# Restarting an Agile Transformation: A Decision Guide After the First Attempt

Author: Marin Niehues, Niehues Consulting · Published: 2024-02-19 · Transformation & Change
Source: https://www.niehuesconsulting.de/en/blog/agile-transformation-restart/

You restart an agile transformation when the first attempt failed in its implementation, for example through missing sponsorship from senior management or teams without decision rights. If it failed on its objective, a correction is enough. Before you begin again, establish the cause and the business result you want as well as the decision rights, because a second attempt under the same conditions ends where the first one did.

Many companies reach this point after one or two years. The roles are filled and the ceremonies run, yet delivery has not become faster. This article offers a decision guide that lets executive teams and divisional heads analyse the cause, choose between restart, correction and stopping, and set up the second attempt so that it has a measurable result.

**The cause of the first attempt decides whether a restart makes sense. Replacing the method while leaving sponsorship, decision rights and target picture untouched repeats the error under new vocabulary.**

## When does a restart of an agile transformation pay off?

A restart pays off when three conditions are met at the same time. The company can name a measurable business result that agile working can reach. At least one member of the executive team takes responsibility for the programme and changes their own behaviour to do so. And the teams receive decision rights they did not have before. If one of these conditions is missing, a second attempt costs time again without changing the situation.

The starting point is usually a programme that began as a method rollout. Training courses, role titles and events such as sprint planning or the daily scrum can be introduced within a few months, and they are visible. The effect arrives only when decisions are taken faster, priorities stay stable and teams can finish their work without asking three levels of hierarchy. The 2020 Scrum Guide describes Scrum as a framework that helps people, teams and organisations generate value through adaptive solutions. It names three accountabilities, the Product Owner and the Scrum Master as well as the Developers, and it presumes that the organisation lets these accountabilities be exercised.

Where that does not happen, a familiar pattern emerges, described in the article on [agile rituals without effect](/en/blog/agile-rituals-cargo-cult/): the form stays and the substance disappears. A restart cures this pattern only if it starts from the surrounding conditions.

## Why did the first attempt fail? A root-cause analysis

In practice the first attempt fails for one of five reasons, which you can tell apart by asking the people involved. The analysis takes two or three conversations per division and provides the basis for the decision about the way forward.

The first reason is a missing business objective. The programme was called "becoming agile" and had no metric that was supposed to move. Neither success nor failure can then be demonstrated, and every side interprets the situation according to its own position. The second reason is missing sponsorship. The executive team approved the rollout but did not change its own way of working: it keeps planning in annual budgets with fixed scope and demands monthly status reports in the old format. The third reason is teams without decision rights. The Product Owner may not set the order of work because functional departments or project managers dictate it.

The fourth reason lies in the organisation itself. Teams cut by function, for example with analysis and development separated and testing handled elsewhere, create hand-overs that even perfectly practised Scrum does not remove. The fifth reason is the support model. Agile coaches have taught the practices but have not taken responsibility for results, or the teams have become dependent on them, as the article on [agile coaches](/en/blog/agile-coaches-help-or-dependency/) describes.

**Cause and consequence for the second attempt**
Criterion | Typical symptom | Consequence | With Niehues Consulting
No business objective | No metric, each side judges differently | Correction: set objective and baseline, then continue | Understand phase with a measurable business result and baseline
No sponsorship | Old reporting and planning formats run in parallel | Restart only with a named sponsor and changed leadership behaviour | Clarifying who decides, who delivers, who uses
No decision rights | Product Owner without power to prioritise | Correction: put the rights in writing | Decision paths and interfaces before the start
Organisation by function | Many hand-overs, long waiting times | Restart with a new team structure along the value stream | Organisation design from the delivery perspective
Dependence on coaches | Teams stall without support | Correction: hand over roles, clarify accountability for results | Operations owned by the company from day one

The table shows that three of the five causes can be fixed by a correction, whereas two, missing sponsorship and an organisation cut by function, demand a genuine restart. If you find more than two causes, treat the transformation as a new undertaking with its own decision by the executive team.

## Restart, correct or stop: which decision fits?

The decision follows a checklist of seven questions answered with yes or no. With at least five yes answers a restart is justified. With three or four, a correction of the running programme is sufficient. With fewer than three, you should end the programme and allocate the resources to other initiatives.

1. Is there a business result with a metric and a baseline that faster delivery can improve?
2. Has a member of the executive team taken responsibility for the programme and agreed to change their own planning and reporting?
3. May Product Owners determine the order of their team's work?
4. Can teams complete their work without waiting for more than two functional departments?
5. Is there at least one team that has delivered results the business unit confirms?
6. Are the people involved prepared to accept a second attempt with a clear time limit?
7. Is capacity for coaching and enablement planned without endangering ongoing delivery?

The time limit in the sixth question matters. A second attempt without a stop criterion becomes a permanent task on which expectations and disappointments pile up. Set a review date after ninety days with a metric that decides whether the programme continues. The metric can come from everyday delivery, for example the cycle time from the start of work to release, or the number of initiatives running at the same time.

## What does the second attempt look like? Five steps

A second attempt succeeds when it starts smaller than the first and aims at a concrete result. Five steps structure the approach.

