The agility trend is gaining momentum: everyone is searching for "their" agility as a response to the potential disruption of their core business, as a magical remedy to accelerate time-to-market, or to conquer future markets ahead of competitors. However, beyond the solemn statements of executive committees, the agile centers mushrooming, and trains launching at full speed, it is evident that the business-as-usual (processes, command and control, P&L...) often retains its rights. So, if the word "transformation" implies a journey, it may be that this journey towards the agile land—a kind of New World—passes through areas where currents are contrary and reefs are visible.
The sudden dynamic of many large organizations wishing to "transform" towards and through agility is quite exciting. It is rooted in the recognition of the limitations of command and control, especially in intellectual professions where insecurity towards individuals first paralyzes their cognitive functions.
Organizations are now seeking a new management paradigm that prioritizes collaboration and value creation for the benefit of the customer, using collective intelligence and continuous improvement.
In complex systems, there are manifest desires for transformation
This movement is touching because it often seems deep and sincere from individuals at all levels of organizational management who desire and work towards it.
However, in heavily regulated professional worlds, it is challenging to defuse processes and control tools governing sets of several hundred or thousand people at once. The existing control systems do not hesitate to remind everyone of their rights if attempts at disruption are too drastic.
Indeed, while there may be room for change at the team level (altering interactions, changing decision-making methods, making work visible, and improving together by learning from mistakes)... is this still true when considering interactions between teams? With their management? With the rest of the organization? One of the key questions in implementing agility seems to lie here.
Structural habits resist "disruption"
Process one day, process always... To address the complexity of interactions between teams moving towards agility, frameworks—often elegant—have emerged and received a warm welcome from "organizational" populations: the era of scaled agility has arrived. Designed for projects involving more than a hundred people, if not more, these frameworks offer a formalized organization of information transmission and decision-making to provide visibility and security for (large) agile projects... according to what visibility and security mean in the world of processes and indicators.
What are the three characteristics of French cooking ? Butter, butter and butter.
Where the problem arises, at least from the perspective of agility, is not so much in the intrinsic quality of these processes but in the fact that they respond in the negative to all the characteristics of project management in a pre-agile world: production milestones, predictability, ROI control... It is easy to understand the enthusiasm they can generate in traditional management circles. To the point that major consulting firms [armed with their expertise in agility acquired through practice...] end up custom-building frameworks adapted to the culture of clients. Frameworks somewhat marked by "Command & Control," but with all the agile terms included.
And the three characteristics of 20th Century management ? Reporting, reporting and reporting.
As you might have understood, the intervention zones of agile coaches are rarely "all black or all white." They are more likely in gray areas, where some actors, some of the time, and on certain subjects are favorable or open to change, while others do not want to go there, do not believe in it, mock it, and, above all, fear it.
The reasons for this fear can stem from various factors:
And finally, the experience of a diluted version of the agile proposal (far from the Agile Manifesto) that becomes tasteless and bland frameworks, where the MOE is replaced by the Product Owner (Proxy-PO, of course), and Project Manager by Scrum Master, with story points as elements of reporting and surveillance.
In the set-up outlined above, it seems to me that agile coaches today can adopt three main postures:
A nuanced posture that involves dealing with reality while not missing an opportunity to eliminate unnecessary processes and advance team autonomy.
Let's examine these postures one by one.
The uncompromising posture certainly has its advocates. It has the merit of clarity and courage. However, one can also question its coherence with the content of our profession itself. If the ground is completely ready, why would an agile coach be needed to help the actors? And if we have to wait for a field to be completely ready for a transformation (alignment of the executive committee, top management, middle management, proximity managers, teams...), will it ever happen?
The "provider" posture is more accommodating (and safer for extending missions!). But if, by being accommodating, it merely reproduces existing patterns, then it will no longer be agile or transformative. It is also, for the coach-consultants who practice it, a dead end to any form of learning, experimentation, waiting for the arrival of the "next managerial trend." It quickly collides with the values of transparency and courage that underlie healthy interactions.
The nuanced posture requires an innovative anchoring compared to the traditional practice of consulting professions. It takes into account the reality (the famous structure, interactions, and culture of sociologists of the company) and, at the same time, seizes every possible opportunity to twist and eliminate the sclerotic practices inherited from the organization, replacing them with simplified systems that produce more value than reporting. In this posture, every identification of a practice that creates waste, especially organizationally, and the implementation of a counter-practice also becomes an opportunity to TEST something different.
Many agile coaches who provide transformation support to teams often find themselves navigating at the intersection of currents, in marginal places intersecting the practices of an Old World and a world under invention, in gray areas where the desire for change is present but the legacy of past managerial reflexes remains operational.
Are there intervention conditions that would allow the agile coach to navigate in these troubled waters without risking shipwreck on the reefs?
I propose to make a few suggestions (to be completed, of course!).
Clarity on the Posture
The agile coach must be clear—at a minimum—with himself about his real capacity to intervene on the proposed ground and the posture he chooses to adopt. Seeking advice from colleagues, going through the filter of supervision can be effective means to ensure that one is not deceiving oneself. Or deceiving the teams. Or the client. Or all three at once!
Hold a clear institutional mandate (and respect it)
Why embark on workshops, abandoning or modifying processes, providing support, beyond the expressed desire for transformation by the collective? This attitude would be dangerous not only for the agile coach but also for the individuals and teams being supported. It might also be wise to have formalized the coaching contract between the agile coach, the team, and the management. (This point will be the subject of a future post).
Understand the situations
Understanding, or rather attempting to understand to the best of one's ability, the organizations in which one operates is a prerequisite for intervention. This is sometimes left aside due to the prescriptive dimension of certain approaches. Is the goal to "switch to Scrum" (Kanban, Safe, Less...) or to use Scrum (Kanban, Safe, Less) as a framework to allow a collective to adopt an agile mindset for the purpose of developing its learning capacity and delivered value? It may be necessary to work with organizational reading tools to understand interactions before claiming to "transform" them.
Be transparent in learning actions (before, during, after)
"I suggest doing this... to experiment with that," "We are experiencing this (positively, negatively)... and it teaches us that," "We did this... (what worked, what didn't) and it taught us that"... Practicing transparency with teams and individuals afterward sets an example and presents oneself with humility in the face of terrain and people. Sometimes, in certain cases, it is good to let teams "discover," even intentionally blur the lines, and in this case, let's do it. But without losing sight of the dimension of test & learn, experimentation, and having the humility to be part of the system.
Adopt an "agile" mode of interaction
Shouldn't we start by interacting in a new way with our clients, partners, and sponsors before claiming to accompany a transformation of relationships? Some examples: prefer face-to-face interviews, do not participate in email discussions, minimize PowerPoint presentations, use physical visual aids, scribbling, drawing. Take advantage of meetings to deploy new modes of discussion... in short, break the codes from the very beginning. And, above all, continue afterward! Imagining that it would be possible to deploy an agile culture outside an agile approach is as incongruous as it is unrealistic.
Respect people
Often, the agile coach is an external element to the organization, somewhat like a consultant who comes to deploy operational knowledge within teams and their management. However, the juxtaposition of the two words "coach" and "agile" can be an opportunity to rethink our support, at least for those who have been "consultants" in past lives.
--> A coach? He guides the person or organization where they want to go. Not where the coach would like them to go.
--> Agile? With positive interactions, aiming for concrete and measurable results, practicing continuous improvement. Prioritizing interactions... etc.
Respect organizations
The grounds we accompany have their flaws, undoubtedly. But also their qualities. One of them is to open up to different practices and force themselves to step out of their comfort zone. The other is to function and produce value, as "imperfect, heavy, procedural, anxiety-inducing" as they may be. In short: we have the right to arrive with a modest posture and not heavily criticize the systems we are asked to help.
Originally (a few dozen months ago...), agile coaches were recruited from experienced Agile practitioners who could accompany teams and individuals on a journey they had already undertaken. But we can now observe that this profession (still in the process of creation) is practiced very heterogeneously by individuals from very different backgrounds.
This has the advantage of respecting the diversity of situations and approaches and not confining "Agile" to a specific group, which would be an unemergent process in itself. And the disadvantage of not knowing too well what to expect from the work of the agile coach, that is, being able to project all kinds of fantasies onto them or expecting anything and everything: a preacher, an agile change driver, a framework unroller, a work psychologist...
Our profession would benefit from structuring itself around key concepts, with both enough latitude to respect enriching approaches from diverse backgrounds and also an ethical and methodological framework to provide visibility and coherence to our professions, made of patience and action, silence, and words, gestures and non-gestures.
And you? What do you think?