One of the problems in Scrum is what to do with new urgent items. There is an interesting discussion going on right now between some developers at AgileAdvice and Joel Spolsky, that boils down to:

Dmitry: Don't interrupt the sprint for urgent items because small distractions cause big delays.

Joel: "You call this Agile?"
Agile development is supposed to be about agility. It's supposed to mean that you can change plans quickly. It's not supposed to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can't rearrange their schedule a bit to serve the needs of the customer. Dmitri's conclusion, I'm afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.
Mishkin:
Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. [...] 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.
If you have customers, you can't afford not to be responsive. Dmitry's hypothetical case is about a new deal, but existing customers have urgent needs too. At Atalasoft, we offer paid Gold support, which means that we promise to respond quickly and release hot-fixes between minor releases to address the problems of our Gold support customers.

As Miskin points out, in Scrum, the team makes a commitment to delivering a fixed set of work in a fixed amount of time (the sprint). But we also have another ongoing commitment to deliver ad-hoc fixes to existing customers quickly. I can tell you that in our development meetings, saying that a task is tied to a Gold support request is a trump card, we don't discuss its priority any further.

Scrum offers us basically one option for dealing with this -- cancel the sprint. For us, that's unacceptable. So, we may not be doing pure Scrum -- but, we have seen and implemented some different ways of dealing with urgent items, that I think are in the spirit of Scrum.
  1. Leave some time unallocated to deal with urgent items. Actually, I wish we did this better. The problem is that we can go a whole sprint without any large Gold support issues that require development -- we have no idea what's going to happen.

  2. Remove items from the sprint. I know this is a no-no, but usually we have a few small lower-priority items that are nice to have and help round out the time to a sprint-sized chunk. In a way, we are pre-deciding what we would do if no urgent items came up. Probably the right way to do this is to not put them into the sprint to begin with, and then let the team add them in if they have time.

  3. Reserve part of the day to do non-sprint items. We don't do this, but I know of a company that only does Scrum after lunch and in the morning deals with ad-hoc tasks (existing customers, infrastructure, etc.). If they have nothing to do, they can work on a sprint item or any other backlog item. It works for them.
Of course, there are other options like lengthening the sprint or not delivering, which I'm sure many teams do, and personally, I don't really have that much of a problem with it if it works.

The benefits of Scrum that I am trying to maximize don't require dogmatic adherence to the "rules". Here's what I like:
  1. Transparency. We create a burndown chart each day and try to identify problems early enough to do something about them. We have the scrum meeting each morning and discuss what is happening on the project. If you do just these two things (track progress and have a morning meeting), you will get huge benefits. Doing this sets up a feedback loop that smart developers will use to get the project on track.

  2. Iterative Development. Breaking down the development into small chunks makes it easier to plan, easier to see when we are on the wrong track, and let's us apply lessons learned more quickly. The sprint planning meeting forces us to make decisions about what is important and what we'd like to see in 3-4 weeks. They are spirited discussions because the choices are hard, but if we tried to plan out 6 months this way, it would be impossible.

  3. Cross-pollination. All of the developers get to see what's going on in other products at the daily meeting, and at the end of the sprint, we have a "show" where we get demos of all the new functionality and a walk-through of code (especially important for new API's).

  4. Rational, Priority-based Decision Making. It's very easy to let urgent items drive development. We still do that to some extent, but we make a rational decision based on the value of each urgent item vs. the items in our backlog. For Gold items, the answer is easy, we already promised to do it. For other urgent items, we weigh them against our other work.
The way to deal with important urgent items in Scrum is to first figure out what you are trying to get out of the process and then figure out how to do them in a way that let's you still get those benefits.
Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!