It is worse than herding cats because cats do not have strong opinions about what a cat is.

The Naming Problem

The role has more titles than responsibilities. This is because the role was invented by organisations who had already hired agile coaches and discovered that agile coaches, left to their own devices, will coach in seventeen different directions simultaneously. Someone needed to align the coaches. That someone needed a title. The title needed to sound more senior than “coach” but less threatening than “manager” — because you cannot manage agile coaches, you can only facilitate their self-organisation, which is a phrase that means “manage them but never use that word.”

The title changes approximately every eighteen months, driven by LinkedIn trends, conference keynote themes, and the ongoing need to distinguish oneself from the two hundred other people in the same city with the same role and a different name for it. A single practitioner may hold four different titles in three years without changing employer, desk, or job description.

The title is the only thing that transforms more often than the organisation.

The Fifteen Opinions Problem

Talk to ten Agile Coaches. Get fifteen opinions. This is not an exaggeration. This is a census.

The fundamental problem of managing agile coaches is that each coach has a deeply held, experience-forged, certification-backed opinion about how teams should be organised, and these opinions contradict each other with the precision of a logic puzzle:

• Coach A believes teams should be cross-functional and product-aligned

• Coach B believes teams should be component-based with clear ownership boundaries

• Coach C believes teams should be temporary and project-based, dissolving after each initiative

• Coach A and Coach B agree that Coach C is wrong

• Coach C agrees that Coach A and Coach B are wrong

• Coaches D through J have positions that are variations of the above, plus three novel approaches they read about at a conference

• The Transformation Lead must create a single, coherent team topology from this

Now multiply this by every question a transformation involves: How long should a sprint be? (Two weeks. Three weeks. No sprints. Depends on the team. Depends on the work. One week but only for the first three months.) Should we use story points? (Yes. No. T-shirt sizes. Flow metrics. Cycle time only. Story points but rename them.) Should we do SAFe? (Yes. Absolutely not. Parts of it. Only the PI Planning. Never the PI Planning. What’s SAFe?)

The Transformation Lead’s job is to synthesise fifteen contradictory opinions into a coherent strategy, implement the strategy with people who disagree with it on principle, and then facilitate a Retrospective about why the implementation isn’t working — facilitated by the very people who disagreed with it, who will use the retrospective to propose their original opinion again.

The Irony

The supreme irony of the Agile Transformation Lead role is this: the people whose professional expertise is helping teams collaborate, align, and self-organise are — as a team — nearly impossible to get to collaborate, align, or self-organise.

Every coach has a model for how teams work. Every coach has facilitated hundreds of sessions on psychological safety, working agreements, and team norms. Every coach can draw the Tuckman model on a whiteboard with their eyes closed — forming, storming, norming, performing. Every coach knows the theory.

The theory does not survive contact with a room full of coaches.

Because a team of agile coaches is a team where every member is simultaneously a player and a referee. Every decision is also a coaching moment. Every disagreement is also a facilitation opportunity. Every meeting has twelve people who know exactly how the meeting should be run, and twelve different opinions about how that is. The storming phase of a coaching team does not end. It becomes the culture.

The Transformation Lead sits in the middle of this, holding fifteen leashes attached to fifteen professionals who are each trying to coach the person holding the leash.

The Cat Theorem

There exists an observed phenomenon — documented across multiple organisations, multiple countries, and at least one frustrated LinkedIn post — which may be stated formally as:

The Cat Theorem of Agile Coaching: The difficulty of organising a group of agile coaches into a functioning team is proportional to the square of the number of coaches, multiplied by the number of coaching certifications in the room.

This is because each certification comes with its own framework, its own vocabulary, its own model of how teams work, and its own opinion about whether the other certifications are valid. A room containing one Certified Scrum Master, one ICAgile coach, one SAFe Program Consultant, and one Kanban practitioner is not a team. It is a panel discussion that never ends.

The corollary: anyone who has successfully managed a team of agile coaches for more than two years will, upon retirement, acquire actual cats — finding them restful by comparison. riclib managed coaching teams for years. riclib now has Oskar and Mia. The causation is not proven. The correlation is perfect.

Oskar does not have opinions about sprint length. Mia does not propose alternative facilitation techniques during dinner. Both occasionally knock things off tables, but they do so without first requesting a retrospective about the table’s structural integrity. After years of herding coaches, riclib found that herding actual cats was a lateral move with better working conditions.

