Agile Has Been Costing You Too Much! 

It is Time to Adopt the Alternative Path to Enterprise Agility.

[The original version of this article was published on January 4th, 2016, titled ¨Is Agile Costing You Too Much?¨ and revised again in May 2020, with the same title] 

Agile is in crisis. Since January 2023 when CapitalOne, a bank in the United States, cut 1,100 people with Agile job titles, companies worldwide have been reviewing their Agile transition initiatives and finding them to be little of value. Every week a new round of layoffs is reported, and many Agile coaches are now looking for new opportunities. 

While Agile appears to have failed, large enterprises need business agility now more than ever. The ability to pivot, adapt, and reinvent how you do things has become the core survival capability for modern business. The need for agility hasn´t gone away, rather it is even more important than ever before.

So if Agile has failed, what do you do instead? 

The Kanban Method

The Kanban Method has offered an alternative path to agility since 2005. Evidence suggests that it produces productivity improvements 4 to 8 times better than Agile methods and in some reports as much as 16 to 20 times greater, while the cost of implementation can be less than 1% of the cost of Agile transition initiatives at enterprise scale. Kanban is the secret the Agile market has been hiding from you for years. Now is the time to show resilience, embrace an evolutionary approach to improvement, and recognize that Agile costs you too much. Agile came at a price you can no longer afford.  

Enterprise Scale Kanban guidance together with the Kanban Maturity Model, and its leadership development guidance, offer you an affordable, incremental roadmap to deliver significant economic improvements. They lead you to satisfied customers, and true enterprise agility without the impact of a horde of Agile coaches and other additional Agile roles that increase your fixed costs. 

Failing at Scaling  

While writing my first book, Agile Management for Software Engineering, in 2002, I came to believe in the need for an alternative path to agility. Too many people were resisting the adoption of Agile methods. The book introduced the concept of the flow of work into the technology development space and argued that enterprise agility was achieved by focusing on changing managers´ behavior and improving their decision-making. It argued for improved agility without additional overhead. You just need the existing workers and their managers to do their jobs more effectively through better decision-making. 

Agile Management foreshadowed the emergence of the Kanban Method by suggesting that we could go beyond Agile methods that, through deferred commitment, could gracefully accept late-breaking changes to requirements before project completion or product delivery. A truly agile organization was one capable of evolving its processes and adapting its business models for a rapidly changing external environment. The Kanban Method´s focus on the evolutionary adaptation of service delivery workflows made it a second generational agile method. It was beyond Agile.  

In the early 2000s, I observed lackluster adoption of Agile methods when attempting to scale to the size of a business unit of approximately 300-450 people. This happened at both Sprint (a telco in the United States) and Motorola´s mobile phone division. A single team was easy. A single department only needed a strong manager to lead it, but scaling to a whole business unit met with human resistance. By 2002, I already knew from the experience of two lackluster implementations that scaling existing Agile methods to the enterprise was doomed to failure. 22 years later, it is abundantly clear that this was and is true. 

Writing that first book inspired me to seek a better approach to the adoption of new ways of working and managing – ways that would lead to large-scale enterprise agility. I set off in pursuit of that alternative, incremental evolutionary approach. Today we call it the Kanban Method. Kanban was for people and organizations who found Agile wasn’t a good fit for them or that it wasn’t suited to their culture or the nature of their business. It was for those who needed to scale because at scale Agile methods were always going to meet with resistance. 

While the Agile community tried to hit the rock head-on by introducing coaches to remove resistance, the Kanban Method took the approach of going around the rock. Rather than invoking resistance, it was better to meet people where they are now and help them evolve their ways of working and improve their organization’s performance. 

In 2016 my article, ¨Is Agile Costing You Too Much?¨, I predicted the Agile crisis that we see globally today. It seems it took another 7-8 years before companies started to question the results Agile was giving them versus the costs they were incurring. It started a year ago when CapitalOne bank in the United States cut 1,100 Agile positions, and the trend has now spread throughout most of the world. Recently, in Spain, a major bank cut all of its Agile coaches and, in the same week, an oil company cut about half of them by cutting those working at the team level. Only those working at a service delivery workflow (value stream) or portfolio level have survived for now.

The truth is simple – Agile has been costing too much, and now it is time to do something about it! 

The following anecdotes from 2016 are even more relevant today, as the world struggles to adapt and show resilience during these economically difficult times of inflation, war, and geopolitical uncertainty. If you want to learn how to improve your enterprise agility, at a fraction of the cost of your failed, stalled, or struggling Agile transition initiative, then read on… 

Evidence That Agile Inflates Your Fixed Costs  

In 2011, my firm collaborated on a conference in Finland called LESS. During a panel session that I facilitated, a question asked from the floor was

“It seems to me, listening to the sessions at this conference that Kanban obviates the need for the Product Owner role in Scrum. I would like to ask the panel, what would you do if you had recently hired 400 product owners?” 

Me: “I’m sorry, can I clarify that I heard you correctly, I thought I heard you say ‘400 product owners?’”

“Yes, that is correct!” 

