Rigid Agile?

November 16, 2006 2:26 PM

I have to agree with Joel Spolsky's take on this piece of "Agile Advice". Isn't agile development supposed to be all about embracing change?

Mishkin Berteig from Agile Advice follows up and tries to explain. The hypothetical situation is Sarah. Sarah's bosses want her to work on a different project for a day, to add a feature that would give them a sale. To me, this is a simple cost/benefit analysis. Is the feature (and resulting sale) worth losing a day of Sarah's work on her current project? If so, get the stakeholders to remove one day of work from the current iteration to compensate. Problem solved.

To Berteig it's far more devastating. Apparently to cater for such a situation:

...there are really only two [alternatives] that work in Scrum:
  1. Stay the Course [i.e. do not allow Sarah to work on the other project -cm]
  2. Cancel the Iteration

I'll admit that I know nothing about Scrum, but I really hope that it's being misrepresented in the article. This approach seems completely bizarre. You lose resources from development all the time, and if you can't deal with it elegantly, you're screwed.

As an exercise, re-read the two articles, and all the pronouncements about how Sarah spending a day on another project would "stop the whole team" (Berteig's words), cause the whole iteration to be reset and seriously damage both the business's trust in the development team and Sarah's self-worth. Now imagine she instead had to take the day off to care for her sick three-year old son.

From a resourcing point of view, what's the difference if someone is reassigned or just absent? If losing a single resource for one day is a cataclysm that causes the entire iteration to collapse for everybody, you've got problems, and you're putting the wrong kind of pressure on your team.

And you certainly don't have anything I would call agility.

Previously: How Not to Take my Money

Next: Dreaming