The Transformation Lead’s Toolkit

The tools available to the Transformation Lead are, in order of effectiveness:

1. Wine — not officially in any framework, but present at every offsite

2. The One-on-One — where the real alignment happens, because coaches will say things privately that they will never concede in a group

3. The External Consultant — occasionally, the only way to resolve a coaching deadlock is to bring in someone from outside. This is The Consultant pattern: paying a stranger to say the thing everyone already knows, because the stranger has no factional allegiance

4. Attrition — some coaches leave. The remaining team becomes more coherent. This is Conway’s Law applied to the coaching team: the team’s communication structure eventually simplifies to match the opinions of whoever stayed longest

5. Giving up and becoming a Solo Developer — see below

The Exit

The Transformation Lead role has one of the highest attrition rates in the agile industry. This is not because the work is unimportant. It is because the work is the organisational equivalent of being a marriage counsellor for a polyamorous commune where everyone has a PhD in relationships.

The exit paths are:

• Back to coaching — having learned that leading coaches is harder than coaching teams

• Into product — having learned that building things is more satisfying than helping people argue about how to build things

• Into consulting — having learned that the same dysfunction, experienced at arm’s length and billed hourly, is more tolerable

• Into a completely different field — having learned

• Into cat ownership — having learned that the herding instinct, once developed, demands an outlet, but the outlet no longer needs to have opinions

Measured Characteristics

• Alternative job titles for this role: 23+ (and counting)

• Average tenure in role: 18 months

• Coaches managed: 5–15

• Opinions per coach: 1.5 (minimum)

• Contradictory opinions per 10 coaches: 15

• Frameworks represented in an average coaching team: 4

• Certifications in an average coaching team: 27

• Agreement on sprint length: never achieved

• Agreement on story points: theoretically impossible

• Retrospectives about why coaches can’t agree: recursive

• Cats acquired post-retirement: 2 (Oskar and Mia)

• Oskar’s opinions on sprint length: 0

• Mia’s opinions on sprint length: 0

• Mia’s opinions on knocking things off tables: strong

• Improvement over coaching team: significant

• Lateral move with better working conditions: confirmed

See Also

• Agile Coach

• Agile

• SAFe

• Transformation Initiative

• Reorg

• Enterprise Agility

• Conway’s Law

• The Consultant

• Solo Developer

• The Caffeinated Squirrel

To listen to the whole conversation, make sure to subscribe to the podcast with the link below or search for it on your podcast client!

By providing a quick and easy way to gather feedback and identify areas for improvement, the 30 second retro encourages open communication and collaboration among team members.

It’s a simple process that can be repeated regularly to continuously improve the quality of your meetings. Watch the video to learn more about how this technique can benefit your team and help you achieve greater success.

Steps:

At the end of your meeting walk to the nearest flip chart or whiteboard.

1. Draw a scale from five to one.

2. Ask the first participant how valuable the meeting was.

3. Put your hand next to the number they give and ask how to make it one point higher.

4. Draw a diagonal line from the given number to the next one and write the feedback on top.

5. Repeat with the next participant.

6. Choose the most common feedback and highlight it.

7. Implement the feedback for the next meeting.

Repeat the process tweaking the question so it doesn’t get boring. You will se dramatic improvements to the meeting.

Zawadi recommends understanding why the CEO wants to make the company more agile. Often, it is because of issues such as slowness, red tape, or inefficiencies in certain areas of the organization. By aligning on these problems, a more effective and efficient approach can be taken to make the organization more agile.

If you’re curious about how to approach the question of making your organization more agile, watch this video to learn more about Zawadi’s approach. By understanding the underlying problems and aligning on a strategy to address them, you can make your organization more agile and efficient.

Both Sam and Ricardo have been working with Agile for decades, but they came at it from different perspectives. Ricardo was a troubleshooter who naturally fell into Agile practices, while Sam approached Agile from a delivery management perspective. Both found success in working in short cycles and letting teams plan their own work.

However, they both noticed a trend in the Agile community, particularly in the Scrum community, of dismissing project managers and insisting that Scrum was the only way to do Agile. This narrow-minded approach turned many people away from Agile, leading Sam to found Agnostic Agile.