Another Agile Transformation Is Not a Delivery Strategy

Delivery decays in a recognizable pattern. Commitments made in quarterly planning arrive two weeks late, then a quarter late. Nobody can name the team responsible, because every team can show that its own part finished on time. The escalation path produces more forums, more alignment meetings, more status reporting, and the dates keep moving. At some point a senior voice proposes a transformation: a new operating model, a framework with a name, a programme office and a coaching budget.

That proposal deserves a harder question than it usually gets. It commits money and management attention that could instead address the actual constraint. The evidence behind a broad transformation promise is also thinner than many business cases imply.

What the research will actually carry

Start with the strongest claim available. Stettina et al. (2021) surveyed teams, programmes and portfolios and found that respondents in organizations further along in agile transformation reported better organizational performance. The direction is favourable. It is also the only retained finding that speaks to performance at the level of the organization rather than the team.

The limits shape how much weight that finding can take. The data are perceptions collected at a single point in time from 134 respondents, and a substantial share of them hold transformation roles, which means the people assessing the change are often the people running it. There is no comparison group of organizations that did not transform, so the study cannot separate the effect of transformation from everything else happening in those companies at the same time. Customer satisfaction was not among the measured outcomes. Read honestly, this supports a cautious association between transformation maturity and better reported performance outcomes, and nothing stronger.

The review helps explain why broad causal claims need caution. Dikert et al. (2016) reviewed 52 publications covering 42 industrial cases, and almost 90% of those publications were experience reports. Those accounts are useful for understanding reported challenges and success factors. They do not establish that a framework caused a delivery outcome. A business case for a scaled rollout therefore needs a more specific argument than the framework name and a list of successful adoptions.

The label does not identify the active ingredients

The case research becomes considerably more useful once you stop reading it as a verdict on frameworks and start reading it as a description of mechanisms.

Paasivaara et al. (2018) documented a transformation at a large telecommunications organization that proceeded through stepwise experimentation and deliberate tailoring of the model to context, supported by shared learning and coaching structures. The same case records a goal that did not survive contact with the product: full team interchangeability proved difficult to reach where deep domain knowledge was required. That failure is more instructive than most successes. It shows a specific structural assumption inside a scaling model breaking against a specific property of the product, which is the kind of detail a framework name cannot carry.

Dingsøyr et al. (2022) followed a very large programme across a change of method generation. The programme reorganized from feature-oriented to product-oriented teams, changed how teams coordinated, and moved from infrequent releases to daily deployments. This was a substantial increase in deployment frequency and a clear change in delivery capability. It does not, by itself, establish better customer value, quality or predictability. Architecture, platform, team design and governance also changed during the same period, so the method cannot be isolated as the cause. Copying the method name alone would leave those concurrent conditions unaddressed.

Carroll et al. (2023) describe how failing to embed and sustain a large-scale agile method can unravel transformation efforts. Their exploratory case shifts attention beyond initial adoption to whether changed practices become normal work. It does not establish how often this happens across organizations.

A mechanism contract

What follows is an unvalidated diagnostic. It is derived from the synthesis above rather than tested in research, and it should be treated as a way of structuring a decision, not as a validated instrument. Its only claim is that it makes a weak transformation argument visibly weak before the money is committed.

Before approving any change to how delivery works, write five fields on one page.

Delivery outcome. The observable thing that must change, stated so that someone outside the programme could verify it. Not maturity, not adoption, not engagement.

Current constraint. Where the delivery outcome is actually being held up today, supported by data you already have.

Proposed mechanism. The specific structural change expected to alter that constraint, described concretely enough that an engineer could recognize it in the codebase or the org chart.

Disconfirming signal. What you would observe within a defined window if the mechanism is not working. Agree this before you start.

Management decision. What leadership will do when the disconfirming signal appears, named in advance.

A generic worked example. The delivery outcome is that changes reach production within five working days of being ready for review, measured on thirty completed items. The current constraint is that review waiting time consumes the majority of elapsed time, because a small group of approvers holds sign-off across several teams and reviews queue behind their availability. The proposed mechanism is to move approval authority for a defined class of change into the owning teams and to split the shared component so that ownership matches the review boundary. The disconfirming signal is that after eight weeks, review waiting time has not moved, or has moved only by shifting the queue to a different bottleneck. The management decision is that leadership then examines component ownership and architecture directly, rather than adding review capacity or another coordination forum.

Filling this in for a proposed transformation is uncomfortable, and the discomfort is the point. A programme that cannot name a constraint, a mechanism and a disconfirming signal is a reorganization looking for a justification.

Where this argument runs out

This is a reading of a small number of studies. The organization-level finding rests on what people inside transformations reported about themselves, and the two detailed programme accounts describe two particular organizations with their own products, histories and constraints. Neither tells you what will happen in yours. The mechanism contract has not been evaluated against alternatives, and it will not rescue a decision that leadership has already made politically.

What the evidence does support is a shift in where the burden of proof sits. The question in front of a delivery leader is not which framework to adopt. It is whether the organization can state, before committing substantial attention, what constraint is being removed, by what mechanism, and what evidence would prove the bet wrong.

References

Carroll, N., Conboy, K., & Wang, X. (2023, March 24). From transformation to normalisation: An exploratory study of a large-scale agile transformation. Journal of Information Technology, 38(3), 267–303. https://doi.org/10.1177/02683962231164428

Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108. https://doi.org/10.1016/j.jss.2016.06.013

Dingsøyr, T., Bjørnson, F. O., Schrof, J., & Sporsem, T. (2022, November 8). A longitudinal explanatory case study of coordination in a very large development programme: The impact of transitioning from a first- to a second-generation large-scale agile development method. Empirical Software Engineering, 28(1), 1. https://doi.org/10.1007/s10664-022-10230-6

Paasivaara, M., Behm, B., Lassenius, C., & Hallikainen, M. (2018, January 11). Large-scale agile transformation at Ericsson: A case study. Empirical Software Engineering, 23(5), 2550–2596. https://doi.org/10.1007/s10664-017-9555-8

Stettina, C. J., van Els, V., Croonenberg, J., & Visser, J. (2021). The impact of agile transformations on organizational performance: A survey of teams, programs and portfolios. Lecture Notes in Business Information Processing, 86–102. https://doi.org/10.1007/978-3-030-78098-2_6