Thursday, September 28, 2006
Confusion over "Agile"
While reading Steve Yegge's post "Good Agile, Bad Agile" a useful distinction occurred to me: there's a philosophy, as put forward in the Agile Manifesto, and there are executions of that philosophy: the various Agile Methods that people are so quick to rail against are examples.
I read the vitriolic derision aimed at the agile community. Steve's post goes on at length about 'Bad Agile.' Articles at Hacknot are harsh. A quick web search uncovered various other instances of developers bashing Agile. These pieces are backed with statements about how Extreme Programming is broken, or why Scrum can't work. That's fine. Everyone's entitled to their opinion.
The authors of these articles often go on in self aggrandizing fashion, to describe how they develop software, and how that's sooo much better than 'Agile' methods. Their contempt is palpable; I wonder if they run off to wash their hands after typing that word, 'Agile,' the way Sicilians expectorate after speaking the name of familia disgraziata.
The comments typically boil down to: Agile is for unthinking fanatics.
And this is where I find myself frustrated. They've tossed the entire Agile movement on the trash heap, but their own software modi operandi? The ones they're so proud of? Almost invariably, they are executions of the Agile philosophy!
I'm not the first to have noticed this. One of the earliest comments on this post gives a decent comparison between Scrum and Google's development practices, so I won't add any detail here.
Steve talks about a lot of other things too - things that don't fall into the category of Agile development, good or bad. He talks about managers who motivate with incentive rather than fear. At Google, they limit meetings to core hours, they hire good, disciplined developers, some of whom work on tools to help the others. Everyone gets time to work on side projects, and they're strongly urged to take advantage of that.
Guess what folks - that's just good management. These things lead to a productive environment, but they don't make it any easier to change the direction of your product while you're writing the code. And that's what Agile is all about.
What I'm saying is this: as an Agilist, I agree with everything Steve calls 'Good Agile.' Some of it is simply an interpretation of the Agile Manifesto; it's not Scrum, or XP, or anything - it's a version of Agile that exists within Google. The rest just describes a productive work environment.
This leads me to a few interesting conclusions. First, most people know Agile through the practices and procedures that follow from the Agile philosophy; few are aware of the philosophy itself. Further, the mapping between the philosophy and the practices is not straightforward. Without awareness and understanding of the philosophy, the practices are easily misinterpreted. The unfortunate consequence is developers who judge Agile on its face and reject it, even though they may actually be Agile at heart.
My second conclusion is that having a group of Agile developers isn't enough; for a project to be successful, you also need the right environment. If the culture surrounding the development team is toxic to Agile precepts, it will be difficult if not impossible to mount a successful Agile project.