Agile - What went wrong
Part 3 of 3
Over the past couple of weeks I have been writing about agile and agility and all the wonderful things that it can do for teams and organisations of all sizes and industries. I truly believe that when it is designed and implemented in the right way, it is the best way to run and operate a business. I believe your people will be happier, so will your customers and so will your bottom line.
Sadly, agile is not a word that is totally well received in organisations these days; especially by people who have “suffered” big agile transformations thrown upon them. Some people are sceptical when they hear the word and in general, it has probably been overused and misused a lot in the last 5 to 10 years in the world of business. My first business was called The Agile Eleven and I remember clients used to say to me: we really want to work with you, but can you not call it agile? You know there is a problem when you hear something like that, and you also know it is time to rebrand your business!
So, what went wrong? In my mind three things:
1. Turning agile into a methodology rather than a mindset
I have explained over the last couple of weeks how the essence of agile and agility sits in the mindsets that support it: collaboration, trust, transparency, collaboration, communication, etc…
When the agile manifesto was created, it was not a step-by-step rulebook on “how to do agile”; it was a set of values and principles. The problem is that we “humans” struggle with ambiguity; and we need someone or something to remove that uncertainty and tell us what to do. Therefore, a bunch of methodologies emerged in the market. Scrum was the most famous for teams but there were others; and SAFE (Scaled Agile For Enterprise) was the methodology most widely used for big transformations. What a brilliant marketing name by the way!
In my opinion, that is when things started to go wrong. It was no longer about the outcomes one should achieve by implementing agile or agility, like more speed in execution, better customer outcomes, faster and more desirable products, better people engagement, etc…but instead it becomes about implementing a methodology and to make sure we follow the steps in the rulebook. I think the English saying for this is having the tail wagging the dog. Which leads me to problem number two…
2. Agile becomes an industry
Because suddenly we have all these new methodologies, people need to “learn” how to do them and therefore we need to “certify” them and give them new job titles like “scrum masters” (what a non-agile name by the way! Master?), agile coaches, delivery leads, etc, etc…and a whole industry of learning and certification is born; and with that the essence of agile dies.
I have a confession to make. I have been helping organisations become more “agile” for more than ten years and I don’t have any of the certifications of the agile industry; and I will never will. Because the whole point is that organisations “become” agile; not “do” agile. Sure, some of the methodologies can be useful at times and I have used some parts of it; but with the aim to embed the mindsets and achieve the outcomes of agility; never to implement a methodology.
3. Agile becomes a cost-cutting exercise
Since the Spotify model was first introduced to the world in 2012, a lot of companies have tried to emulate their approach, but for the wrong reasons. For those who don’t know, the Spotify model was an organisational structure model based on cross functional teams (named squads), that were grouped into customer value streams (tribes) and where same functional roles still came together under the name of chapters. That model was designed with the mindsets and outcomes of agile and agility: better collaboration, more speed, more customer value, etc…it was never conceived as a cost saving exercise or a way to reduce headcount.
Sadly, since then, when a big corporate has wanted to “go agile” and usually has been advised by a big consultancy; generally this has meant that they’ve tried to implement some sort of “spotify model” – restructuring the entire organisation in cross functional teams under the promise that it would make them more “agile” – but with the sole purpose of cutting cost and removing headcount for the organisation. Forgetting all about the mindsets, values and principles that are the essence of agile and just thinking about the money and savings.