In the first step the executive team fixes a business result, for instance shortening the time from order to delivery of a service by a defined amount. The baseline is measured, not estimated. In the second step it chooses a value stream in which the result is attainable and cuts the teams along that value stream rather than along functions. The third step settles the decision rights in writing: who sets priorities, who decides on budget, who accepts results. In the fourth step the teams work with one simple method, Scrum where the value stream produces increments, Kanban where operational work flows in continuously, and they measure cycle time and throughput from the beginning. In the fifth step the executive team checks after ninety days whether the metric has moved and decides on extending the approach to further value streams.

In his 2014 book "Accelerate", John Kotter describes an operating model in which the classic hierarchy and a network of volunteer employees exist side by side. For a restart this offers a practical thought. The hierarchy does not have to be rebuilt at once for a value stream to work in an agile way. It has to give the network room and decision rights, and make sure both systems pursue the same goals.

**When a change of method makes sense**
Moving from Scrum to another framework does not remove the causes listed in the table as long as objective, sponsorship and decision rights are missing. A change makes sense when the work itself does not suit the method, for example operational work with irregular intake, for which Kanban fits better than sprints. The article on [method FOMO](/en/blog/method-fomo-companies-chasing-every-new-framework/) explains why a new framework rarely solves the real problem.

## What does a second attempt cost, and what does waiting cost?

The direct costs of a second attempt consist of the working time of the teams involved as well as coaching and enablement. They are lower than those of the first attempt when you build on what exists: roles are named, teams know the events, and employees have gathered experience. The cost of waiting arises from delayed delivery and from fading credibility. A programme that runs for two years without a measurable result loses the backing of employees and makes the next initiative harder to start.

A simple calculation helps with the assessment. Multiply the value that a shorter lead time in the chosen value stream creates per week by the number of weeks the programme needs to reach a reliable decision. The result is the upper limit of what the restart may cost. Scope and terms of an engagement are discussed in the free initial consultation.

## Who is accountable for the transformation in the second round?

Accountability sits with a member of the executive team or with the divisional head who steers the value stream. This person takes the decisions that teams cannot take, such as budget reallocations and team structures as well as priorities between divisions. An additional staff unit for agile transformation does not replace this accountability. It can pool method knowledge and support teams, but it has no authority over business units and therefore cannot remove obstacles that originate in leadership.

As a rule of thumb, any obstacle that leads a team to the same point twice goes to the desk of the accountable executive and is decided within an agreed period. Where this rhythm is missing, the pattern of the first attempt repeats.

## Restarting with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. As delivery manager, project manager or product owner he works in engagements where a transformation has to produce results.

The approach follows the Niehues Delivery Model with its three phases. For a second attempt, three of its checking questions matter most: Which business result should change measurably? Who decides, who delivers, who uses? Which metric shows after 90 days that the solution has landed? This turns a disappointing method rollout into an undertaking with an objective, an accountable owner and a review date. The entry point is a free initial consultation of 30 minutes, which you can arrange via the [contact page](/en/#kontakt). What remains of Scrum after the first year in a mid-sized company is described in the article on [Scrum in mid-sized companies](/en/blog/scrum-mid-sized-companies-after-first-year/).

**Conclusion**
A restart of an agile transformation succeeds when the cause of the first attempt is understood, the executive team takes accountability and the teams receive decision rights. The seven-question checklist separates the restart from the correction and from stopping. A review date after ninety days with a metric prevents the second attempt from turning into a permanent task.

**Sources**
- Schwaber, Sutherland: The Scrum Guide, guide, 2020
- Kotter, John P.: Accelerate: Building Strategic Agility for a Faster-Moving World, book, 2014

## Frequently asked questions

### Why do agile transformations fail?

Agile transformations usually fail on the conditions of the rollout. Frequent causes are a missing business objective, missing sponsorship, teams without decision rights and an organisation that forces hand-overs between functions. Switching the method does not change any of these.

### How do you know an agile transformation has failed?

An agile transformation has failed when, after one or two years, no delivery metric has measurably improved. Roles and ceremonies prove nothing. Compare cycle time, the number of parallel initiatives and the satisfaction of the business units with the baseline.

### Should we restart a failed agile transformation or stop it?

A restart is justified when at least five of the seven checklist questions in this article are answered with yes. With three or four yes answers a correction of the running programme is sufficient. With fewer, end the programme and assign the resources to other initiatives.

### How long does a second attempt take?

A second attempt needs a first review point after ninety days. By then a metric agreed in advance must have moved in one value stream. Extension to other divisions follows only after this review and takes several quarters, depending on the number of value streams.

### Who should lead the transformation after a restart?

Leadership belongs to a member of the executive team or to the divisional head who steers the chosen value stream. An agile coach or staff unit supports the work but cannot replace decisions that only management can take.

### Do we need a different framework after the restart?

A different framework is needed only when the work does not fit the current method. Kanban suits operational work with irregular intake better than Scrum, whereas Scrum suits product development in fixed cycles. Objective, sponsorship and decision rights influence the outcome more than the choice of framework.

### How can we tell that the restart is working?

The restart is working when the agreed metric has moved after ninety days and the business unit confirms the delivered results. Further signs are shorter waiting times between teams and fewer initiatives running in parallel.

### How much does a second attempt at an agile transformation cost?

The costs consist of the teams' working time as well as coaching and enablement, and they are usually below those of the first attempt because roles and experience already exist. Scope and terms of an engagement are discussed in the free initial consultation.