It’s 9am in the office. You can hear the clicking of mice and keyboards, as well as mumbling conversations at the water cooler. The topics range from last night’s Champions League Semi Finals to the quality of the important feature the team pushed out yesterday. Suddenly, the voice of the Agile Coach echoes through the office: “Come on guys, it’s already a minute late for the Daily Stand-Up. You guys don’t want to do push-ups again, right?”
One by one, the team members lurch towards one screen to do the Daily Scrum. They need to do it hybrid because Joe and Anna are working from home. After exactly 15 minutes, everyone informed each other about their work status and what they are planning to do today. And of course, nobody has an impediment.
Agile compliance
The organization claims to be Agile since they have Daily Scrums and Post-Its. Their Agile Coach is taking care of it. But if we asked Anna right after the Daily Scrum whether she knows what Joe is working on, she might say something like: “No, but it is not relevant. He is a backend developer and I am a frontend developer. I can check his API later on.”
While the organization, the maturity assessment, or even the OKRs might technically say that the company is Agile, it’s not necessarily improving the team. The Agile values and principles promote self-organization to increase team effectiveness and efficiency. This is one of the core aspects of agility.
But how self-organized is a team if they need a coach to remind them at 9am to do the Daily Scrum? How self-organized is a team if individual members still don’t know what others are working on after the Daily Scrum? How does this help the team improve their decision-making to achieve higher effectiveness?
Focus on Resilience, not agility
The Agile industry and the notion of having an Agile Coach are deeply flawed. This is coming from an Agile Coach myself. Too often, we measure agility and its maturity by compliance with a process or methodology and not by outcomes or value creation.
The goal of your organization should NEVER be to implement Agile processes. Instead, the goal should be higher responsiveness or higher adaptability in the face of uncertainty. As an organization, you should not strive for a perfect Sprint Planning or Daily Scrum. You should be able to recover quickly from difficulties, since they are happening constantly in our complex world. In other words, the goal of your organization is not Agile, it is Resilience.
Higher resilience does not come through a process. It comes through removing everything that makes organizations less resilient. This sounds obvious, but many organizations do not know that. Too often, organizations focus on process implementation instead.
Ashby’s Law and Self-Organization
Ashby’s law of requisite variety states that in order for a system to be able to handle a certain type of problem, it needs to have a variety of possible responses equal to the variety of the problem. In other words, the more diverse the types of problems a system is likely to encounter, the more diverse the system’s responses need to be to effectively deal with those problems. This is especially important in complex systems, where a lack of variety in responses can lead to failure.
Compliance with Agile processes or frameworks can create the impression that we can control an organization and its teams through a single controlling instance. However, this contradicts Ashby’s law. Let’s oversimplify: The variety of problems within a team might be as high as the possible interactions within the team. For example, in a team of 3, there are 3 possible interactions. In a team of 6, there are 15 possible interactions (if I have not miscounted). Therefore, according to Ashby’s law, the only way to address the variety of problems within a team is through the variety of possible interactions. This cannot be done by a single node of control, but only through self-organization. This is similar to how ant colonies organize and regulate themselves, despite consisting of millions of ants.
If your organization calls out your Agile Coach as the “Agile police” or the Agile Coach primarily babysits teams, then your Agile Transformation has failed, or you started the transformation for all the wrong reasons. An Agile Coach’s skills are wasted when they are reduced to a babysitter or enforcer of imposed approaches.
The role of an Agile Coach
But an Agile Coach can provide valuable assistance. By offering an external perspective on the system and gaining an understanding of the dynamics of the team or organization, a coach can help individuals and teams navigate the uncertainties and unknown outcomes of their work. The Role of an Agile Coach should be that of an outside “voice of reason.” They can remind organizations and individuals of theories, knowledge, concepts, or practices that they may have forgotten in the midst of daily work. It is important to note that Agile Coaches should not work within the system and impose ways of working, as the law of requisite variety forbids it. However, as external consultants, they can provide valuable insights and recommendations.
Unfortunately, most Agile Coaches are unaware and unskilled to support teams to deal with the variety of problems. They are trained or certified in a certain way of working and therefore only know how to impose a certain framework on people. This is why, organizations become agile fatigue and Agile Coaches are more often seen as the Agile police.
