Change Isn’t Free

Agile teams are told to “embrace change,” which is the subtitle to Kent Beck’s wonderful Extreme Programming Explained book. Although an agile team can embrace change, the stakeholders in an organization must understand that change is not always free.

Most agile teams seems to understand this. They get that requirements changes can crossover into requirements churn, to use the traditional term for the problem. Scrum tries to solve the problem by including as part of its framework a rule that change is not allowed into a sprint. Once a sprint has started, change is kept out of the sprint, leaving the team to focus on what was selected to be worked on in the sprint.

This can work extremely well, but keeping change out of the sprint is sometimes thrown back in the face of the team. A product owner or stakeholder who is told that a change cannot be introduced will respond with, “But I thought you’re agile, and isn’t the whole point of being agile that you welcome changing requirements?”

Well, yes and no. A team can welcome changing requirements but that doesn’t mean those changes are free. Consider the following scenario:

You’re out to dinner and settle on chicken as the main dish. As the waiter walks away, you call him back and tell him you’ve changed your mind. You’d prefer the fish. No problem, he says. There is no cost to this change. The restaurant is not going to charge you for changing your mind (changing the requirements) five seconds into your order (five seconds into the iteration).

But, let’s make things a little more interesting.

Suppose the waiter takes your order for chicken and a salad to start. He brings you the salad, and you then change your order for the main dish from chicken to fish. My experience is that most restaurants will still not charge you for this. They’ll bring you the fish even though they may have started cooking the chicken.

There may be a real cost to the restaurant. But I suspect they write it off as goodwill, hoping you enjoy your meal and the courtesy they showed you. And they hope you come back more often because of it.

And let’s say you do come back. In fact, you come back every night. And every night, you jerk the waiter around by changing your order after he brings you the salad. The restaurant is incurring real costs because of you.

They may still be nice and not pass the costs of these changes onto you. But, if I were that restaurant, I’d pass a different type of cost onto you: I’d wait to start cooking your main dish until after you ate the salad so that we were both sure of your order.

Let’s consider one additional scenario. In this case, after eating the salad, you change your order of chicken to fish, as before. But before the fish comes, you call the waiter over and tell him you’ve re-considered and the steak sounds appealing.

Then, before the steak arrives, you call the waiter again and tell him you saw the linguine served to another diner and simply must have that. At some point, the restaurant has incurred real costs from all this switching and will charge you for it.

Change is not free.

You can change your order at the restaurant up to a point for free. You can change it after that and the restaurant will do all they can to minimize the impact of that change, but beyond some point there is a cost to changing.

The same is true on product development initiatives. We can and should embrace change. It is often why we want to be agile. But we can also educate our stakeholders so they understand that change introduced beyond a certain point in an iteration has a cost. And we can work together with them to minimize those costs.

To join the conversation, head on over to the original post on my blog, here.