Unfreeze Your Budget

Doing more with less in a world of tariffs, trade wars and economic turbulence 

How would you feel about reducing 75% of your Scrum Masters, up to 94% of your Product Owners, 75% of your Release Train Engineers, and nearly all of your Agile Coaches?

You don’t need an army of coordinators to manage the people delivering real customer value. By simplifying your structure, you can free up significant budget and empower your teams to achieve more with less.

Let us show you how.

Frozen 

Frozen! 2026 budgets at enterprises around the world are locked down. Businesses are struggling to make plans: geopolitical uncertainty, economic uncertainty, trade tariffs, new regulations, and a world where globalization is in reverse, have left executives frozen, unable to make decisions, unsure from one day to the next what this year might bring. We´ve been speaking with middle and senior managers around the world and we hear the same things,  

 
¨2026 budgets are frozen at 2025 levels. Every manager has been told to find cost savings if they want to do anything new this year. ¨ 
¨Every manager in the company has a cost reduction target! ¨ 
¨Senior executives no longer care about agility. In fact, Agile is toxic. Everything is focused on cost savings now. ¨ 

We Hear you!

For a decade already, we have been saying that Agile transformation initiatives are costing you too much. Agile didn’t save you money, it increased costs typically by around 15%. It added a lot of new positions that didn’t exist 25 years ago. Extra people seemed like a good idea at the time – more people, more budget, bigger empire, more power, money was cheap, oversight and governance were poor, accountability was a forgotten art. Now, all of that overhead, that Agile empire, it is a weight around your neck, a burden you can no longer carry. 

AI will save us! 

In response, we hear that a lot of companies are looking to AI as the great hope to save them. Enable the workers to work faster and better, resulting in a dramatic drop in employee costs. However, we are not seeing a lot of positive results reported from these initiatives. In fact, in 2026, the opposite seems to be happening, companies are reporting that AI experiments have failed to show the expected gains. While many companies will continue to try, using AI automation to assist workers, to help them go faster, and do more, we believe that we have an alternative approach that is immediately actionable, extremely pragmatic and will have an impact on your bottom line within 6 months – delivering results now, in 2026. Instead of focusing on the workers and the work, focus your cost cutting attention on the coordination and transaction costs of doing the work. Let us show you how… 

Overheads 

Learn to understand your overheads. How much time, money and attention do you spend coordinating work, setting up to make it happen, handing over, and cleaning up afterwards?  Quantify your waste and non-value-adding activities… 
 
 
A good large scale Kanban / Enterprise Delivery Management implementation should give you a picture like this (above). Coordination costs should be 3-5% of the total. Transaction costs should also not exceed 5% of the total. This leaves around 90% for value adding work with perhaps 1-5% of that accounted for as failure demand such as production defect fixes and other rework. In summary around 85% of your cost is spend generating value-adding work. 

A typical Agile implementation based on Scrum at the team level will give you a picture much more like this (below). 1 scrummaster, and 1 product owner for every 5 or so engineers doing value-adding work. Close to 30% spend on coordination costs. With a further 5% spent on daily scrum meetings. 35% in total spend on coordination. Transaction costs of sprint planning, demo, retrospective, etc using a further 10%. And did you spend any time upstream refining your backlog? Typical Scrum implementations spend around 50% on transaction and coordination costs. We seen reports of 90% failure demand in Agile organizations. In other words, it is not uncommon that only 5% of the budget for a product team is spent on value-adding work. 

Anyone working in a coordination role such as Scrummaster, project manager, or product owner contributes to your coordination costs. Time spent in coordination meetings and time spend organizing and scheduling such meetings is coordination cost. 

Transaction costs at the front end represent set up – planning overheads, budgeting, assembling a team, putting in place all of the right resources to deliver a project. At the back end, the transaction costs, are tear down of environments, breaking up of teams and the organization, hand over and delivery. Transaction and coordination overheads can often be as high as 40-60% of total budget. 

Failure Demand 

The purple area on the picture represents work that your workers are doing because of some earlier failure: fixing production defects, redesign because of poor user experience, failure to correctly understand requirements resulting in delivery of the wrong functionality, any work that is being undertaken because of a failure to get it right the first time around. In some organizations, including some early experience reports from Yahoo!, this has been reported to be as high as 90%. 

If we compound this result with the overheads of transaction and coordination, it is possible that as much as 96% of your budget is spend on non-value-adding activities. If even half of it is avoidable waste then budget savings of 40-50% are possible! 

Flow Efficiency 

Focusing at team-level misdirects attention from delivering business value and customer satisfaction. An Agile coach at a global internet equipment manufacturer told me, ¨Every team in the retrospective reported a good sprint, but I can tell you that customers are waiting 6 to 9 months for delivery of their features.¨ The problem is a failure to track end-to-end flow of the customer-valued feature, work item, or request. Of thos 6 to 9 months, how much of the time was spend doing customer-valued work, versus simply waiting, queuing, delayed for various reasons, blocked, and otherwise stuck? The concept of working time compared to end-to-end lead time, from customer request to delivery, is often referred to as flow efficiency. When we first meet organizations, it is common to find that flow efficiency is 1-2%. In other words, something that takes 100 days to deliver, only required 1 to 2 days of actual work. 

Now imagine that we introduce AI into this scenario and the AI improves the workers effectiveness by 10x. Work that previously took 2 days, now takes 90 minutes. Before AI flow efficiency was 2%. After AI, flow efficiency in 0.2% and the customer is still waiting 98 days for delivery. As a general observation, at this time, large corporations have not been successful at deploying AI to improve coordination within their operations. In fact, their AI experiments haven´t even attempted to make such improvements. 