Me:“How many developers do you have?”

“2,400. Our Agile consultants told us we needed one product owner for every six developers. So what should we do with these 400 new people we have hired?” 

How much additional cost was the company suffering to go Agile? A conservative estimate might be 48,000,000€ per year, just in added fixed costs for product owners. 

In December 2015, my colleague and co-author, Alexei Zheglov, was speaking with an Agile coach whose contract hadn’t been renewed. It is never nice to be laid off at Christmas. What had happened? This coach responsible for coaching just six developers was not renewed because there were insufficient tangible benefits to justify the overhead. His contract was costing $150,000 every six months. CAD 300,000 per year to help just 6 people overcome their resistance to Agile ways of working.  

On December 24th, 2015, I met the CTO of a bank in China. This fairly mature IT organization was running a side-by-side comparison of Kanban versus Scrum. The consultants and trainers for both methods were being supplied by the same firm in Shenzhen under a single purchase order and master services agreement. The Scrum coaching required one full-time Scrum coach for every twelve employees. In other words, enabling Scrum had added at least 8% to their fixed costs. In comparison, Kanban cost around 200 days of billable time for training and coaching and had institutionalized at a scale of 2,000+ people, eventually reaching 3,500 people with no additional overhead.  

Late in 2014, I did some consulting for a large telecommunications equipment manufacturer in the USA. Specifically, I was advising a business unit based in suburban Boston. The general manager had brought me in because in his words, “We have been doing Scrum for 6 years but we have not seen any improvements for at least the last 2 of those years.” The business unit of 600 people in total had a ScrumMaster for every 6 developers. I attended several retrospectives, usually facilitated by one ScrumMaster and then each of the others, in turn, had an opportunity to speak up and report the sprint for their teams. Later in the engagement, I discussed the need for someone to take responsibility for flow. Someone to take responsibility for receiving the business owner´s requests and accountability for ensuring their delivery. In Kanban, we call this the role of Flow Manager or Service Delivery Manager. It is usually a role taken on by an existing staff member. Usually someone with a managerial or supervisory position in the organization. The GM asked me who should play that role. He suggested no one in his business unit had the skillset. So, I innocently asked, “What do your ScrumMasters do?” He replied that “they enforce the rules of Scrum.” They were his Scrum conformance police. Since then I’ve come across many companies who describe their ScrumMasters as Agile coaches and the ratio of coach to value-adding workers is in the range of 1:6 to 1:12. Or put another way, Agile is inflating fixed costs by at least 8-16%. If product owners, release train engineers, and perhaps yet more junior ScrumMasters in addition to the coaches are all new positions, then Agile might have increased costs by up to 25%.  

Product Owners: Unnecessary Intermediaries in Agile—Adding to Costs!

The role of the Product Owner became interestingly ambiguous in its definition over 20 years. In some organizations, product owners are business analysts who write requirements. In others, product owners have a role that is very specific to prioritization and they are the decision-makers for the sequencing of the work. Ken Schwaber, a founder of Scrum, described the Product Owner role in the early years as “the single throat to choke” or ¨the single wringable neck”. He clearly had decision-making, responsibility, and accountability in mind when he used those terms. For many the Product Owner is an interface between multiple competing business stakeholders and the delivery organization (or Agile team) – in other words, the Product Owner is an additional intermediary or broker. 

The Product Owner as a concept is a curious addition to Agile. At the founding of the movement, Agile was partly about removing intermediaries, eliminating signal attenuation, and having direct contact with customers. This means having conversations rather than documentation. It is strange, therefore, that to facilitate such a process we need a new form of intermediary, the Product Owner, to prioritize the order of the conversations. It was already a strange development in 2002, and that it persisted more likely reflects that the buyer did not know better and there was money to be made providing product owners from consulting companies and recruitment agencies. 

Regardless, of exactly what the product owner does in your organization, it does seem that often these product owners are new hires to the organization, and again, the ratio of 1:6 seems to be common. One of our clients based in Barcelona decided in 2015 to hire about 20 such product owners. While it goes against standard Kanban coaching guidance, the client had their reasons and justification for the decision. The new product owners represented about 3% of the headcount or a ratio of about 1:30 technology delivery people. 

There is a question of whether the Product Owner is a value-adding role or not. In many organizations, it appears that it is not. The product owner is an intermediary with authority over prioritization. While sequencing and scheduling when done well will generate value, the act of sequencing one item over another does not add value to the items themselves. It’s a non-value-adding role. It is even more curious then that Agile requires you to create and add wasteful, non-value-adding positions. 

So, in many cases, Agile methods implemented at the enterprise scale appear to have added two new people in non-value-adding positions for every six in value-adding positions. Put another way, after the Agile transition, 25% of the workforce is additional “Agile” overhead for operating the Agile method. While this is at the higher end of the range, I believe that it is typical for operating expense budgets for IT/product delivery teams to be increased by around 14% on average and up to 25% to cover the overhead of non-value-adding Agile facilitation positions. 

The Cost of Agile Training and Coaching  

