It Hurts When I Do That
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.