Anti-Agile flak March 7, 2010

There were a couple of interesting posts on InfoQ last week about problems with Agile. First, a few points from Mark Lines' post Here's one of his 'common sense improvements' to Agile:

...the Unified Process breaks a project up into 4 distinct Phases, after which the iterations are named.  In this way, stakeholders can know how the project is progressing...Other agile methodologies simply number their iterations sequentially.  Being in iteration 4 tells me nothing about the progress of the project towards completion of its initial vision.

Here Kai is mostly making an informative statement about his flavor of Unified Process, but ends it with a dig at Agile iteration numbers. Agile projects provide other artifacts for getting a high level picture of the status of the project such as burn down charts.  Iteration numbers are more useful as historical markers.  If you want a detailed view of an Agile project's status then attend an iteration planning meeting. His point here is like saying "My new car is better than yours because I put the blinker at the top of the steering column.  You don't have anything at the top of your steering column!" Mark also lists many issues that Agile projects have to face such as resistance to pair programming, mandated bureaucracy, insistence that projects cannot be executed independently, and perceived difficulty in frequent deployments.  He claims that Agile projects often trivialize or ignore these realities. In my experience we will fight against these issues. If the fight cannot be won or is not worth it then we give up.  There are times when some of these issues cannot be overcome.  Some projects must take a dependency on other ongoing projects and sometimes you can't deploy frequently.  But to fight against these issues is not trivializing or ignoring them, quite the opposite: we are acknowledging and addressing them. Now on to Kai Gilb's post Kai makes two claims (so far, his post is only at part 2 of 7 as I write this):

Agile does not focus on stakeholder value

To make this point he shows a diagram that represents a Scrum workflow (from here: Nowhere on this diagram does it mention stakeholder value.  It's just a product backlog going into a sprint backlog, going through development and producing working software. To assert that this means Scrum doesn't focus on delivering value you would have to intentionally ignore the creation of the product and sprint backlogs.  It's almost as if he stumbled on to this lone diagram and said "Hey, there's no mention of value here, I can use this to say Scrum doesn't focus on value!"

Agile 'baby talk' kills developer creativity

For this point he uses the following user story as an example: "As a buyer, I want to place a book in the shopping cart" While this story does come from some Scrum training materials it is used in the context of describing a product backlog, not how to create a story.  So, I'd agree with him if this were your typical user story, but it isn't.  At best this is the kind of story crafted and accepted by an inexperienced team.  It doesn't talk about the business value it would provide.  Doing so would serve to both justify its existence and help developers think of appropriate solutions.  Also, the story goes too far by prescribing an implementation of a desired function instead of stating the desired function. I suppose these kinds of posts are common (both the ones I'm responding to and mine) so I probably won't make another post like this.  However I would gladly continue a dialog along these lines if anyone is interested.

blog comments powered by Disqus