The $2 Billion Dollar Dilemma

What is the time and place for interrupting an iteration?

To answer that I will take an out-of-context quote from the most interesting man in the world, "The time is never and I will let you figure out the place."

Some would argue that this stance is too conservative and doesn't allow for any flexibility when real emergencies arise. This argument is founded on two things; first, that the definition that real emergencies are those things that are so dangerous that they have already or soon will prevent the normal course of business unless they are resolved and two, a fundamental misunderstanding of agile principles when planning iterations.

This is a valid definition of a real emergency but invalid in that proper iteration planning takes into account the overhead of resolving defects in production and therefore in that context the iteration plan is built with the expectation of "real emergencies" and is therefore not interrupted when they occur. In other words, the established average velocity of the team takes into account the natural frequency of real emergencies and the overhead needed to address them.

The other use of the "real emergencies" clause is when business development and sales people claim there are real business/sales scenarios that because of the perceived value of the potential client/customer, represent a valid excuse to interrupt the iteration or a real emergency.

To further illustrate this point I will describe a common real world example:
The development team is three weeks into a four-week iteration when the development manager gets called into an urgent meeting with the business development team. In the meeting the development manager is informed that in two weeks, his team needs to deliver a working demo product to be used by the sales team for a meeting with industry CEO's for a deal that could be worth two gazillion dollars. What does the development manager do?

The problem with countering this argument is the dollar amount of the potential deal, the business people will use that like a Quake stud with a BFG on quad damage to demolish any counter claim about the productivity losses and procedural misconduct the development team may offer up. They would argue that this is a situation in which the team is justified in breaking the iteration, and building the demo product for the sales team, but this argument and its seemingly weighty justification are just common camouflage hiding a much larger problem within the organization.

This justification is really just an excuse to all for all the factors that lead to a scenario like this, such as a lack of planning by the business development team and sales team, a lack of communication about what the needs of the sales and business development teams will be in the coming weeks and months, lack coordination between the product managers prioritizing the backlog and the business development/sales teams, and a destructive attitude that it's acceptable to push the consequences of disorganization down to the development teams.

Sadly, it becomes the duty of the development teams to stand firm against this hurricane of incompetence and hold the iteration together. Correcting the organizational misconduct will undoubtedly be very painful and in some cases slow going, but the end result completely justifies the means.