Escalations in Agile Programmes: Deciding Fast Without Blocking Teams

Escalations in agile programmes work when every decision has an owner, a deadline and a fixed level at which it is settled at the latest. Escalation then becomes a normal part of steering and stops blocking teams. The cause usually lies in unclear decision rights: anyone who does not know who may decide waits for the steering committee, and work stands still.

This article describes an escalation model with three levels, shows how to set decision deadlines and offers a checklist for programmes with several teams.

Why do escalations block agile programmes?

Escalations block agile programmes because they halt a team's work until someone outside the team has decided. A team of eight that waits three days for an approval loses 24 person-days, although nobody did anything wrong. With a ten-day sprint, that is almost a third of the sprint's capacity. The delay is rarely visible, because the team works on other tasks in the meantime, and the waiting task only appears in the retrospective as the reason the sprint missed its goal.

Three patterns create this waiting time. The first is the missing decision level: a conflict between two teams goes straight to the steering committee because no intermediate level exists. The second is the unclear owner: several parties feel responsible, and each waits for the other. The third is the missing deadline: the escalation is placed on the agenda of the next meeting, which takes place in two weeks.

How such delays add up along the delivery chain is described in the article on managing dependencies between teams. Escalations are usually the visible end of a dependency that was not clarified in time.

Which levels does an escalation model need?

An escalation model for agile programmes needs three levels: the decision within the team, the decision between teams and the decision in programme steering. Each level has a named decision-maker and a deadline, after which the matter passes automatically to the next level. The model follows the principle of subsidiarity: a decision is taken at the lowest level at which all necessary information is available.

The first level is the decision within the team. It covers everything concerning implementation, sequence and technology inside the team. The 2020 Scrum Guide assigns the ordering of the Product Backlog to the Product Owner and the planning and delivery of work to the Developers, with nobody outside the team intervening. When a team escalates at this level, its roles are usually unclear, and clarifying them settles the matter without a higher authority.

The second level is the decision between teams. It applies when two teams disagree over an interface, a shared component or a sequence. The decision-makers are the Product Owners of the teams involved or a person with programme responsibility, in many organisations a delivery manager. In practice the deadline is one to two working days, because both teams wait in the meantime.

The third level is the decision in programme steering. It covers questions that change the budget, deadline or scope of the programme or affect several parts of the company. The deadline is five working days at most, and steering decides in a fixed time slot without waiting for the next regular meeting.

How do you set deadlines for decisions?

You set deadlines by calculating the cost of waiting and aligning the deadline with that cost. The calculation is simple: number of people waiting times days waited times day rate. Five people waiting two days make ten person-days. At an assumed internal charging rate of 600 euros per person-day, a single delay costs 6,000 euros. The principle comes from prioritisation by cost of delay, which puts the economic damage of a delay at the centre.

The calculation yields a rule for deadlines: the more people a decision blocks, the shorter the deadline. A decision that holds up a single team for half a day can wait. A decision that slows three teams needs an answer on the same or the next day. The deadline is a ceiling, and many decisions take half an hour once the right people are in conversation.

Expiry of a deadline has a clear consequence. Whoever has not decided within the deadline hands the decision to the next level, and that level receives a short summary with options and a recommendation. The waiting time thus reveals itself, and nobody has to name and shame a delay.

Which decision rights must be settled in advance?

The decision rights for sequence, technology, budget, staffing and external communication must be settled in advance, each with a name or a role. Where this clarification is missing, the avoidable escalations arise. A proven aid is Delegation Poker from Management 3.0 by Jurgen Appelo: a group assigns one of seven delegation levels to each type of decision, from “I decide alone” to “the team decides entirely”. The result is a table that records for each type of decision who decides and who is heard.

The effort is small. A ninety-minute session with the Product Owners and the programme lead is enough for the first ten to fifteen decision types. What matters is that the results are published and apply to all teams. A decision table that exists only in minutes has no effect in daily work.

A second layer concerns coordination across several programmes. The Flight Levels model by Klaus Leopold distinguishes three levels at which decisions are made: the operational level of the teams, the coordination between teams and the strategy. The three escalation levels above map directly onto these.

What does a decision log look like?

A decision log records five items per decision: the question, the options, the decision, the decision-maker and the date. For far-reaching decisions it adds a review date. The log serves two purposes. It prevents the same question from reappearing after four weeks because nobody remembers. And it makes patterns visible: if a particular type of decision lands repeatedly at level 3, a lower level lacks the decision right.

The log also shows whether the model works. If many entries land at level 3 that could have been settled at level 1 or 2, decision rights are not clarified, and programme steering becomes a bottleneck. The number of level-3 escalations is therefore a useful indicator that every programme lead should watch monthly. If it falls over several months, decisions are arriving where the information sits.

What should you do when executives or heads of department are in conflict?

When executives or heads of department are in conflict, the programme lead prepares the decision so that the common sponsor can take it in a single meeting. That includes the effect of each option on deadline, cost and benefit in figures, a recommendation with reasons and the date by which a decision is needed. Such a decision paper runs to one page. Anyone who writes ten pages delays the decision.

Another lever is planning. A programme that clarifies its dependencies in one joint event, as described for big room planning, moves many conflicts from ongoing delivery to the planning event. The decision-makers are in the room anyway, and escalation happens in real time.

Managing escalations with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver and works on projects ranging from VC-funded scale-ups to DAX 40 corporations, deployed in over 20 countries on six continents. In the service area of delivery management he takes on roles such as delivery manager, project manager or product owner and designs the organisation around delivery.

The approach follows the Niehues Delivery Model. Two of its review questions are particularly revealing for escalations: who decides, who delivers, who uses? And: which roles, decision paths and interfaces does operations need? Anyone who answers both questions in writing has the basis of an escalation model. Scope and terms of an engagement are discussed in the free initial consultation, which you can arrange via the contact page.