Tue, 16 Dec 2008

Agile Shenanigans

One of my teams at work has been involved in a pilot project to deploy the Agile methodology, Scrum. If you're reading this far, I presume you have an idea what Scrum is, so I'll just come out and say it:

I'm calling "Shenanigans" on the "Agile Manifesto".

Simply stated, this is what the Manifesto says:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
Now, I understand if some of these guidelines were necessary for the formation of the Scrum methodology. Scrum is tool- and technology- agnostic, so taking the focus away from those aspects which the methodology doesn't prescribe isn't surprising.

But, take the first element-- individuals and interactions over processes and tools... I'm far from a gearhead-oriented manager. My humanist management philosophy is well documented, so on the face of it, I would tend to agree with this statement.

Yet sometimes, the most important problem you need to solve on a team or in the course of conducting business is not "individuals and interactions", but "processes and tools"...

In some projects, comprehensive documentation may actually be a better artifact than "working software". You may want to "negotiate a contract" between parties if communication challenges (say with a vendor or a customer) will save time, hassle and energy. In some cases, it's far better to publish an API than to conduct "customer collaboration", for example, or to follow a plan if that's the most expedient way of solving the problem at hand rather than revisiting things that have already been decided and agreed upon.

One last example, and I'll end my rant... If Agile had been invented in the 1970s, then many of the folks working on software at the time may have developed code more productively and with less gnashing of teeth and pulling of hair.

But when Y2K came around, what do you think the remediators would be more grateful for? That there was "comprehensive documentation" about the date/time functions, or that the developers were able to launch "working software"?

If you would have told the developers 30 years ago that there was a "Y2K" defect in their code, in Scrum, that defect would be placed on a backlog, and be deprioritized so frequently that eventually any ScrumMaster worth his weight would have taken it off the backlog after a year or two. After 2-5 years, if not a decade or two, the people who originally may have realized there was a Y2K bug would have moved on, and the decision to take the Y2K bug off the backlog wouldn't have been realized until... you guessed it, a few years before Y2K when suddenly everyone was scrambling trying to figure out "are we vulnerable?"

And the teams responsible for remediating the problem? The 1970s Scrum teams would have focused not on documentation or negotiation of contracts or producing any artifacts that could be useful if only for software-archaeology purposes, but on code that met a 1970s "definition of done".

Don't get me wrong, I'm a big proponent of Agile, but because there are occasions to value items on the right more from time to time, it's probably best to put the Agile Manifesto on a "credits" page and grant it "historical anecdote" status rather than front-and-center in many slide decks about the Agile methodology.




Khan Klatt

Khan Klatt's photo