We have not seen solid case studies and experience reports where AI has dramatically reduced customer lead times or had a significant effect on quality and customer satisfaction – other than those where the impact was negative. 

To improve flow efficiency, the core competency required is coordination. In a typical enterprise, a customer request must pass between different parts of an organization from point of entry until fulfilment. The diagram below illustrates this flow spanning sections of the organizational structure. The delays happen in the gaps between these organizational units. These represent blind spots, often without tracking, instrumentation or reporting – each team sprints locally, the end-to-end flow isn´t tracked or reported, the customer gets frustrated waiting, usually without an satisfactory progress reporting. 

The typical response to this is to appoint a Delivery Manager, someone responsible for taking the customer´s order and ensuring its flow through the organization and eventual delivery. In a high trust organization such as we had at Corbis in Seattle in 2007, an existing manager at the front of the value-chain took on this added responsibility – no additional headcount, no new roles, no new job titles, just an existing manager with additional responsibilities. A workflow kanban board is used to track, report and coordinate the customer requests from end-to-end. Daily kanban meetings with representatives from each organization unit involved in the workflow enable and facilitate the coordination of all work. The kanban board enables cooperation without explicit power or authority given to the delivery manager over the others in the chain. It enables each organizational unit to collaborate in customer workflows and services, effectively operating a shared services model, orchestrated into value chains under the direction of an accountable person, the delivery manager. 

The image below shows the how an end-to-end workflow kanban board moves beyond the team level. Instead of each team having separate boards, managed locally, optimizing efficiency locally, the workflow kanban board gives an end-to-end view of customer-valued work requests. 

The joins between the teams represent unbounded queues that often fall between the cracks in organizations: end-to-end flow isn´t being managed, often there is no instrumentation to report end-to-end lead times of customer-valued work. Consequently, many organizations we encounter report 1-2% flow efficiency. Something that takes 1-2 days of effort takes 100 days to delivery to the customer. So imagine that we´re focused on improving the work using AI. If we make the work 4 times faster, we cut 2 days of effort to half of one day. We reduce 100 days of delivery time to 98.5 days. As a general guide rule, AI will not help you avoid cost of delay. Instead you need to focus on the delays, the periods that are often not being managed in your organization. 

Efficient Scaling 

Facilitating a panel session at a conference Helsinki, Finland, in 2010, a question was asked to the panel from the floor,… 

¨I have been at this conference for a couple of days now, and from all of the presentations about Kanban, I have concluded that with Kanban, you do not need the role of Product Owner as prescribed with Scrum. If the panel agree with this, what would be their recommendation to a company that recently hired 400 product owners?¨ 

Taken a little by surprised, I replied, ¨I need to clarify that I heard your question correctly: I thought I heard you say ´400 product owners´ was that correct?¨ 

¨Yes. That is correct. 400 product owners!¨ 

¨If you have 400 product owners, how many developers do you have?¨ 

¨2400 developers. 1 product owner for every 6 developers. This is what our Agile consultants recommended.¨ 

Did your company receive similar advice? 

The pattern below is one that I first presented to Barry Boehm´s master´s degree students at USC in Los Angeles in 2009. The Scrum pattern at the top shows a set of business owners, perhaps from different business units, feeding a product owner with their requirements. The product owner, ¨the single ringable neck¨, ¨the single throat to choke¨, the accountable person, in turn works with the scrummaster who acts as the point of liaison for the scrum team of developers. 

To make this pattern more efficient, we want the delivery organization dealing directly with the business owners – no middle-men, no intermediaries, instead replace it with better coordination. Elevat the product owner above the value stream, a role that we called service request manager (SRM) and more recently renamed to Demand Manager (a title becoming popular in some parts of Europe). 

If the front end of the delivery organization is represented by a Delivery Manager and behind him or her is a workflow, value stream, of chained teams, then typically we have one delivery manager for 24 to 36 delivery people, and the delivery manager does not represent additional headcount. Additionally, the coordination effort for a single workflow or value stream does not generally represent a full time job, and one Demand Manager can support 4 to 6 delivery workflows. 1 Demand Manager for every 96-144 delivery people. And no coaches. 
 

So, with this reorganization into value streams with end-to-end workflows in kanban boards, use of Delivery Managers and Demand Managers, you have a completely different story for this company from Finland. 

Imagine at the time of asking, they have 400 product owners, 400 scrummasters, and more than likely 50-80 Agile coaches from their advisory consultants. We are going to take that, make it faster, more efficient, almost certainly with higher quality, and to do so, we should need: 

• 24 Demand Manager (compared with 400 product owners, with 400 scrummasters) 
• 100 Delivery Managers (no additional headcount, just team leads with added responsibilities) 
• If we need coaches,… 
• 1 Accredited Kanban Consultant (AKC) overseeing a 2400 person strong transformation 
• 8-16 Kanban Coaching Professional (KCPs) also known as Enterprise Transformation Managers (ETMs) 

Before, organized using Scrum: total headcount 3200 people. 

After, better coordinated using enterprise scale Kanban, 2441 people. 

Headcount reduction: 24% 

Our offer 

We believe that we can significantly impact your headcount and costs. If you´ve been an organization that embraced Agile methods over the past 2 decades and you are carrying that legacy, we believe that we can help you shed up to 25% of your workforce this year without negatively impacting the delivery of customer-valued work. In fact, we genuinely believe that customer satisfaction will increase – delivery times will drop dramatically, quality will improve, and with it customer satisfaction, and all the while at significantly lower costs. 

So much so that we are prepared to put our money where our mouth is. Come talk to us about a training, coaching and mentoring engagement to run from April to October. We will set meaningful headcount reduction targets. We will tie payments and bonuses to achieving those targets.