Scaling Agile and SAFe
Agile methods were built for small co-located teams. Scaling frameworks — SAFe, LeSS, Nexus, Scrum@Scale — exist to handle what those methods do not address: synchronising many teams, meeting parts of the organisation that are not changing, and reconciling team autonomy with an existing hierarchy [1].
The honest position is that we know a good deal about what breaks and very little about which framework fixes it.
1. Scaling breaks the practices that need people in the room
The damage is not evenly distributed. On a large XP project tracked over eighteen months, the engineering practices — continuous integration, testing, refactoring — survived, while the social ones — pairing, on-site customer — eroded [2].
There is a mechanism behind that. The coordination agile relies on is co-located coordination, and it decays with distance faster than people expect: beyond roughly thirty metres, spontaneous communication collapses toward the rate it has between continents [3]. A team on another floor is, for these purposes, already distributed.
The frequency data agrees. Across 21 studies of distributed agile development, distance appears as a communication challenge in 76%, ahead of organisational factors at 52% and team configuration at 48% [4]. The same body of work yields a blunt practical rule: do not distribute a single team — split along boundaries that need less talking.
The largest review of large-scale transformations catalogues 35 challenges in 9 categories, including coordination across multi-team environments, divergent approaches emerging between teams, hierarchical management and organisational boundaries, and integrating functions that are not development [5].
2. What helps is managerial, not technical
The same review names 29 success factors, and the most salient categories are management support, choosing and customising the agile approach, training and coaching, and mindset and alignment [5]. None of them is a practice or a tool.
Two things follow. First, the framework is the cheap part — an organisation that adopts SAFe without management support or coaching has bought a vocabulary. Second, customising the approach is an evidenced success factor, not a deviation from it, which sits awkwardly beside frameworks that present themselves as complete.
3. Read the method, not the sentence
Example — two reviews, two answers. Students ask which framework to pick, and the literature contains both an answer and a refusal.
| A comparative review [6] | A systematic review [7] | |
|---|---|---|
| Claim | SAFe is “the most suitable for working in large organizations with geographically distributed teams” | “there is no one method that suits a particular type of company” |
| Method | Qualitative review of secondary sources; no search protocol, no corpus size, no inclusion criteria, no inter-rater check | 35,215 articles screened → 191 primary studies |
| Venue | A journal in its second volume | IEEE Transactions on Software Engineering |
And the first paper walks its own claim back: the mapping appears in the body, while the conclusion retreats to “a framework that presents good results in one organization can be a failure in another”.
That is the useful lesson, and it is more useful than “nobody says this”. The confident sentence exists, it is weakly evidenced, and its own conclusion does not support it. Ask what method produced the sentence.
How solid is this?
- Nothing here outperforms anything. No scaling framework has been shown to beat another, and the best-evidenced review available declines to rank them deliberately [7].
- Dikert is mostly experience reports — roughly 90% by its authors’ own count, and they state they “decided not to make quantitative interpretations”. Its challenge and success-factor lists are frequencies of mention, not effect sizes [5].
- Almeida has no stated protocol, and its single outcome figure is borrowed from another study. Cite it as an example of a weakly supported claim, not as support for one [6].
- Herbsleb is a research roadmap, not a study; the thirty-metre finding comes from older communication research that it summarises [3].
- Elssamadisy is one project reported by a participant, unpublished and internally dated [2].
- SAFe’s own text is cited only for what SAFe is [1] and for nothing else. It is written by the framework’s creator and was not read for this review.
Acknowledgments
This page adapts material from lectures by Eduardo Miranda and David Root [8] on software project management.
References
- D. Leffingwell,SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020.
- A. Elssamadisy,“XP On A Large Project - A Developer’s View.” 2001.
- J. D. Herbsleb,“Global Software Engineering: The Future of Socio-technical Coordination,” in Future of Software Engineering (FOSE ’07), May 2007, pp. 188–198. doi: 10.1109/FOSE.2007.11.
- Y. I. Alzoubi, A. Q. Gill, and A. Al-Ani,“Empirical studies of geographically distributed agile development communication challenges: A systematic review,” Information & Management, vol. 53, no. 1, pp. 22–37, Jan. 2016, doi: 10.1016/j.im.2015.08.003.
- K. Dikert, M. Paasivaara, and C. Lassenius,“Challenges and Success Factors for Large-Scale Agile Transformations: A Systematic Literature Review,” Journal of Systems and Software, vol. 119, pp. 87–108, 2016, doi: 10.1016/j.jss.2016.06.013.
- F. Almeida and E. Espinheira,“Large-Scale Agile Frameworks: A Comparative Review,” Journal of Applied Sciences, Management and Engineering Technology, vol. 2, no. 1, pp. 16–29, Mar. 2021, doi: 10.31284/j.jasmet.2021.v2i1.1832.
- H. Edison, X. Wang, and K. Conboy,“Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review,” IEEE Transactions on Software Engineering, vol. 48, no. 8, pp. 2709–2731, Aug. 2022, doi: 10.1109/TSE.2021.3069039.
- D. Root,Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.