Enterprise agile is a large industry built on a small amount of proof. Frameworks for scaling agility across hundreds or thousands of people are marketed with the confidence of settled science, complete with certifications, maturity models and consultants to install them. The pitch implies a body of evidence behind the recipe. When you go looking for that evidence, it is thinner than the confidence suggests, and knowing how thin should change how you buy.
Ninety percent stories, ten percent study
The most cited synthesis of scaling agile is candid about its own foundations, and the candor is the most useful thing in it. Dikert, Paasivaara and Lassenius (2016) systematically reviewed the research on large-scale agile adoption, covering 52 publications that described 42 industrial cases, and from them extracted 35 challenges and 29 success factors. That sounds like a solid base until you read their methodological caution: roughly 90 percent of the included papers were practitioner experience reports rather than academic studies.
That is a remarkable admission for a field that sells certainty. Experience reports are not worthless. They are how practitioners share hard-won lessons, and there is signal in them. But they are also selection bias in written form. People write up the transformations they are proud of and the ones with a clean narrative. Failures go undocumented, or get reframed as learning. Building a scaling framework on a corpus that is nine parts anecdote is building on sand and painting it to look like rock.
What the review does find is worth more than any framework. The success factors that recur, management support, customizing the model to context, training and coaching, and a genuine mindset shift, are precisely the things a packaged framework cannot supply. Customization is the opposite of a template. The evidence, such as it is, points away from the products being sold.
Where the measurement is actually good
Contrast this with the parts of the field that took measurement seriously. The book Accelerate by Forsgren, Humble and Kim (2018) grew out of four years of research using data from the State of DevOps surveys, analyzed statistically to identify what drives software delivery performance. Its explicit argument was against the conventional wisdom that delivery-team performance does not matter competitively, and it set out to name the organizational capabilities that do. Whatever one makes of its causal claims, its ambition was the right one: measure performance and trace it to specific capabilities rather than to adherence to a branded framework.
That program continues in the DORA State of DevOps report (2024), which now surveys on the order of 39,000 respondents. Its findings are instructive precisely because they are not framework endorsements. Instability in organizational priorities reduces productivity and increases burnout, and that damage persists even under good leadership and good documentation. Transformational leadership is associated with better performance and lower burnout. Internal developer platforms improve productivity but can reduce stability and throughput. None of that is a ceremony you can install. It is context, leadership and capability, measured at scale.
One caution belongs here, in the spirit of the point. The DORA work is cross-sectional survey data, correlational however causally it is sometimes phrased. It tells you what travels together, not always what causes what. That humility is exactly what the scaling-framework industry lacks.
Buy capabilities, not certainty
Put the two bodies of evidence side by side and a buying strategy falls out. The confident scaling frameworks rest, by the admission of the field's own review, largely on experience reports (Dikert, Paasivaara and Lassenius, 2016). The rigorous measurement, where it exists, points not at frameworks but at capabilities, leadership and stable priorities (Forsgren, Humble and Kim, 2018; DORA, 2024). So stop shopping for the framework and start building the capabilities the measured evidence favors.
That means investing in the things the anecdotes and the data both endorse: real management support rather than a maturity certificate, customization to your context rather than a wholesale copy, coaching that builds skill, and above all priorities stable enough that teams can actually finish what they start. The DORA report (2024) suggests priority instability alone can undo a transformation no matter how disciplined its ceremonies.
The practical read
The next time a scaling framework is pitched to you as proven, ask a simple question. Proven by what? If the honest answer is a shelf of success stories, you are being sold anecdote dressed as evidence, and Dikert, Paasivaara and Lassenius (2016) documented the thinness themselves. The parts of this field that measured carefully, from Accelerate onward, never found a framework at the bottom of good performance. They found capabilities, context and leadership. Buy those. They are harder to install and far more likely to be real.
Sources
- Dikert, Paasivaara and Lassenius (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Reviews 42 industrial cases and cautions that roughly 90 percent of the underlying papers are practitioner experience reports rather than rigorous studies. https://doi.org/10.1016/j.jss.2016.06.013
- Forsgren, Humble and Kim (2018). Accelerate: The Science of Lean Software and DevOps. Built on four years of State of DevOps data, it argues delivery performance traces to measurable organizational capabilities rather than to any branded framework. https://itrevolution.com/product/accelerate/
- DORA / Google Cloud (2024). Accelerate State of DevOps Report 2024. Large-scale survey pointing to priority stability, leadership and capabilities, not ceremonies, as what correlates with performance, while remaining correlational data. https://dora.dev/research/2024/dora-report/