In the VersionOne 9th Annual State of the Agile Survey, 56 percent of the respondents cited “the ability to manage changing priorities” as a reason for adopting agile. That doesn’t surprise me at all, since more traditional forms of development are quite fragile to changing priorities. After all, companies would like to at least be robust, if not antifragile, in the face of changing priorities. Unfortunately, too often, organizations take agile’s “embrace change” principle to the point of waste, hurting themselves in the process.
For example, a few years ago I taught a product owner class at large, well-known software tools company. The class was composed of higher-level business people and a few senior engineering managers. When I arrived onsite, one of the engineering managers pulled me aside before class started and said:
The business people were told that in agile we embrace change. They have interpreted that to mean they can make changes whenever they want—even in the middle of a sprint! When we push back, they say that agile is about embracing change, and it is one of the principal reasons we transitioned to agile, so the engineering organization just needed to deal with it!
Sure enough, during the class the embracing-change issue came up. The business people complained that the technology people were being too rigid and were unwilling to make changes when the business needed them to. The technology people complained that they were buried beneath a wasteful pile of partly completed work because the business people were constantly changing their minds.
Sound familiar? The root cause of the problem is a misunderstanding of the underlying principle from the agile manifesto: We value responding to change over conforming to a plan.
Embrace Economically Sensible Change
My solution is to restate the principle. I no longer say, “In agile we embrace change.” Instead I say, “In agile we embrace economically sensible change.”
A keystone of embracing change in an economically sensible way is adherence to an important Scrum rule: Once the sprint goal has been established and sprint execution has begun, no change is permitted that can materially affect the sprint goal. In other words, no goal-altering changes once a sprint begins.
To help explain why following this rule is so critical, let’s look at the economic consequences of a change as our level of investment in the changed work increases.
We invest in product backlog items to get them ready to be worked on in a sprint. Then, once a sprint starts, our investment in those product backlog items steadily increases; initially, because we spent time during sprint planning to discuss and plan them at a task level, and eventually because we actually began developing and testing product backlog items. If we make a change after sprint planning has occurred, we not only jeopardize the planning investment, but we also incur additional costs for having to re-plan any changes during the sprint.
As a result, the waste of making a change goes up once our investment in an item has increased. In other words, it is naïve to say that we “embrace change,” because there are times when making a change is just bad economics. Instead, we need to embrace economically sensible change! Restating the principle in this way creates a shared understanding among business people and development teams about how, why, and when change is possible, and reduces the waste caused by ill-conceived change.
Does your organization abuse the “embrace change” principle? If so, leave a comment below and explain how.