Posts What I learned from Agile Transformations

What I learned from Agile Transformations


Human systems are at best a complex system. When we try to change that system we need to respect that system and understand it. Making changes that focus on simple answers but ignoring the complex parts of the system is inviting failure.

An airplane being overgrown by trees Photo by Mohan Reddy Atalu from Pexels


I have been through several failed agile transformations and one successful one. To say that a transformation failed does not say every aspect of it failed, but that in the end the company was in a worse spot then they were before the transformation. These transformations have been at different stages of my career and learning path. That being said, this blog is not intended to be an end all blog on transformation failure or recipes, only a look at what I have seen throughout my career and what I learned from that.


Simplicity is a core agile tenet, defined as “Maximizing the work not done.” This can be tricky though, particularly when dealing with wicked problems. The problem I see is that people are looking for a “simple solution” rather than a “simple way to find our solution”. (I speak from experience here 🙂)

By focusing on the simple solution, we ignore the complexity of the domain. We ignore the people involved. And we ignore the effort real change will take. We must remember that a system behaves exactly as it is designed to behave. People who are trying to accomplish goals will find ways to optimize around achieving those goals. We may not understand every way the system is optimized; we may never understand. Worst of all, as we change a system, we are inherently removing the rewards people get for working the way they work.

So, we turn to a different tool. The Cynefin Framework can give guidance here. If we are not in firefighting mode, then we are most likely working in a “Complex” environment. Cynefin suggests that when in a complex environment we must probe, sense, and then respond. Meaning that we make a change, wait to see how the system reacts to that change, and evaluate where the system lands after it reacts. Once we know that, we can then try another change with the hopes of getting closer to what we want. If this sounds familiar, you may have heard a talk or two on retrospectives.

If however we find ourselves in a firefighting mode, we are probably operating in a chaotic domain. This means we do not have time to probe the system. So Cynefin suggests we act, sense, and then respond. We act first because things are critical and urgent. But this is an action based on pressure and need, not data. We then sense. Was this the correct action? Did this action start more fires? Finally, we respond, by either acting to fix the problems we caused, or to tackle the next biggest critical and urgent thing on our plate.

Human Systems are Systems

Human systems are systems and as such they obey all the natural laws of systems. The one that is often ignored is that all systems seek equilibrium. Once in equilibrium it takes a significant amount of energy to find a new equilibrium, often an order of magnitude more energy. Before that new equilibrium is found, the system tries to revert to a state that requires a lower amount of energy. Often that is a previous state, but it might also be a state where the system disintegrates.

When trying to alter a human system we need to take the whole system into account. We need to respect the system and look for the correct lever. In “The Fifth Discipline” Peter Senge diagrams a number of ways that human systems work, and how to find their leverage point. A leverage point, as described by him, is a point where a system is subject to change with little to no effort. These are points that are already setup to amplify effort in the system and can therefore be used to modify how a system behaves.

When we take these common human system patterns and their leverage points into consideration, we gain a lot of control of that system. When we do not, we pour a lot of energy into a system with no idea what its new equilibrium will be.


You have heard that culture eats process for lunch. This is usually hurled as a pithy remark that you must change culture if you want to change process. However, changing culture is not a pithy effort. When you look at culture there are a lot of inputs and outputs that form feedback loops. Culture is a human system within a human system. We need to look for leverage points, make small changes and determine if that change leads to favorable outcomes.

But how do you change culture at the leverage points? You cannot simply tell people that their culture is now different.

Follows Structure

Culture follows structure, especially informal structure. That means you can determine structure by examining culture. It also means that by changing structure we will change culture. However, some changes will reinforce culture by strengthening what is already there. So not every change to structure is equal and you have to think about simplicity and systems when changing structure.

Follows Rewards

Rewards are an insidious system that exists within companies. They are insidious because they are “simple” switches that have drastic effects on behavior and often in unanticipated ways. Moreover, rewards affect how someone sees success in their role and can become tied to one’s own identity. Changing rewards are often one of the things that causes resistance in transformations. They are a powerful influencer to culture. Changing a reward structure will change the underlying culture, but again do so with care as you will not know what its outcome is until it is over.

Is Slow to Change

Culture is built over years. When a change is made with the intent to change culture, that change will need to filter through the system. It will cause ripples and eddies as the system tries to find its new equilibrium. It will change parts of the system that feed back into the culture. This feedback will in turn cause more ripples. You must be patient and wait for those perturbations to die out and a new normal to be established. Determining success or failure while the system is still oscillating is a sure-fire way to miss the truth.


In summary, a transformation is an attempted migration of a system from one equilibrium to another. The hope of that transition is that the company ends in a better place than where they started. The problem is there are a lot of things to consider. Rewards, current structure, culture, the overall system, the sub-systems, and the emotions at play in all of this. If we seek a simple answer, we are almost certain to destroy the solution we are migrating towards. However, any answer that will work is almost guaranteed to be more complicated than any person or team to handle. This means that instead of simple solutions we need simple ways to get feedback, simple ways to allow us to fail on small scales. Most of all, we need to respect the current context, and those who are working in that context. Only once these things are done do we have a hope of success.

This post is licensed under CC BY 4.0 by the author.