Is Agile Costing you too much?
An alternative path to business agility can save you a fortune.
[The original version of this article was first published on 4th January 2016]
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, while the cost of implementation can be as little as 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, to embrace an evolutionary approach to improvement, and to recognize that Agile has been costing you too much – a price you can no longer afford. The Kanban Maturity Model now offers you an affordable, incremental roadmap to significant economic improvements, satisfied customers, and true business agility, without the impact of a horde of Agile coaches increasing your fixed costs.
Failing at Scaling
At the time of writing my first book, Agile Management for Software Engineering in 2002, I came to believe that an alternative path to agility was required because too many people were resisting adoption of Agile methods. I knew that I was writing the wrong book, solving the wrong problem – making the economic argument for Agile methods, when in fact, it was irrelevant, implementing Agile at scale met with resistance, instead an alternative, incremental, evolutionary approach was needed. At the time, I had seen lackluster adoption of Agile methods at a business unit scale of approximately 300-450 people at both Sprint and Motorola. While a single team was easy, a single department only needed a strong manager, leading the effort, scaling to a whole business unit met with human resistance. By 2002, I already knew from experience that scaling Agile methods to the enterprise was doomed to failure. 18 years later, it is abundantly clear that this is true.
After the book was published in 2003, 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, wasn’t suited to their culture or the nature of their business.
What follows is text originally published in January 2016 after I visited several large clients in China. The anecdotes are even more relevant today, as the world struggles to adapt and show resilience during the pandemic. If you want to learn how to improve your organizational 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 which 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’d like to ask the panel, what would you do if you’d 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!”
“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 in order to go Agile?
Last month (December 2015), my colleague, 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? Well, this coach responsible for coaching just six developers wasn’t renewed because there weren’t sufficient tangible benefits to justify the overhead. His contract was costing $150,000 every six months.
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 against Scrum. The consultants and trainers for both methods were being supplied by the same firm in Shenzhen under a single purchase order. The Scrum coaching was requiring one fulltime Scrum coach for every twelve employees. In other words, enabling Scrum had added at least 8% to their fixed costs.
Late in 2014, I did some consulting for a large telecommunications equipment manufacturer here in the US. Specifically, I was advising a business unit based in sub-urban Boston. The general manager had brought me in because in his own words, “We’ve been doing Scrum for 6 years but we haven’t 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 was discussing the need for someone to play the role of Flow Manager / Service Delivery Manager for a kanban implementation. 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 coach the practices of Scrum.” 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 8-16%.
Product Owners, unnecessary, Agile intermediaries – yet more cost!
The role of the Product Owner is interestingly ambiguous in its definition. In some organizations, product owners are basically business analysts who write requirements. While in others, product owners have a role that is very specific to prioritization and they are the decision-makers with respect to the sequencing of the work. Ken Schwaber described the Product Owner role as “the single throat to choke” or ¨the single ringable neck¨, and 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.)
The Product Owner as a concept is a curious addition for Agile. At the founding of the movement, Agile was in part about removing intermediaries, eliminating signal attenuation and having direct contact with customers – 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.
Regardless, of exactly what the product owner actually 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 own clients based in Barcelona, in 2015 made a decision to hire about 20 such product owners. While it goes against standard Kanban coaching guidance, the client had their own reasons and justification for the decision.
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. 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 organizational scale, appear to have added 2 new people in non-value-adding positions for every 6 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% 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 which while fun to play do not teach specific actionable behavioural change in the workplace. 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, are 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.
Let’s imagine for a moment that Agile was producing twice as much value than whatever processes preceded it. If this were true would you spend 14% more on operating expense in order to generate that additional value? Rationally, you would say yes. It is an obvious and simple executive decision. The ROI is clear. Assuming that 2x more revenue were possible (and we have never seen an Agile case study report that made such a claim) and that the additional revenue came with a gross margin of greater than 14% then it is a rational executive decision to proceed.
And therein lies the rub with Agile. How many supposedly Agile organizations can show such benefits? The best and most popular Scaled Agile Framework appears to scale by offering quarterly release planning and using 3-month time boxes. The so called “release train planning” involves getting everyone in a room together in order to resolve dependencies between work and to devise a suitable schedule of six incremental 2-week sprints. This doesn´t offer a lot of ¨agility!¨
Scaled Agile inflates the costs even more
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 in order 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 heard of several more, including a large German automotive company that rents an indoor sports arena every 3 months, in order to put almost 2000 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.
Meanwhile, releases are only coming every quarter. How often were releases happening prior to 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?
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. I haven’t seen this explicitly with any of our own clients, so it is hearsay until I have some solid evidence.
Agile has been failing to show any return on investment for two decades
Almost 15 years ago I worked with a group of Agile coaches from Sabre Holdings, a 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 and the senior leadership wanted, quite reasonably, to know what they were getting for that money. After some period of 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 a period of time, Sabre was once again dabbling with Agile and the costs for consultants and staff augmentation were mounting up. A decision was made to create a new in-house team. This time the justification was merely deferred cost 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.
So there have been almost 20 years of Agile and yet we still don’t have very many case studies showing tangible business benefits and real ROI. Meanwhile, Agile consulting firms thrive on supplying the large numbers of coaches required to “go Agile.” Perhaps, it is time to ask, “Is there an alternative approach to agility that costs a lot less?”
Kanban costs a fraction compared to Agile methods
Back to the CTO of the Chinese bank that I met on 24th December 2015. He told me that in 5 months, he’d managed to scale Kanban to 2000 people across 5 locations in China. That the adoption had institutionalized and he’d been able to make a tour of the various locations and inspect many of the Kanban implementations for himself. He told me that Kanban was producing greater productivity and efficiency than Scrum. He, however, didn’t elaborate much, and wasn’t ready to share his data. He wanted more evidence before going public. What he was willing to share is that the Kanban implementation had been achieved with a total of 200 days of training and consulting, and no coaches, just his own people taking responsibility and showing accountability. This is a ratio of 1 day for every 10 employees. Meanwhile, Scrum coaching is costing 180 days for every 12 employees, in the same half-year time period. He also confirmed that Scrum was failing to institutionalize and required constant coaching. We hear this again and again from clients, year after year.
To put this in perspective, in terms of per employee adoption cost, Kanban was costing this bank 1/150th of the cost of Scrum, and producing better results. How might this huge cost saving be possible? Well, for starters Kanban doesn’t require you to add people to your organization as coaches or product owners, instead it provides existing workers with a means to frame and make better quality decisions. Kanban is empowering and enabling. Workers become more effective at doing their existing jobs in the existing process and workflow – no need for coaching in a new role as part of a new process. It’s simply more effective to stick with what you do now and get better at it than it is to make grand changes.
Only this week (July 2020), I spoke with an Agile coach from New Zealand, she told me that she applies for Scrummaster positions and then when she gets on the ground, she offers the organization some options, ¨alternative paths to agility¨ if you like. She says that organizations that run side-by-side experiments, end up selecting Kanban, while some opt to start with it, after being informed of the options. Further, she reports that Kanban institutionalizes while she has seen numerous occasions where Scrum coaches are removed to save money, or because the Agile transition is ¨complete¨ only for it to fall apart again as soon as the coach is removed. Kanban is working much better for her, but customers don´t yet buy it openly, their opinion needs to be switched.
Scrum is a Procrustean Bed
Back to December 2015 and prior to China, I was in India where I saw a case study presented by a young consultant who was acting for a large Agile consulting firm, advising a large Indian outsource firm, to a large financial institution based in New York – the credit card company that used to ask ¨Do you know me?.¨ Because of the nature of the contracts between these firms, the actual details are covered by a non-disclosure agreement, so we can’t name names, or any specifics. The client had adopted Scrum largely enterprise-wide and had adjusted all their processes to facilitate a 2-week Sprint cadence. We are talking about disrupting almost 100,000 employees in order to have them ¨do Scrum.¨ If ever there was evidence that Scrum is a Procrustean Bed that forces you to change to it, rather than helping you change and improve then this firm is a strong candidate as the prima facia evidence.
Despite the painful disruption, they had by all accounts, managed this transition. It sounds like a highly arrangement, but actual customer lead times for changes to credit card processing systems were taking 130 days on average, not a couple of weeks as might be expected from an Agile organization. With some courage, the consultant took it open herself to push through a single kanban system implementation. With no other changes, within 6 weeks, lead times had shrunk to just 12.5 days and the client was so happy they pushed the consulting firm to implement more Kanban. That particular consulting firm was well known to be anti-Kanban and their salespeople around the world actively dissuade clients from experimenting with it. So, it took a courageous act from a single professional keeping the client’s best interests at heart to create a huge improvement in value delivery.
Kanban has consistently shown tangible economic benefits
That same week in India I saw another presentation, from Amit Kaulagekar of Sungard, where the kanban system had produced a 30% increase in revenue by enabling the firm to process more service requests faster. This is real ROI. Now would you spend 14% on OpEx to get 30% more revenue? Probably not! Revenue isn’t margin or profit. If you only got 30% more revenue but Agile was costing you 14% more OpEx you’d be losing money. The thing is, how many Agile implementations could claim 30% more revenue? Meanwhile, this Kanban implementation cost a handful of coaching days over 6 months. At the cost of Kanban, these benefits make real sense – they make a difference. Meanwhile, at the cost of Agile, the unlikely outcome that you might produce such benefits, simply isn´t worth the risk. It is irrational to spend money on Agile transition initiatives.
Amit´s story provided a déjà vu moment, as I recollected another case study presented at Lean Kanban Benelux by Tina Dudenhoeffer, a consultant, and Marianne Lanting of Winkle. Again, they had increased revenue by 30% in only 5 months by servicing requests for market research surveys faster and more predictably using Kanban. The cost of this implementation was less than 20 consulting days from Tina plus training from Maarten Hoppen of our partner VX Company. Marianne is a manager at Winkle and there was no additional cost for her. And again, at the cost of Kanban, the benefits had made a real impact for Winkle. Marianne described it to me as ¨saving the company from bankruptcy.
In general, these results while extreme sounding to many readers, aren’t surprising. We already know from surveys and reports post Kanban training that our training is more effective than typical Agile training. Kanban training is specifically experiential and uses games, simulations and exercises that simulate or model the actual working environment. Students leave our classes with specifically actionable ideas and designs for changes many of which can be implemented immediately at no or very low cost. They don’t need any or much coaching. They come out of the class understanding what to do and why they want to do it.
A Kanban coaching engagements, from a firm with Accredited Kanban Consultants (AKCs) or Kanban Coaching Professionals (KCPs) will typically look like 2-4 days per month for organizations up to a product unit (or 150 people) in size. Kanban coaching is typically centered around coaching managers on metrics, reporting, and holding the various Kanban Cadences meetings such as Service Delivery Review, Risk Review or Operations Review. Kanban focuses on catalyzing leadership through accountability.
Why all of this seems like such a well-kept secret!
In the days when my own firm did consulting work, we have often found ourselves bidding against Agile consulting firms recommending coaches are on-site for 4 or 5 days per week and often at the ratios we’ve discussed here 1:6 -> 1:12 people. Bizarrely clients have often opted for the latter, usually for 2 reasons:
We don’t quote hourly rates for our consultants, only daily rates, and if you do try to calculate an hourly rate, it will be higher than that for a typical Agile coach. We aren’t ashamed of this. We believe our coaching is far more effective because it focuses on high leverage activities that deliver more value, rather than on Agile practice adoption and behavior.
The quantity of consulting days and the number of consultants is dramatically less. Often clients are skeptical of this. Everyone else is advising them they need a lot of Agile coaches and a lot of coaching. They believe it is too risky to go with our model when we appear to be bucking the trend. It seems easier to follow the herd.
It was common for us to be quoting less than 1/10th the cost of rival Agile consulting firms, typically, $30,000 – $50,000 against $300,000 – $500,000 and then to be told we didn’t win the business because, and to quote a VP from a travel technology firm, “You are too expensive!” This analysis was based on an hourly rate and not on a total contract cost. Sigh! The dysfunction was rooted in her use of her discretionary budget for staff augmentation (contractors) in order to fund what should have been a strategic initiative approved as a project at the portfolio level during the annual budget review. In other words, it was ¨Agile by stealth¨ and being funded by effectively increasing fixed costs in IT by 14% – a total waste of shareholders funds, and an indication that the organization had very low maturity corporate governance.
Carpe Diem! Time to put Agile in the bin and move on
2020 is an unusual year: for many of us, it will be the defining year of our lives and our professional careers. Now is the time to show resilience, and to take the opportunity of the punctuation point of the Coronavirus pandemic to do things different, to put the old ways, that haven´t been working and have been costing you too much, into the bin. 2020 is the year to throw Agile in the bin and move on! There is a proven and effective alternative path to agility, the Kanban Method, and the Kanban Maturity Model. Perhaps now is the time for you to start on your Kanban journey to true organizational agility?
