The discipline of Change Management has existed for a long time in traditional project management. It is a set of roles and activities that deal with the need to change what has already been agreed upon and planned. You know – we plan, we gather requirements from all sides, then we put it together, analyze it, design it to make sense – everything is perfect. But once the team starts working on it… changes start happening almost immediately. The planned scope changes, forgotten requirements pop up, some absolute necessities turn out to be actually unnecessary, and so on. That’s why Change Management exists, to analyze such incoming changes and then process them so that the whole thing makes sense again. Either by rejecting the change (more effort than benefit) or by incorporating it into the plan. Since changes are happening almost constantly nowadays, this is a very important activity.
In the Agile world, things work a little differently. Agile thinking itself builds on the simple idea of adaptivity, that “change simply happens” and accounts for it from the beginning. So any Agile approach is built with the idea that the changes will keep coming and that they need to be accounted for. This is emphasized in the Agile Manifesto Principles, point 2: “We welcome changing requirements, even late in development…”
The well-known Agile framework Scrum is an example of this – the team plans only a set of top-priority tasks, and typically only for the following 14 days. After those 14 days, it’s time to check again and verify that we’re still moving in the right direction. If no changes come, we move on to the next priority tasks. But if a change has come, we react to it immediately.
Advocates of an even more flexible approach use the Kanban methodology, where there is no fixed 2-week time slot, we just work on the top few priorities each time, and we can decide what to do next each time we finish something.
This explains how Agile approaches work at the operational team level. But how do you plan strategically? Our clients and stakeholders typically want to see beyond the 14-day horizon. Agile approaches typically deal with this through two-phase planning:
In the first phase, the requirements of the stakeholders are also gathered and analyzed, but only the necessary minimum is analyzed so that we have an idea of what the need really is while burning only the minimum amount of time and effort on this. The output tends to be a so-called Backlog – a prioritized list of everything we currently know we need to process, which is easily estimated and about which we can say with certainty that it will change. On the basis of even such rough estimates, we are already able (often with surprising accuracy) to set rough boundaries for the whole larger activity – how much it will probably cost when it will probably be done – and thus whether we want to start it at all. And all this for minimal investment – we are just comparing tasks against similar ones from the past.
In the second phase, we dive right in and start working on these Backlog requirements in priority order. The deep analysis comes at this point when we really want to immediately work on these requirements. Already during the first days of work, we gather valuable lessons from practice. Typically these lessons are lessons like “This area is much more complicated than we thought”, “Here we don’t know what they actually meant” or “Here it’s much simpler, it’s going to be a piece of cake”. These are all already representatives of the first changes that are creeping into our plan and thus into the Backlog:
- “More complicated” happens almost always, because only during the work itself, do we encounter reality, which is often not as straightforward as our plans were. Here, we have the opportunity to react right away either by communicating that the plan is getting longer, by looking for ways to make this requirement easier, or by crossing out some requirements.
- “We don’t know” also happens a lot when the description of the need turns out to be insufficient, or the originally planned solution turns out to be impossible. At such a moment, this reality immediately sends us back to the requestor for clarification or reworking of the requirement (and therefore correct understanding). This prevents the typical disappointment of the “I GUESS the client wanted it this way” solution.
- “Piece of cake” changes are the most welcome ones because they shorten our path to the goal. And they free up space in the Backlog for other requirements, or for the previous two types of changes.
Now to determine who is the “requestor” who is informed about these changes and responds to them. Typically, the role from the Scrum methodology, the Product Owner role, is used in the Agile approach. This role manages their given area (whether it’s really the Product or just a development team) and takes care of their Backlog – making sure that the top priority requirements are on top of the Backlog and that the team is clear on what to do and why or who to ask. He is the representative of all customers and stakeholders of the team. He has thus the final authority over his Backlog and decides what to do in case of this or that change. And thanks to this approach to internal changes, it’s already relatively easy to treat external changes similarly – changes in needs, changes in the market, changes in priorities, etc.
This is how the Agile approach deals with the constraints of the Iron Triangle. It claims that we do NOT know (only guess) how big this triangle is from the beginning, and that changes and refinements need to be worked on constantly. Whether by taking out some of the originally planned requirements (changing Scope), shifting the final deadline (changing Time), expanding the team’s capacity over the long term (changing Cost), or even taking a risk by lowering quality (changing Quality). Decisions depend on the current situation, opportunities, and alignment with the clients and our strategy. Thus, the Agile approach actually elevates Change Management to a primary mechanism by making everything a change by design and understanding that change is actually the right thing to do.
The benefits of this approach to change:
- Transparency – it does not create the false perception that things are not changing, on the contrary, it works with the uncertainty that this is just the current state and it will change. This also has a positive effect on people’s reaction to change, because here we always know that it will come, there is no false sense of certainty of stability, and therefore resistance to change is significantly lower.
- Flexibility – any change is welcome. Each has its price, sure, but if the state after the change is more advantageous to us than the state before it, it is a change for the better.
- Speed – this approach can lead to a faster Time to Market (TTM) because it will deliver the most important value to us in the shortest possible time.
- Cost – when this response to change is a natural part of the process, then we don’t need any special analysis of individual changes or any approval committees. This simplification of the process will have a positive impact on costs. And again, delivering the most important value in the shortest time can help us arrive at the Minimum Valuable Product (MVP) earlier and monetize it (more profit), or stop there (less costs).
