Agile Coaches limit the capability of teams and organizations to be agile
Agile Coaches, it’s Time to Learn from the DevOps Movement
Why Agile Coaches and Scrum Master became the new operations people back in 2005 and what to do about it.
Having Scrum Masters and Agile Coaches is great. Those jobs enjoy great popularity among companies on their way of being agile. Interestingly, many companies introducing those roles years ago still cannot claim to be agile. There are certainly many reasons why this is the case. Often, Agile Coaches, Scrum Masters, managers, and teams blame each other for not “having the right mindset” which supposedly makes it impossible for teams, organizational units, and whole organizations to be agile. One reason certainly is the missing integration of the huge body of knowledge on agile principles and practices into the daily work of organizations, teams, and individuals.
In this post, I want to take a closer look at the behavioral patterns that agile folks like Scrum Masters and Agile Coaches show and how that limits the ability of the organization of behaving in an agile way. I want to draw a parallel to the DevOps movement starting in 2009 and shed a light on similar behavioral patterns of operations folks which in turn sparked the need for DevOps. Let’s take a look at the structural changes the DevOps movement introduced that made it possible for teams to integrate the body of knowledge of operations.
I find it fascinating how many modern Agile Coaches and many operations people (Operators) back in the early 2000er years show a similar behavioral pattern. Being in that role for some time they often gathered quite some expertise in their respective field. They interact frequently with teams to get work done and to ship great products to the users. However, the expertise somehow in only shallowly transferred to the team. The capabilities don’t grow in the teams but remain with the experts.
I witnessed this pattern with ops people and with agile folks. With ops it sounded something like this: “We cannot bring this feature live without the deployment of ops.” and “We are still waiting for the DBA to grant us access to the user data database. That’s why we cannot make any progress here.” Interestingly it sounds almost the same when it comes to agile folks: “We should have that retrospective but our Scrum Master is on vacation.”, “We have that conflict between these two colleagues, but we cannot do anything about that because the Agile Coach has no time for us.” or “We definitely should have that cross-team collaboration workshop but this has to wait until the Agile Coach is back from his sick leave.”
For me, this sounds like being dependent on the Agile Coaches or Scrum Masters is an impediment to the flow of work and for good team collaboration. It was the same with the dependency on operations some years ago. I would argue that productively dealing with conflict, facilitating sessions to reflect and learn and structure one’s meetings is an essential capability of teams doing their job. There is no difference in having those “soft” capabilities and the capability of continuously deploying to production or monitor live software.
Tell me, and I’ll forget it. Show it to me and I’ll remember. Let me do it and I’ll keep it.
This quote, which is said to be from Confucius, describes the attitude of the Agile Coaches that we need to strive to overcome the limitations of current agile coaching.
The DevOps Movement — a source of inspiration
People in operations and development roles noticed that the division between dev and ops had become an impediment to flow. Thus people from dev and ops started the DevOps movement in 2009. In tight collaboration, operations-people and developers invented ingenious ways to strengthen the DevOps skills within teams and to support them with tools and infrastructure that made it increasingly easier to bear a load of operations duties while developing the application. Developers bridged the chasm to the realm of ops (and the other way around) to solve pressing problems they felt in their daily work. Teams wanted to be autonomous, feel more flow and self-efficacy and get more valuable stuff done faster.
Over time the teams became better at managing both the development part and the operations part of building a product. “You build it, you run it!” became a mantra of the modern product development teams. Operations changed gears and their attitude. They remained the experts for operations but with a different spin. They started to provide “infrastructure as code” and expertise to support product development teams with the tools and the skills to provision virtual servers, set up their release pipelines, and provided infrastructure to monitor and maintain the software in production. While the product development teams became more and more experienced in using the provided tools and infrastructure the operations teams became more and more experienced in providing the infrastructure and the underlying platform which made computing, monitoring and analytics more and more a “plug-and-play” commodity. This in turn massively increased the autonomy, adaptability, and speed of the product development teams. It also supported the product development teams to take more responsibility for their products which increased the sense of mastery, autonomy, purpose, and relatedness. In hindsight, it is obvious to me that this movement has been a huge success and a great gift for the world of product development.
Is Agile Coaching the new DevOps?
Why do I bore you with history lessons about the DevOps movement? Because I find it fascinating how similar this looks to me to the way we agile folks still act. Agile folks to some extent have become an impediment to the flow of work, the team’s autonomy and to value generations. I propose to let the agile folks also change gears and imagine a role description that enables product development teams and management roles to behave agile independently from their agile baby sitter. I propose that one measurement of expertise for an Agile Coach or Scrum Master shall be how well she enables people and organizations to act effectively. The expert is no longer the one who knows it all but who is most effective in making others effective. This — like in the DevOps movement — includes helping individuals to develop skills and to provide tools and infrastructure that makes it easier to act autonomously. It shall help teams and individuals to make effective use of agile principles and practices. This again shall support teams to become even more autonomous, feel even more flow and self-efficacy and get even more valuable stuff done faster. Agile folks have quite something to offer in order to solve those problems.
The expert is no longer the one who knows it all but who is most effective in making others effective.
In that sense, the agile folks don’t earn their value by being personally present with the team all the time but by having the skills and capabilities present in the team all the time. This in return will then again boost the sense of mastery, autonomy, purpose, and relatedness of the product developers.
Agile Coaches and Scrum Masters may formulate their offers to the product development teams in a sense that they solve actual problems by enabling the teams to solve the problems on their own, providing skills, tools, and infrastructure like the DevOps movement has done before.
This will never work!
In the following posts, I am going to take a closer look at how that might look like. But first I would like to devote your attention to some of the “BUTs” that are raised when I propose the thoughts above.
But agile coaching is complex and cannot be codified!
The matter of whether or not some form of tacit knowledge can be codified is under discussion for decades now and I am aware that only a small percentage of the coaches’ capabilities may be codified satisfyingly. Nevertheless, I remember that being said for the work of operations people around 20 years ago as well. Back then the work of the operations people was more witchcraft than something that possibly could have been codified, transformed into tools, or even be automated. But look where we are today. So much knowledge has been successfully transferred into something that can be used by teams at any time and without having to study those domains of knowledge for decades.
I am also aware that the work of an Agile Coach is complex and thus neither deterministic nor linear reproducible. However, is that true for every aspect of the agile folks’ daily work? I doubt it. It’s this claim that makes the agile folks stuck in the role of an expert limiting the autonomy of a team.
But it overwhelms teams and individuals
I’ve experienced the reaction of being overwhelmed by teams and managers alike when I proposed this train of thought written above. “I cannot do anymore!”, “How should we learn something so different from our development work?” or “We barely mastered the DevOps craft and now you want to add even more load to us?”.
I am aware that this sounds like a load that teams and managers cannot bear. I remember teams saying the same when it came to DevOps. I take those responses as an indicator that the expertise of agile folks still looks a lot like witchcraft or something completely unrelated to the current work of the product development team. And it is also a good indicator of the direction the development of that agile expertise is likely to take. Essential capabilities like planing, breaking down goals, facilitating meetings and workshops, making decisions quickly, resolving conflicts, facilitate learning, improve collaboratively, becoming faster and support product discovery are going to be more digestible and structurally supported very soon. Tools and playbooks on how to facilitate retrospectives and workshops are already clearing the path for more to come.
But this is going to break the team
In the early days of the DevOps movement especially the operations folks have been heavily concerned that the product development teams are going to “break production”. They have been afraid that the capabilities of the developers are insufficient to reliably and securely run production environments. In tiny steps, the risks of that time have been mitigated. Training on the job and quality assurance (like test automation and build tests) increased the reliability of code that was shipped to production.
In contrast to putting the success of the application at risk, the agile folks might put the success of the team at risk. That’s why the same tiny steps need to be taken to safely increase the teams’ autonomy and capability without breaking the team.
Like in product development and empirical management Agile Coaches and Scrum Masters need to constantly provide ‘products’ and constantly need to generate feedback if the provided products enable the teams and managers to act effectively in a complex environment.
Agile Coaches and Scrum Masters are normal people. They have traits and personality preferences like every other person out there which makes them not distinctly different from developers. I’ve known product developers who loved to also facilitate retrospectives of another team from time to time. I’ve known Product Owners who have been highly skilled in conflict resolution. I am certain that we will see a rich spectrum of hidden capabilities already sleeping in people with different roles that can be awakened with voluntariness and good support.
But this is not agile!
This pseudo-religious claim is not so easy to take. It refers to the first principle of the agile manifesto
Individuals and interactions over processes and tools
and indicates that it can’t be agile if the Agile Coaches start creating ‘infrastructure’ or ‘tools’ that support teams in being agile. The thoughts above are not meant to reduce agile coaching or the work of Scrum Masters to tool usage, applying check-lists or use blueprints. We’ve been there in the very early days of Scrum where we tried to force teams into a framework that has not been suitable for the situation of that team. I know that there is a thin line between just enforcing tools and supporting individuals and teams with tools and proven practices. It might take some time to find the right balance but it’s worthwhile trying. I don’t want the agile manifesto been taken hostage for something that limits the teams’ capability of delivering value independently.
Let me know what you think about this analogy between agile coaching and DevOps. How do you deal with being dependent on the work of agile folks?
Further Sources
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, Gene Kim
- The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Jez Humble, Patrick Debois, John Willis, John Allspaw
- State of DevOps Report 2019
- Agiles Coaching: Die neue Art, Teams zum Erfolg zu führen (German) von Judith Andresen
