Dmitri Zimine recently posted an article on Agile Advice titled "How Two Hours Can Waste Two Weeks", in which he describes the costs associated with responding to a customer request within an iteration after that iteration has already been planned. According to Dmitri, the problem is that a "two hour" job is never just two hours, and so it becomes impossible to know if the team has any chance of fulfilling the commitments it has made for that iteration. Thus, the only responsible course of action when faced with such a request is to either defer the request to the next iteration, or cancel the iteration and respond.
None of this seemed very agile to Joel Spolsky, who posted a response titled "You Call This Agile?" Joel argues that urgent customer requests will - by necessity - almost always take priority over the plans of the development team. (A similar perspective is presented in Pawel Brodzinski's blog posting titled "Context Switching.")
Mishkin Berteig followed up with an article on AgileAdvice defending Dmitri's position, in which Mishkin elaborates on the theme of an iteration forming a commitment made to the customers by the development team. The point, says Mishkin, is that planning an iteration and sticking to it is crucial to establishing a bond of trust between the development team and the customer. It's not that the developers can't handle interruptions, but rather that those interruptions should be handled within the process:
Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. That's a red herring and I'm suprised that Joel threw it's stinky carcass into the discussion. Agile is also about balancing that responsiveness with the overall view of value for the team and the organization. The tool for doing that is the prioritized list of work, not the email message from Sales Guy to Sarah.
Community comments
A week isn't responsive enough?
by Deborah (Hartmann) Preuss,
Re: A week isn't responsive enough?
by Bruce Rennie,
Re: A week isn't responsive enough?
by Deborah (Hartmann) Preuss,
Re: A week isn't responsive enough?
by Mishkin Berteig,
Re: A week isn't responsive enough?
by Nicholas Cancelliere,
A week isn't responsive enough?
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
Statistically, an unplanned urgent request is likely to fall in the middle of an iteration, right? In my experience, for a team doing 2-week iterations, asking a customer to wait one week usually doesn't cause any stir at all.
Remember where we come from: I've seen change control take 6 weeks before the request ever comes back to the team!
Re: A week isn't responsive enough?
by Bruce Rennie,
Your message is awaiting moderation. Thank you for participating in the discussion.
As with all questions of this kind the answer is: it depends. If the urgent request is to address a defect that is preventing a customer from working, a one week turnaround probably isn't going to cut it (and yes, I have seen this happen on legacy projects that are transitioning to agile).
I'm not fond of Joel's frequent jabs at agile, but I'm also not quite ready to take a firm stand on this situation. In fact, doing so DOES feel like violating some of the manifesto's values. It's an interesting question, isn't it? Are hard and fast rules, by definition, not agile? Can we adapt our process to individual situations and still call ourselves disciplined? I like to think so.
For better or worse, I would probably try to find a compromise solution (assuming it is a true emergency). I would ask the team if they felt they were able to commit to the scope change. I would ask the customer if they were willing to "swap" a story of similar size. I would DEFINITELY make sure the event was discussed at the iteration/sprint retrospective to see if the team had any ideas about how to protect itself from this type of interruption in the future.
That may feel all too much like what goes on in traditional plan-driven projects every day. The difference with agile is we know we're doing something that isn't optimal. We know context switching is bad. We want to avoid it whenever we can. It's almost a rule. But the rule that beats all other rules is "do the right thing". If the right thing for the business is to address the emergency immediately, then we should do that.
Re: A week isn't responsive enough?
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
However, should an urgent request come in requiring 30%, we'd be back to the former decision: cancel? wait? And, of course, the customer would be expected to make this decision based on the cost of the bug vs the cost of their choices.
Interestingly - having watched Ken's "Canary in a Coalmine" talk, I now view this "planned maintenance" buffer as a metric on the quality of that legacy system, and an indicator I can take to management :-)
Re: A week isn't responsive enough?
by Mishkin Berteig,
Your message is awaiting moderation. Thank you for participating in the discussion.
Again, the problem is that doing this has to be recognized as completely invalidating the commitment the team made at the start of the iteration. In Scrum, this commitment is made at the granularity of the team and the iteration, not by individuals or backlog items. This is partly because you can't predict what order backlog items will be completed nor who will be working on them during the iteration. The strict rules are there to acknowledge that if you have an urgent request, then you have to absolve the team of their previous commitment. When you do this (because the urgency is high enough), then you start a new sprint so that you are still in the process framework. I've seen a team cancel an iteration to handle an urgent request and then spend several months in chaos because they didn't plan the request in a new iteration - they forgot to keep doing iterations!
I believe that agile methods such as Scrum, XP and Lean Software development provide a balance of rules somewhere between chaos and excessive bureaucracy. These rules vary depending on team size, project criticality, etc. etc. But the rules are there for a reason. Learn to follow your chosen set of rules first, then learn to transcend the rules. It's okay to be dogmatic when you are first learning/trying a process. If you don't be dogmatic, you don't know if the failures are because of the process or because of your mis-application of the process.
Agail, agile isn't only about responding to change. It's also about quite a few other important things that balance out.
Re: A week isn't responsive enough?
by Nicholas Cancelliere,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sometimes a week isn't responsive enough. If your server dies and requires developers to help troubleshoot that requires being responsive within minutes. If your team is required to code a fix - hours of your day lost.
The Agile manifesto says "Responding to change over following a plan." There needs to be a balance, and remember the manifesto doesn't say "no plans," it just says they're less important than responding to change. An unhappy customer at the end of the day is more harmful than an side-tracked plan.
It really boils down to where these emergencies originate. If it's outside your business (customers) then you probably have to respond, it will mean your team's velocity suffers. If this becomes habitual then maybe there are some QA issues or product development issues that need to be addressed. If the emergencies come within the organization then maybe there is a problem with prioritization, weak leadership or poor vision by product owners.
In the end it should be a decision shared by the team (product owner, developers and scrummaster). That way the trust is preserved and the team is self-managing because they're making the decisions collaboratively.