On “Rigid Agile?“:

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. […]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.

I’d better agree with the AgileAdvice analysis. And it will be so until someone will be successful in bringing together:

  • a sales or a Customer that want’s “just two hour” feature to “be online yesterday”
  • the current project Customer
  • developers.

Until that no solution that satisfies everybody is even possible. Question #1: how frequently you have this? Me - quite seldom. And even the possibility such solution doesn’t guarantees that it would be found. Even if that sales and the current project Customer is the same person I won’t bet it would be. Believe me, I have such customer.

The reason behind this is that any customer (including the customer paying you money now) tends to interpred any words said (and even not said) by you as your commitment. Even if it was stated in triplicate in 24pt bold that the said is just a preliminary estimate.

And, be sure, anyone asking if you can squeeze in an “urgen tiny two-hour feature”, he expects that all your previous commitments will hold. Even if he says the opposite! (Is there anyone who expects him to say his boss/customer that he by his own delayed the project? Ha! There always developers to point to!) So, the only clean solution, if the situation above happens at the beginning of the iteration is to trash the iteration plan to /dev/null and replan the iteration. Canceling every iteration commitment made and reestablishing new ones.

Or to say that nothing during this iteration is guaranteed. If anyone thinks there’s a different solution, I have a wonderful tiny project “with fixed requirements”! And Brookling Bridge accompanying it.

Ah yeah!.. People get sick… Yes, people go vacation, get sick, and get hit by the bus. But what’s new to the Agile?

Have a good development!