Change Is Good…Or is It?

Different agile teams take different approaches to change. Some teams follow the lead of Extreme Programming and are very accommodating of change within an iteration. These teams will allow their customer or product manager to introduce changes directly within an iteration, effectively swapping the development of one feature for the development of another.

Other agile teams take the advice of the Scrum process and decide that it is important to keep change out of an iteration. For these teams, once the team commits to developing a set of new features during an iteration, no changes are allowed. Plenty of teams have succeeded with each approach, so it is too simplistic to say that all agile teams need to adopt the same attitude toward change. However, I do think that there are clear advantages (and disadvantages) to each approach. What I'd like to present in this article is a set of guidelines that teams can use to determine how they should view change: Should they allow changes within an iteration, or should they seek to avoid it? A significant obstacle to establishing highly productive software development teams that I observe frequently is that most organizations cannot establish a set of priorities and leave them alone for any significant period of time. Many struggle to set priorities and hold them constant for even the short two- to four-week iterations favored by most agile teams. These organizations seem to think of themselves as hospital emergency rooms--new business opportunities appear so often and with such suddenness that there is no opportunity for them to prioritize. By the time priorities have been established, business conditions have changed again, requiring a further change of priorities. In most cases, however, this just isn't the case.

Most organizations that struggle with shifting priorities do so because thinking ahead is difficult. It takes effort for a customer or product owner to say, "This is the most important thing to work on" and have enough confidence in that statement to stick with it through the entire iteration. Because establishing priorities and sticking to them is hard, many organizations take the default position of allowing changes into their iterations. I think this is a mistake and it leads to my:

Guideline #1: Develop the ability to establish and stick to priorities so that you can truly choose between letting change into and keeping it out of iterations.

Until an organization has the ability to leave priorities alone for an entire iteration, it has no choice in the matter: It must introduce change within iterations. Learning how to leave priorities alone can be difficult. One way for customers or product owners to learn how to leave priorities alone is to practice. The more iterations you run without changing priorities, the easier you will find it to run future iterations that way. However, saying that one must practice leaving priorities alone begs the question of how one begins. Advice for getting started is given by:

Guideline #2: If you cannot leave priorities alone for the length of an iteration, shorten the iteration.

The central idea behind Guideline #2 is that it is better to shorten the iteration than to allow change into an iteration for a team that hasn't yet learned how to keep change out. Some agile processes encourage month-long iterations. With a month-long iteration, the organization may occasionally have to wait nearly two months to get a new feature. (This would happen, for example, if one day into an iteration a slightly more important feature than those being worked on is identified. That feature would be prioritized into the next iteration and delivered at its conclusion.) This can be a very long time to wait for a highly dynamic organization. If it is, try a shorter iteration. I've taken organizations down to as short as one-week iterations. The point of shortening the iteration is not to permanently settle at that length, but to provide more opportunities for learning how to stick to priorities (even if only a very short period).

The organization that becomes accustomed to holding priorities constant for a one-week iteration will probably be able to do so with two-week iterations. If the organization then becomes able to hold priorities constant on two-week iterations, they could then try four-week iterations if they want their iterations to be that long.

Once an organization begins to be successful in keeping its priorities constant for the iteration, their goal becomes getting good at it, which is embodied by:

Guideline #3: Get good at running iterations with unchanged priorities before contemplating allowing change in.

After the organization becomes good at keeping change out of its iterations, the organization can begin to make a conscious, deliberate decision about how to view change. Some will prefer the Extreme Programming approach of allowing change into an iteration, others will prefer the Scrum approach of preventing change within an iteration. By this point--after having achieved a proficiency for keeping change out so that doing so has become a realistic option--the extended project team will be able to make a decision about what is best for their organization.