But as of late, I think marketing got a hold of the term and it is becoming a bit abused. A number of new “driven” practices that have emerged recently including Model-Driven Development and Requirements-Driven Development. These practices start to take me back to my days at Rational Software when the “best” practices were about selling tools – not making teams deliver better solutions. If you look back at the Original Rational Best Practices, they line up specifically with the tools they were selling – Manage requirements, Visually model software, Verify software quality, etc. While IBM Rational has moved on to a better set of “best” practices, the new “driven” of the month marketing programs by all of the other tool vendors appears to be in full market fluff. Software Development Times has a great article on this topic if you want to keep reading.
You can even find Meeting-Driven Development for those looking to hide incompetence and Resume-Driven Development for those looking for technology to improve their resume. But I digress into Dilbert land…
If I recall correctly, the Agile Manifesto states that individuals and interactions are more important than process or tools. I believe this is true. Sure, process and tools are important, but not as important as the people you have on your project and how well they work together to deliver software to your customers. I will take your team and trade it for any process and bet that I will deliver more value than you. A process is good, but a team is essential to building software.
That is why Scrum works. Scrum is all about the team, the whole team and nothing but the team. I like to refer to Scrum as Team-Driven Development. There are many good development, test, build and product management practices including some mentioned above, and they can all be used with Scrum because Scrum is a framework for the team. Scrum recognizes that software developers do not deliver software in isolation – it requires a whole team including analysts or product managers, architects, developers, DBAs, quality engineers, build engineers, operations, support, and others involved in a whole-system, end-to-end, delivery cycle of a software solution frequently involving multiple iterations of reviewing working software to get it right.
As Team-Driven Development, Scrum shines the light of radical visibility necessary to expose the tremendous inefficiencies built into every one of our organizations. It is those inefficiencies that are preventing the right solutions from being delivered in a timely fashion. Years of predictive waterfall thinking with command and control leadership have suppressed much of the capabilities within organizations. Through listening to and acting on the inhibitors exposed by Scrum, organizations will begin to release the tremendous energy currently untapped within their teams.
So if you are in the market for a proven “driven” approach for your organization, and one that comes with no tool strings attached, try the Team-Driven Development approach through Scrum. There is no comparison practice that can produce the quality and quantity of results than you will get from high-performing teams. Expect to be surprised and prepare yourself to see and hear things you are not ready to see or hear. Scrum is not easy, but it is worth it.