Ian Spence

Scagilize Network Partner (Trainer & Consultant), Advisor & SAFe Fellow

Ian Spence on:



It's not them, it's you:
Some thoughts on why Agile Transformations fail




Now we all know that change is difficult and that the failure rate for Agile Transformations is quite high.

 

There are many reasons for this – just ask ChatGPT – but if you hang out on LinkedIn, you’ll probably get the impression that they fail because:

 

  1. someone picked the wrong framework.
  2. of interference from those pesky middle managers.
  3. they didn’t reach the Agile Nirvana.
  4. people have too many badges.

 

Rarely do you see anyone admitting that it was their fault or the fault of the Agile Coaches.

Let’s be honest, it’s not the framework.

Now, over the years I’ve been involved in many Agile Transformations with varying degrees of success, and I must admit I’ve never seen an Agile Transformation fail because the wrong framework was selected.

 

All the Agile Frameworks:

  • have more in common than they have differences.
  • go some way to providing a common vocabulary that will help ease the change.
  • make a good starting point for experiments and accelerated adoption.
  • were recommended by Agile Coaches.

If the framework needs improvement, then that’s what good coaches do. If you need to show empathy and change your vocabulary, then that’s what good coaches do. If you need to be pragmatic and sacrifice your favourite agile practice to support the business goals of the organization, then that’s what good coaches do. If you don’t like the selected framework and can’t bring yourself to work within it, then don’t take the job. That’s what good coaches do.

 

Do I see this behaviour consistently from Agile Coaches? No. I can’t count the number of instances where coaches have come in and started a resistance movement to undermine all previous progress towards agility. My favourite instances of this are:


  1. A large program adopted framework A and were trending very successfully on all the measures that matter (throughput, quality, morale, empowerment, time-to-market). They were told, on the recommendation of the Agile Coaches from a major consultancy organization, that they had to stop what they were doing as ‘it wasn’t Agile” and that they needed to start again using the Spotify Model.
  2. A Product Owner working at a major bank who was told by a member of the Lean and Agile Center for Excellence that they couldn’t be Agile as they were using Use Cases instead of User Stories and that they had to stop, throw them away and start again, even though the whole team was happy using use cases and was outperforming the other ‘agile’ teams on all the measures that matter.


So, let’s stop starting unnecessary and antagonistic Framework Wars in the organizations that we support and focus on practical steps to increase their agility and improve their performance.

Let’s be honest, it’s not the Middle Managers.

I must admit I used to subscribe to the theory that all the problems were with the middle management permafrost, but over the years I’ve learned to embrace and work with them to accelerate and sustain the Agile Transformation.

 

The trick is to have empathy for them, their knowledge, and their experience. Treat them as the knowledge workers they are and empower them alongside the teams that they manage and support. Help them to become the ‘good managers’ that the organization needs to thrive and become more successful.

 

It was great to see Chris James of SAI acknowledging the importance of middle managers in his keynote at the recent SAFeÒ Summit in Berlin by quoting the following:

This is backed up by many studies and experiments at places such as Google, where after several attempts to remove their managers, they discovered that good managers are worth their weight in gold (and exhibit what we’d all recognize as agile characteristics) whilst bad managers are toxic, damaging both their teams and the organization.

 

So rather than creating out-groups and alienating the middle managers, embrace them, show empathy, and help them to become better managers.

Let’s be honest, Agility is a vanity measure.

Too many Agile Coaches are focused on achieving some kind of Agile perfection rather than achieving measurable business outcomes.

 

Because of this, they 1) set levels of expectations that can’t be met and 2) judge the success or failure of other Agile Transformations against their own inflated sense of what true agility is.

 

Let’s get back to basics: look at the real return on investment and stop this fundamentalist judgement of other’s achievements.

Let’s be honest, learning and training are good things.

I’ve never really understood why so many people are against agile training and certifications. Everyone knows that training is no substitute for experience, but personally I’d rather work with people who’ve taken the time to learn Agile practices than those that haven’t.

 

There is though a problem inherent in much of the training delivery.

 

The problem is the closed mind-set and dogmatic attitude of many of the trainers. Believe me, it is possible to train people in one Agile Framework without denigrating the others. As someone who has taught both Scrum@Scale with Dr Jeff Sutherland and SAFe with Dean Leffingwell I know that this can be done and that broadening the base of my own learning has been invaluable. Teach people what they have come to learn, and resist the impulse to slander and denigrate the competition. Feel free to explain the strengths and weaknesses of different agile approaches (they all have them) but build on their shared heritage and commonalities rather than proclaiming them the work of the devil.

It's not them, it’s you.

I could go on – for example, is it possible to have too much leadership support? Does everyone else really need to change everything else before you can improve? – but I think my thesis is clear by now.

 

Please stop blaming others when Agile Transformations fail, and start to accept responsibility for the results (or lack of them) that you generate.

 

Please stop judging others against some kind of mythical definition of your own personal Agile Nirvana. If a company moves from one agile framework to another, does this mean the first one failed, or does it just mean that it successfully created a platform for further improvements? If a company lays off all its Scrum Masters or Agile Coaches, does this mean that their Agile Transformation has failed, or does it mean that it’s been so successful that they no longer need to make a big thing about it or have resources dedicated to becoming Agile?


As Dean Leffingwell said to me many years ago – “The biggest threat to the success of SAFe is bad SPCs[1]”. A statement I would extend to the broader community of Agile Coaches.

 

  • The biggest single cause of failure of Agile Transformations today is Agile Coaches.
  • The biggest threat to the continued success of Agile and its sustainability as the foundation for modern ways-of-working is Agile Coaches.

 

So, please, remember it’s not them, it’s you!

 

PS: I say all this as a proud Agile Coach who has no desire to rebrand themselves as something else.

[1] SPC - SAFe Program (now Practice) Consultant - those responsible for promoting, training, and coaching in SAFe.