I am all for agility and flexibility – we need more of that in large companies.
But I have long been a sceptic of “agile at scale”.
I wrote a blog post about it 2018.
A recent article confirms many of the concerns that I described then.
The article was published in the California Management Review (It is written by Maria Annosi, Nicolai Foss, and Antonella Martini.)
It is based on a detailed 5-year case study of a large telecom company (called “Company E” in the article) that implemented agile methods.
The authors interviewed more than 100 people at the team level, middle management, and top management levels, and also analyzed internal document and archival records.
Here are some noteworthy quotes from the article:
Middle management played a key role in facilitating agile implementation, but they often struggled to make sense of the changes themselves. Charged with implementing such changes, they experienced intense confusion (…)
(…) management of Company E increasingly had to realize that its adoption had massive, unanticipated, and far from beneficial consequences
(…) the data revealed high coordination costs due to relevant information being increasingly dispersed across different teams
(…) the application of Agile reduced individual employees’ motivation to learn
Our findings suggest that the innovation goals were not achieved.
Getting what you ask for
The authors write that the effects were unanticipated, but are they that surprising?
If we look at the effects that they describe, arent’ they precisely what you would expect based on the agile philosophy?
According to the agile approach, you should work in “sprints” and shorten the delivery cycles. Well, isn’t it natural, then, to expect that the consequence will be more short term focus, more stress, and lower quality (with less time for testing)?
According to the agile approach, you should minimize written documentation. Isn’t it natural to expect that there would be less knowledge transfer and more difficulty in accumulating shared knowledge about products and processes as a result?
According to the agile approach, you should decentralize decisions to autonomous teams. Without a simultaneous focus on integration across units, isn’t it natural to expect that people will focus more on internal team matters, and spend less time on coordinating with other teams?
All of these problems were observed in the “Company E”.
Paradoxically, an approach that was intended to lead to more innovation actually led to less innovation for this company, as measured in the number of patents or new products.
How did we get here?
I have wondered why agile methods have become so popular.
(It has even invaded my home…one day, late at night, my wife (who works in a government agency) was busy going through a big binder. I asked her what she did. She told me that she was preparing for a test to become a certified scrum master…)
There are probably multiple reasons. One is that most of the consulting firms have marketed the approach heavily. And it is becoming institutionalized with standardization and certification.
Another may be the influence of Spotify. They created a video about the implementation of agile in their organization. It seems like it has inspired people in many other organizations.
The video itself is rather good. But some key factors about the company are left out, and it is hard to say what you can generalize from it.
For example (and now I am guessing), Spotify may have a very good and well structured product architecture (or rather, software architecture).
This may make it relatively simple for them to set up the right teams and allocate tasks. However, firms that don’t have a good understanding of their products and processes may struggle with this.
And as we know all too well, “one size does not fit all”. As I have written about many times on this blog, we need to understand the local context, analyze and diagnose our organization, and tailor the solution to our goals and challenges.
Only then can we have a hope of succeeding.
Keyword from that Spotify video is “Engineering” culture.
Decentralised decisions can be made because “endpoints” (team boundaries) are negotiated with pinpoint precision in standups and architecture meetings. All this happens before anyone pumps out a single line of code.
The communication is highly coordinated with “APIs” or “Service Mesh”. Unfortunately, these artifacts don’t exist in non-engineering cultures.
If there are analogues to these, they are not as sophisticated.
Interesting article. Having spent time in delivery I have come to the conclusion that bimodal delivery is the way to go. Use agile for small teams and low risk projects with waterfall for the opposite end and a blend in the middle. Something I am looking at in my doctoral research