Can I Sell You A New Agile Term?

This is a guest blog by Jay Alphey (see bio below).

The profit motive in Agile has driven industries in certification, organisation change (“agile transformation”) and numerous frameworks. These tend to increase complexity, which means more to sell and more reliance on “experts” rather than leaders. Of course this problem isn’t unique to Agile – the same challenges have hit classical project management for years.

I was reading an article by McKinsey on building agile capability in an organisation. It sounded very promising: "Growing your own agility coaches to adopt new ways of working".

I often read McKinsey articles, especially on Agile. They tell you a lot about what Agile looks like to big, traditional organisations. McKinsey, of course, is selling consulting solutions to big companies, many with little idea about Agile.

Let’s look at this article to see how “selling Agile” can lead to a potentially complicated and obscured approach.

Do we need a new role?

A central premise of the article is that we need to introduce a new role in Agile.

"Where a large organization has hundreds or thousands of small agile teams, it will be impractical to have a scrum master embedded into every single team", the article states.

That kind of sweeping statement might be better with some justification. We are happy to have developers in every team, so we presumably could have Scrum Masters in each team if we wanted. Why is that “impractical”? Presumably because there’s some economy of scale and Scrum Masters could work across several teams.

That’s scarcely news. I’d guess that most organisations that have scaled Scrum beyond one team have found that Scrum Masters can work across several teams. Scrum doesn’t directly suggest this – the Scrum Guide is written to cover only a single team, single product model. But it’s a frequently used scaling model. Ken Schwaber, as one of the inventors of Scrum (and very much a Scrum purist) describes the scrum.org “Advanced” Scrum Master qualification as below:

"Professional Scrum Master II (PSM II)– knows how to be Scrum Master for one or more Scrum teams."

Existing scaling approaches tend to take this approach of sharing Scrum Masters rather than rigidly replicating the Scrum model. According Scaled Agile (SAFe): "At Enterprise scale, it can be a challenge to sell the need for a full-time Scrum Master for each Agile team

The McKinsey article then goes on to propose a “new” solution to this non-existent problem. They propose an “agility coach”, working across multiple Scrum teams. The authors explain: "The rule-of-thumb ratio is one agility coach to every three to five teams".

So what’s happened here? Existing good practice (Scrum Masters, operating across a few teams) has been re-branded as a “new idea”. It is then given a new name “Agility Coach” to have something that looks new and sellable. Cleverly, the term is similar to, but different from, the widely used “Agile Coach”. This means the article can say: “The role has exploded on LinkedIn and many profiles claim to be agility coaches.”

But as we will see, the role is quite different from most people’s understanding of the “Agile Coach” role.

What is this new role?

It’s interesting to look at what the McKinsey article suggests the key roles would be for an “Agility Coach”. Is this just a new name for Scrum Masters? Three of the skills seem to be exactly the classic skillset for Scrum Masters.

• Self-mastery: Listen, empathise and empower
• Coaching: Support learning, encourage ownership, and promote desired outcomes
• Agile Mastery: Understand the practices and mind-sets underpinning agile ways of working

The fourth, however, seems to fly in a completely different direction.

• Commercial acumen. They drive performance in the context of a clear business need.

So this extends the Scrum Master role from agile expertise to business knowledge (“Understands the industry and relevant trends"). And it also adds in delivery responsibility (“Drive team performance against the defined mission”).

This is a second marketing trick. Having introduced a new name, the role is now being angled away from mainstream agile towards something that a traditional organisation finds more comfortable. Less a Scrum Master and more, well, a Project Manager.

This raises a few questions. Should you both coach and drive delivery performance? What is the Product Owner doing in all this? Don’t they have ownership for business priorities and backlog management? Most critically, shouldn’t it be the team that “drives performance”? Isn’t that what an empowered team does?

You get the feeling that it’s easier to sell an “Agility Coach” (who seems to be an “Agile Project Manager”) than to empower a team and a Product Owner.

Use of an academy

The article goes on to propose that the large number of “Agility Coaches” could be created through an internal training program or “agility coaching academy”.

Of course, setting up a training program is a good approach to develop a large organisation. The article suggests a program of 12-20 weeks to train an Agility Coach.

This seems ambitious. Good Scrum Masters (like all good coaches and leaders, and I include good classical Project Managers) have built their skills over a longer timeframe.

So why is McKinsey suggesting a program of 12-20 weeks to build Scrum Masters (who are also going to be commercial and domain experts)? Because it’s sellable. They can set up this program and see the first set of trainees complete before they move on. Three years might be more realistic, but wouldn’t be a sellable product.

Conclusion

The McKinsey article feels like a case study in how Agile is subtly twisted to make money. There are three steps here:

Take ownership of existing good practice

You re-brand good practice as new ideas. You then invent new language to confuse. “Scrum Masters” may exist, but “Agility Coach” – that’s new.

Distort the message to reduce threat

Agile needs cultural change, so you modify the good practice to push it into a less threatening space that minimises the organisational impact. Scrum Masters support team empowerment, so let’s make them accountable for delivery.

Build a change program

Since incremental, practitioner-driven change doesn’t sell, you define a “big bang” solution which implements this idea. Most importantly, you sell the idea that experts, not practitioners, are what matters.

*Guest blogger Jay Alphey is passionate about unlocking the amazing things that result from bright people working together in teams to deliver business value. He’s been a rebel since discovering that few companies seem able to make that happen.

He has led and coached technology teams across the globe and currently heads agile development at 1Spatial, who help organisations maintain accurate maps of key infrastructure.*