What about Agile training? There are many 2-day, and in the case of scaled Agile solutions, 3 and 4-day training classes available. Many of these come with short examinations at the end and certifications for passing. However, what appears to be the case is that these training classes do not prepare the workers to behave in an Agile fashion or to deliver the promised benefits of Agile methods. The classes often contain abstract or metaphorical content and are filled with games that while fun to play, do not teach specific actionable behavioral change in the workplace. 

Together with my colleague Carlos Calleja, I was visiting the campus of one of Spain´s leading global banks in Madrid. As we walked from the parking through the beautiful parkland of their campus to our destination building, we saw a group of 20 people standing in a wide circle throwing bean bags at each other. Carlos exclaimed, ¨My God, what are these people doing?¨ I blankly replied ¨Scrum training!¨ ¨OMG, are you serious?¨ 

All of this is okay because the Agile transition purchase order includes coaching as well as training and the coaching is essential because the training did not contain anything actionable. The workforce, however, is now “certified”. Strangely this certification does not mean they know how to behave differently or how to produce better outcomes. It appears to mean that they are now certified to receive coaching. 

How much do you have to boost your topline business performance to justify a 15-25% increase in fixed costs? Agile has been struggling to show a return on investment for 20 years already. 

Scaled Agile Inflates the Costs Even More 

The creators of the Scaled Agile Framework have claimed that if properly implemented, typically expected improvements might include a 50% increase in delivery rate (of request work such as features in a software product). As I discovered after writing Agile Management, increasing the delivery rate is not a particularly interesting metric for business people. They are interested in faster time to market, reduced lead time, avoidance of cost of delay, and increased market opportunity from earlier delivery. Speed isn´t about the rate of delivery, it is about the delay from request to delivery. Early delivery only creates the possibility and opportunity to make more money sooner. The Scaled Agile Framework has struggled to show value and a true return on investment for firms adopting it. Meanwhile, it appears to cost a great deal of money to implement. 

One company I know of in Central Europe transports up to 500 people by plane, train, or private cars to a location near Frankfurt every quarter to conduct the scaled Agile release train planning. What is this costing? If we conservatively budget 800 Euros per person for transport, lodging, and catering, and assuming the company has a meeting facility large enough and isn’t renting a banquet hall from a nearby hotel, then we might have a budget of 320,000 – 400,000 euros per quarter. Since writing this anecdote in 2016, we´ve learned of several more examples, including a large German automotive company that rents an indoor sports arena every 3 months to put almost 2,000 people in a single room together for most of a week. It is conceivable that the annual cost of this amounts to between 5-10% of the payroll for those people. Adding this cost to the perhaps 25% overhead for all Agile roles, we might approach a 35% increase in fixed costs. 

Meanwhile, releases are only coming every quarter. How often were releases happening before the adoption of Scaled Agile? And how much functionality was getting released? Is there any tangible evidence that Agile is delivering the additional value it claims? Is it shortening the time to market? Enabling deferred commitment? Helping to manage risk better? Providing the agility to pivot and reinvent at short notice? 

I hear other claims that Scaled Agile is leading to inefficiencies synchronizing teams with some teams having to take downtime while others catch up. So, the efficiency of Scaled Agile is being called into question by some of its practitioners. Admittedly, I haven’t seen this problem explicitly with any of our clients. 

Agile Has Been Failing to Show Return on Investment for Two Decades  

Almost 20 years ago, I worked with a group of Agile coaches from Sabre Holdings, a travel industry firm that included properties such as Travelocity and Last Minute. They were under pressure to show an ROI for the Agile coaching team. The Agile coaching department was costing around $2,000,000 per year at the time and the senior leadership wanted, quite reasonably, to know what they were getting for that money. After some time, the group was unable to show real tangible ROI and it was closed down. Some of those coaches found employment with other Agile firms such as Rally. After some time, Sabre was once again dabbling with Agile and the costs for consultants and staff augmentation were mounting. A decision was made to create a new in-house team. This time the justification was merely deferred costs against consultants and temporary staffing. It was no longer necessary to show an ROI on value created, just enough to show that the internal cost was less than using outside help. Rational decision-making had been replaced with irrational decision-making. The travel industry is fast moving, highly competitive and margins are tight. Fear of not moving fast enough was enough to drive the desire to be Agile. Rational decision-making had been discarded as a consequence of that fear. 

Conclusion: The Agile Crisis

So there have been almost 25 years of Agile, and yet, we still don’t have very many case studies showing tangible business benefits and real ROI. Waking up to this, we see the kneejerk reaction to cut all the Agile roles entirely. The Agile crisis is upon us. Agile consulting firms thrived on supplying the large numbers of coaches required to “go Agile.” The bottom has fallen out of this market. Perhaps now, it is time to ask, “Is there an alternative approach to agility that costs a lot less?” 

Enterprise Scale Kanban

This is article one of the Enterprise Agility Without the Overhead series by David Anderson. Stay tuned for our next article!

Ready to scale agile and manage dependencies in a more cost-effective manner? Check out our Enterprise Scale Kanban course and find the solutions you’ve been looking for.