Do Agile Change Agents Know how to Manage? Do They Have to Know?
Agile change agents are managers. They are supposed to manage.
Over the last years as an agile consultant and agile coach I’ve come to the understanding that agile change agents (agile coaches, Scrum Master, Kanban coaches, etc.) are managers in every aspect of that profession. It took me quite some time to realize that the crusade by the early adopters of an agile way of working against the whole caste of mangers was a shadow fight. A shadow fight based on implicit assumptions on what managers are and what they do. In this post, I want to outline why agile change agents are managers themselves. Moreover, I take a closer look at what it means to manage and if agile change agents actually do it adequately.
First of all, let me make clear that I don’t support the crusade on management and managers. I also don’t want to distinguish between managers and leaders which has been done way too frequently over the last years. The rejection of managers and the glorification of leaders stems from collated experience and negative narratives almost everybody knows to tell. Those narratives are so frequently told because almost everybody has experienced at least one archetype of a bad manager once. However, almost everybody has experienced sour milk or stinky air and did not conclude that milk has to be sour and air has to be stinky. Management is not supposed to make the life of people miserable, although some of you might disagree here. But if making the life of people miserable is not the essence of management what is it then?
The essence of management
“The essence of management is recognizing the need for change, then initiating, controlling, and directing it, and solving the problems along the way. If it were not so, managers wouldn’t be needed — only babysitters.” I am thankful to H. William Dettmer to point out the responsibility of management so explicitly. All the negative feelings and the open wounds aside that is what management is all about. The means of management is to make humans productive. Management is about change.
Management constantly answers three questions: 1. What to change? 2. To what to change to? 3. How to cause the change?
If management is all about change and agile change agents are there to initiate and accompany change then both roles are supposed to do the same. Be clear that I don’t talk about hierarchies, status symbols or bad behavior of some managers. I talk about the purpose of management. Agile change agents and managers share the same purpose, to check if a change is needed and to make the change possible.
Do agile change agents know how to manage?
Whether you call it management or not, agile change agents are supposed to cause change. They help people within organizations to inspect and adapt. And that leads to a lot of change. However, change has to be aimed in order to be effective. But aimed towards what? To be agile, right? No! That can never be the right answer. Change has to be aimed toward the goal of the organization.
Is “being agile” not a proper goal? No, of course not. Being agile can only be a mean in order to achieve a specific goal. This goal is very often some sort of “value delivery” to the outside world or “to increase the bottom line”. The deplorable fact I’ve experienced very often is that agile change agents don’t know this specific goal of their organization, or even worse they are personally not in line with the organization’s goal. They know that they have been hired to “implement agile” — whatever that means. Sometimes not even the ones who ‘require’ agile know what the goal of the organization is and how being agile might help them to accomplish that goal.
No goal, no meaningful change, no management
If you don’t know the goal of the organization you obviously can still cause a lot of change. However, this change is meaningless and most of the time even harmful. Harmful, because this change often creates stress, resistance, and conflict which ultimately limits the capability of an organization to deliver value. If you take a minute to reflect on how many ‘change initiatives’ you have witnessed in your professional life, you might understand what I am talking about.
Agile change agents often complain that the whole organization and almost all of its people are change-resistant. But is that really the case? Maybe the people in the organization recognize that this change is not going to create any significant improvement. People support change if it’s not too radical and understandable related to the goal. People support change if they can see the benefits, not only for themselves but also for the whole organization.
This also means that agile change agents have to transparently communicate the goal of the organization and link every ‘agile intervention’ they make tightly to this goal. Easier said than done, you say? Right.
A first good step might be to exactly define what organization (in other words what ‘system’) you would like to change. Every system and thus every organization has a goal. The goal is the purpose of that system. When I use the term “goal” I don’t mean a SMART goal, I mean the true purpose of the organization. Sometimes this is bluntly to create money for its owners, now and in the future. Sometimes it is something much more inspiring.
In an organization, you usually have one or more owners. An organization (system) doesn’t have to be a whole company. A department or team can be an organization (system) as well. The owner of the organization determines the goal. As an agile change agent, you might want to map your own sphere of influence with the boundaries of that organization.
This actually might take some time. However, from a perspective of change, this is mandatory. Otherwise, if your change effort is not directly linked to the goal of the organization, you can never be certain that your change is effective.
Find out what to change
If we know the goal of the organization and we are certain that change is necessary, we eventually get to the point where we ask: What do we have to change in order to get closer towards our goal?
To figure out what to change is not an easy task and requires intuition and experience to be performed well. However, if we don’t find the leverage point at which the change is truly effective, we are going to be utilized with our change interventions all the time without knowing if we are really doing any good for the overall system. Intuition and experience are the reasons why you need the full cooperation of the organization’s owner and the people within that organization. If the agile change agent lacks the necessary experience and intuition, those people have it.
You might say: “Well, isn’t it common sense that agile change agents have to find out what to change before they start changing?” I agree. It is commons sense. However, far too often common practice seems to be that agile change agents change almost everything they can or dislike but not what they have to in order to be effective. Don’t get me wrong, I appreciate passion to cause change for the better, however, when I see random agile intervention tools like this one, I have the feeling that this kind of agile change is arbitrary. Does it increase your bottom line results if you force teams to apply agile practices well? I have my doubts. Again, all your agile change interventions have to be effective. Which means nothing else than being directly related to the goal of the organization.
If you cause change be sure it is worth the effort and costs — remember the “J-curve effect”. If agile change agents don’t make a significant difference in their organizations they might get repelled sooner or later or, even worse, they are going to perform some sort of agile theatre. In the past, we have seen this quite similar to the Kaizen Movement. Back then this movement caused many simultaneous changes allover entire companies but seldom created significant effects in a short period of time, which ultimately and regrettably led to the slow starvation of most of the Kaizen initiatives.
All of this leads to a simple conclusion. An agile intervention is only significant and thus useful at the root cause of the organization’s problems. This root cause will be the limiting factor for the organization to achieve its goal. In the Theory of Constraints, this limiting factor is called constraint. If agile change agents are able to find the organization’s constraint, they find the spot where their practices can be used most effectively.
Let’s take a look at Skype. Tony Grout and Chris Matts tried a lot of ‘agile stuff’ there to improve the situation for a huge amount of teams. It took them quite some time to figure out that it is not helpful to throw all your agile practices on the wall to see what sticks. In the end, they found some effective interventions that changed the whole organization towards the goal and thus for the better.
This makes clear that agile change agents need to learn how to analyze their organization and figure out what to change. To shoot from the hip, as I myself have done it for years, is not appropriate and causes more harm than good.
Agile change agents are confronted with all sorts of problems all the time. It is necessary and hard at the same time to restrain yourself from giving all sorts of good advice immediately. From my experience, none of the problems that are thrown at you is the true root cause that actually needs the agile change agents full attention. Those ‘problems’ are more likely ‘undesirable effects’ of the core problem, the root cause. To find the root cause takes some thinking and often visualization. The Theory of Constraint Logical Thinking Process might be a nice tool to put into the agile toolbox. This Thinking Process makes it easier to identify the organization’s constraint and communicate the need to cause a change right there. I want to encourage the agile change agents to take their time to find the spot at which a change is effective. Avoid the constant firefighting that is inevitable if you don’t understand the true problem to its full extent. Avoid the situation where you stress yourself and the colleagues within your organization with change that will not be effective since it aims at the wrong target.
Find out toward what to change to
Let’s assume that we found the root cause, the organization’s constraint. The next no less difficult question is ‘In which direction do we have to change our identified core problem?’.
In the working environment of agile change agents, we deal with knowledge work most of the time. In knowledge work, the core problem or constraint is usually no physical bottleneck, like those on the factory floor. The core problems are often (implicit) policies, habits which are no longer appropriate or fundamental assumptions that unspoken guide decision making.
Although I raised the suspicion that agile change agents have only few management skills in finding the right thing to change, I’m confident that they know in which direction a constraint has to be changed to in order to be effective in terms of the organization’s goal. They have plenty of experience in using agile practices and measures to change existing policies, habits and assumptions. So, reflecting on my starting question: I think that in this point agile change agents generally know how to manage.
However, one flaw has been made over and over again by agile change agents all over the world, and that is to blindly apply agile concepts regardless of the environment in which they should support the organization in achieving its goal. It is dangerous if agile change agents take practices and methods from one organization and implement them to a different organization without translating those practices and methods to the new environment. How often did I hear the sentence “We apply the Spotify model” as a starting point for a huge organizational change. This is dangerous, because “there is a difference between an application and the fundamental concepts on which the application is based. The fundamental concepts are generic; the application is the translation of the concepts to a specific environment.”* This non-trivial translation is also part of management which should be seriously taken into consideration by agile change agents. “What we have to bear in mind is that the application makes assumptions (sometimes hidden assumptions) about the environment. We should not expect an application to work in environments for which its assumptions are not valid.”* When agile change agents define to what an identified constraint needs to be changed it is worth the effort to explicitly verbalize the underlining assumptions. That can save effort and frustration on the third step of management.
Define how to cause the change
Agile change agents know a good deal of how to cause change. They usually have a broad box of methods, interventions, games, facilitation techniques, workshops formats and tools of all sorts to create settings to inspect, reflect, learn and alter behavior in a fail-safe environment. I have absolutely no doubt that agile change agents know the last of the three management steps. Ironically, agile change agents often know this third step far better than ‘classic managers’ who still too often rely on change announcements as a preferred instrument to cause change.
Don’t forget that the owner of the organization often is — without any blame — heavily involved in the organizations' constraint. This makes him an essential part of the solution and thus of the change. That’s why it is so important that agile change agents work closely together with them, even if this means to move away a little bit from the teams.
Do it again and again
The three steps of management — 1. What to change? 2. To what to change to? 3. How to cause the change? — are like the Deming cycle a process of ongoing improvement. Which again is the essence of management. Fortunately, agile change agents have that engraved in their mindset. They know this from agile product delivery. They know how to deliver increments of change frequently and continuously, starting with the highest value first. This fundamental attitude is part of agile management frameworks like Scrum or Kanban and is highly effective. Combining those frameworks with the management framework of Theory of Constraints makes it possible to cause change with high impact and little friction and that on a continuous basis.
Summary: Do agile change agents need to know how to manage? And do they know it?
Agile change agents and agile coaches are managers. Managers need to know how to manage. Managing means causing effective change at the right time with a direct impact on the organization’s goal. Managing means knowing what to change, to what to change to and how to cause change. Many agile change agents currently don’t precisely know what to change in order to be effective, which often leads to a lot of change, causing resistance, frustration, and harm for the organization.
As soon as they know what to change agile change agents know quite well to what to change to as long as they translate fundamental concepts of their profession to the environment of the application.
In contrast to many ‘classic managers’, agile change agents know a lot about how to cause change. They are experienced and advanced in changing policies and educating colleagues, which is a powerful management skill.
From my perspective, agile change agents partly know how to manage. They could make a real difference in the organizations when they learn to find the right spot at which they can aim their change interventions. The Theory of Constraints calls that spot constraint and the Logical Thinking Process helps to find that constraint and guide the change effort to be highly effective.
References
- Goldratt: The Goal: A Process of Ongoing Improvement
- Goldratt: What Is This Thing Called Theory of Constraints
- Goldratt: It’s not luck
- Goldratt: Beyond the Goal
- McMullen: Introduction to the Theory of Constraints (TOC) Management System
- Dettmer: The Logical Thinking Process: A Systems Approach to Complex Problem Solving
- Börebäck: The Future Reality or “Finding Solutions” DevOps movement with Logical Thinking Process
- Forte: Theory of Constraints 107: Identifying the Constraint