The pandemic has put a slight brake on the "agile coach mania." However, the demand for this category of consultants continues unabated. I believe I won't lack support by pointing out that the success of the SAFe ecosystem is not unrelated to this (as evidenced by the number of SAFe Practitioner Consultants). Like mushrooms in the fall, they have emerged in the last quarter.
Even if these "coaches" were mostly consultants deploying participatory work methods, the magical dimension of their titles entices organizations with the promise of brighter days ahead. As expected, the business system adapts (with a lot of agility...) to this demand. Training institutes provide training, even remotely; certification bodies certify; candidates, both friendly and convinced coaches, are presented in the marketplace by ESNs or as "independents." Finally, the IT departments of companies entrust the task of selecting the so-called agile coaches to their procurement teams to deploy them with the teams.
The culture of process, being resilient, is one of the challenges for organizations that are "transitioning to agility." This involves measuring, with clever indicators, the agility rate of teams (Agility Rate?), or prosaically, the percentage of teams converted to the practice of sprints, PI, retro planning, and other daily activities. This allows, by compiling XXL files, to announce to executive committees that, a few hundred days/coaches/millions later, the majority of teams are finally "agile."
This situation seems quite similar to those of previous large-scale organizational transformation frenzies: CMMI, Prince 2, "Lean" Six Sigma. It follows, in my opinion, a similar pattern: to address a problem, a regulatory solution is found. And today's solution has a name: agility. Except that, this time, the solution will be effectively deployed by knowledgeable individuals with the teams. Not thanks to "change management" but thanks to "coaching." But, concretely, what does this really change? Is the delivery smoother, the quality more stable, the customers served more quickly? And do the teams tell you that there is a difference? And your managers; are they more serene and confident? And, simply, are you measuring these changes? If not, it is possible that you have made a request for no change. Improve my processes... but, especially, without changing them.
In fact, as other solutions have been powerless to solve the problems, logic dictates that more of the same things will lead to more of the same results. Industrialized agility sold in dozens of packages does not one iota take organizations out of their entropies.
As Watzlawick rightly says: the problem is the solution.
This dark picture is still illuminated by patches of light. Here and there, sometimes in surprising places, organizations are taking advantage of this agility shock to shift from cost control to value creation, from self-concern to customer orientation. And this, in a process that goes beyond mere incantation.
We agile coaches may have something to do with it, but let's be honest. It is in the teams—through their inherent dynamism—and in the sponsor—through the protection he provides to the transformation—that lie the ingredients for successful profound change.
Claiming otherwise is to believe that "coached" teams, without adequate protection, could grant themselves the true-false permission to do things differently while continuing to meet the same obligations. This resembles the classic double-bind injunctions that litter the lives of organizations that grind managers like Colombian coffee: "do more with less... but prioritize innovation"; "scrupulously follow processes and rules... but think outside the box." Or if you prefer: "change... but especially by doing it like before." To illustrate the dynamics, I share the memory of a manager in a large organization who had put this formula of absolute transparency in his email signature, "Priority to transformation... And right after, transformation"
From my experiences in agile territories, I derive a beginning of a generic certainty. Indeed, the transition to agility is a real change that requires space. Space-time to be able to try and experiment, space-security to search and make mistakes, conceptual space to admit that what is done today must be abandoned.
And the only actor who has the political power to "allow" and "protect" this space is the leader of the organization. As the formula goes: "Change management is first the change in conduct ©[CCC]" (but well, if you have an example of an ecosystem in which a radical change has occurred without the support of the sponsor, I am very interested in the reference!).
Dear sponsors and leaders: if you confine your agile transformation to a single level of the system, without including budgetary control or managerial transformation, without allowing the system to rebuild itself... there is no reason for the change to go beyond its buzzwords: squads, tribes, RTE, disruption, digital transformation, blah-blah, and so on. But how to do it then? As it is difficult to give generic prescriptions to cases that are all unique, I can only mention the following steps:
Ask yourself "why." Why do we want to change? What is at stake? Why will we "die" if we don't do it? And not the "sense of urgency" of Grandpa Kotter, huh. A real reason. If there is no reason? Especially, don't touch anything.
Then move on to what. What are we doing today that leads us to failure? What does it bring us? What does it allow us to hide? What discussions do we avoid thanks to this?
And finally, to how. How will we "lift" what bothers us? Rather than adding new constraints to these poor teams that can't take it anymore... to test new ways of doing things.
To say it (too) pompously, the detection of our non-change drivers is a prerequisite for a change request rid of its homeostasis. Or, in simpler terms: we must highlight the reasons not to change in order to hope to see a real change occur.
This is where organizational coaching support comes in—to highlight this non-request and then define the permissions and changes in action that will—perhaps—initiate a change process. After whether this change is agile or not agile, it depends on what you produce, its cycle, its complexity.
And if, ultimately, you prefer no change, that's okay too.
And you, how will you request your future non-change?
(Revised and updated version of an article from March 2020 titled "Finally, your transformation is at a standstill")