Tuesday, I posted about handling interrupted iterations. I've experienced agile teams getting into a pattern of interrupted iterations, and in that case, a more systemic situation needs to be put in place.
In some cases, even when we don’t know what the customer issue is going to be, we are fairly certain that something is going to come up. If we have the historical data to predict a certain rate of customer issues, a workable strategy is dedicate a resource. A person on the team is dedicated to dealing with customer issues, and does not participate in the normal task signup. It’s best to rotate the customer support job among the team members so no one becomes too out of date with current product development.
Sometimes even dedicating a resource does not work. If the person in the role does not have the background to do the work, he may have to call on teammates for help, and interrupt the iteration from within. Or the external situation may demand a faster response than one person can provide.
If this is a consistent pattern, the team is attempting to plan iterations that are longer than the predictable period in their company’s operations. And that’s too long! The solution may be shorter iterations. Most agile organizations I’ve worked with have attempted to hold their iterations to two or three weeks long, but a week might be the length of time that the outside world is willing to hold off its demands for immediate attention.
Even a one-week iteration, as short as that may seem to someone in a conventional software development cycle, might be too long. Mishkin Berteig writes about three day iterations, in a situation in which constant customer feedback was shaping the product. In one case study of an organization with severe trouble setting priorities, he counseled iterations of two days.
Two day iterations may seem like shock therapy. Two uninterrupted days, if adhered to according to plan, might be more productive than a week of second-guessing and wondering.
No comments:
Post a Comment