Because, apparently, their 30 minute debate on TDD was insufficient, Agile Bazaar invited industry leaders Bob Martin & Jim Coplien to continue the discussion over an entire weekend of old sk00l learning at MIT. And so, as 90 of us gathered to hear them out, they kicked it off by explaining why agile is so damn hard. You see…
Agile development is like teenage sex.
Everyone says they’re doing it, but only 10% are.
And those who are — ARE DOING IT WRONG.
Don’t believe it?
Take the Agile Machismo test – industry scores range from -4,000 to about +20.
And even for those following the practices – what have we learned? According to Coplien, 70% of Scrum implementations fail, pair programming fails 50% of the time, TDD deteriorates our design, on site customers demoralize the customer and the team, and agile retrospectives have actually been proven to make projects worse.
Phew! So why do we bother?
Pan to Uncle Bob… fast forward 15 minutes past the discussion on how the universe was formed…
Paying the bills is hard! But NOT paying the bills… is harder.
Doing the dishes is hard.
Scraping the hardened CRUD off after several days so we can have clean dishes to make our next dinner – is harder.
Agile, then, is the software equivalent of doing the dishes. It’s our admonition to pay the bills.
It’s hard. But not doing agile is harder.
Sure, there are a lot of practices in agile. And, depending on your persuasion – XP, Scrum, Lean – they may all be a little different. But, one thing Bob and Cope both agreed on was that agile is not about the practices. Agile is NOT TDD (regardless of your views on its goodness or badness). And agile practices are not a substitute for thinking.
As Uncle Bob and Cope leapt up to perform an impromptu martial arts move in eerie synchrony, they spoke to how the practices in agile – like those in martial arts – are only the starting point, the building blocks, from which we learn. If you’re caught in a fight, you’re not going to repeat each form you learned in perfect order while your enemy bows and gives you space. You’re going to use the principles you’ve learned from years of practice to figure out the best moves to make.
And so it is with agile. The religion has to die. XP, Scrum, Lean, these are just sets of practices – good ideas that people have assembled. Scrum is filled with great ideas for creating successful teams, but if all you do are assign the necessary roles and hold the prescribed meetings, you’re missing the point.
Testing can positively influence your design. But it still takes strong design skills & knowledge to do a good design. Even Jim concedes that unit testing can be helpful for tactical decisions, but they both agree it’s no substitute for architecture.
Per its manifesto, agile is about uncovering better ways of developing software by doing it and helping others do it. If you just take the practices, with no consideration for the underlying values or how to make them work within your organization, then you — like all those teenagers — are doing it wrong.
» Deep Agile 2008