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.
