One of the most curious things I encounter when meeting people new to Agile are long time veterans of the software development game who all agree that up-front design doesn’t work and also think Agile is not valuable.
See the contradiction?
These folks (and I have met many over the years) are quick to point out the flaws, inconsistencies, and downright disfunction of their current waterfall process.
“We get the requirements from the Business Analysts,” they say, “and they are never right.”
“We build an deliver to QA and move on to the next project,” they say, “and it always comes back with defects.”
“There is no such thing as defect-free software,” they say, “an in their world they are right.”
“It hurts when I hit my finger with the hammer,” they say while placing their index finger atop the next nail.
These same folks will dismiss Agile and iterative development practices in the next breath with words like “impractical”, “unrealistic”, or “chaotic”. Is this fear of change? Is it threatening to have the system you hate so much be threatened by an up-and-coming idea? This seems to me a bit like hating the king and leaving him in power for fear of who might will replace him.
This is one of the reasons I find it terribly important to discuss not just the benefits of all things Agile like Scrum and TDD, but to also introduce the history and practices of failed engineering projects that caused these things to emerge. This provides a pathway to enlightenment for the most diehard anti-Agilista. Once we can establish the history, theory, demonstrated success, and techniques, engineering minded folks are more able to see these Agile practices as real tools for their toolbox.
Another useful technique is to start these folks off with engineering process first, not methodology changes. Almost everyone can agree to the demonstrated value of TDD. Once a surly developer sees TDD as a small, iterative feedback loop, we can start asking why the next level of the feedback loop isnt’t happening with automated builds. Then Continuous Integration. Then iterative delivery to a product owner. Then Agile because by now they are already there without knowing it.
Leading with process in a top down implementation can be ineffective when selling to grizzled engineers. Let’s help people stop hitting their fingers before we try to get them to build something beautiful.
It is important to note that many of the principles of agile development are actually based on earlier works by Tom Gilb and Harlan Mills. In addition the Rational Unified Process has also used the concepts of iterative development for a long time. Even the concepts of unit testing were originally proposed by Beck when he was working with small talk
None of this takes away the power of Agile development, but it is incorrect to say you must use agile development techniques to get the advantages of Unit Testing and Iterative development.
One area where more formal design methodologies are important is where compliance with regulatory practices must be observed. This was forced on a lot of organizations with Sarbanes –oxly. As such many of these organizations require some level of documentation to be compliant with the new federal laws. This is an area where agile tends to be a bit cavalier with their design and test artifacts and these organizations may need the more formal RUP or IEEE standard process. That is not to say that these organizations cannot take advantage of iterative development and test driven development, they may just need some of the more formal artifacts provided by CMMI compliant methodologies.