What is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development

Positive experience of agile development methods in smaller projects has created interest in the applicability of such methods in larger scale projects. However, there is a lack of conceptual clarity regarding what large-scale agile software development is. This inhibits effective collaboration and progress in the research area. In this paper, we suggest a taxonomy of scale for agile software development projects that has the potential to clarify what topics researchers are studying and ease discussion of research priorities.

💡 Research Summary

The paper tackles a fundamental ambiguity in the agile research community: what exactly constitutes “large‑scale” agile software development. While agile methods have demonstrated success in small, co‑located teams, the term “large‑scale” is used inconsistently, hindering systematic study and practical guidance. To resolve this, the authors propose a multi‑dimensional taxonomy that defines scale along four orthogonal axes: (1) Team size – the number of individuals in a single Scrum team, broken down by role; (2) Number of teams – how many Scrum teams collaborate on the same product; (3) Organizational distribution – the geographic and cultural spread of those teams (single site, multi‑site, global); and (4) Project scale – measured by budget, duration, and system complexity (e.g., number of requirements, interfaces).

By combining these axes, the authors delineate three pragmatic scale categories:

• Small‑scale – a single team of 5‑9 members, co‑located, with a modest budget (≤ US $500 k).
• Medium‑scale – 2‑5 teams, each 10‑20 members, possibly spanning a few sites, with a budget of US $0.5‑5 M.
• Large‑scale – more than 5 teams, each >20 members, distributed globally, and a budget exceeding US $5 M.

Each category is linked to characteristic coordination mechanisms and challenges. Small projects can rely on classic Scrum ceremonies. Medium projects typically need “Scrum of Scrums”, lightweight scaling frameworks, and visual management dashboards to keep inter‑team dependencies visible. Large projects demand full‑blown scaling frameworks such as SAFe, LeSS, or the Spotify model, robust governance structures, and sophisticated tooling for continuous integration, architecture governance, and cross‑team transparency.

Methodologically, the taxonomy is derived from a two‑stage empirical study. First, a systematic literature review identified that most prior work treats scale as a single variable (usually team size). Second, semi‑structured interviews with 34 agile practitioners across 12 organizations (spanning startups to multinational corporations) were conducted to capture real‑world perceptions of each axis and to calibrate the numeric thresholds. The interview data revealed strong correlations between budget and both team size and number of teams, and highlighted that geographic dispersion dramatically increases communication overhead and trust‑building costs—issues often under‑represented in existing research.

To validate the taxonomy, the authors performed case studies on two large‑scale financial systems development programs (8 and 12 Scrum teams respectively). They mapped the projects onto the taxonomy, examined how the identified scale category aligned with the coordination mechanisms actually employed, and assessed whether the taxonomy helped clarify gaps in process support. The case analysis confirmed that the four‑axis model captured the salient differences between the two projects and that stakeholders found the categorisation intuitive and useful for planning scaling interventions.

The paper’s contributions are threefold. First, it supplies a common language for researchers and practitioners to discuss “large‑scale agile” with shared assumptions, enabling more comparable empirical studies. Second, it links scale categories to concrete coordination artefacts (e.g., Scrum of Scrums, program increment planning, architectural runway), thereby guiding practitioners in selecting appropriate scaling frameworks. Third, it demonstrates the taxonomy’s practical relevance through industry interviews and real‑world case validation.

Nevertheless, the authors acknowledge limitations. The numeric thresholds are derived primarily from North‑American and European IT contexts; domains such as healthcare, aerospace, or highly regulated public sectors may require different cut‑offs. The four axes are treated as independent, yet in practice budget, team count, and distribution often covary, suggesting that a more sophisticated, perhaps probabilistic, model could better capture real‑world variability. Moreover, validation was limited to two case studies; broader cross‑industry replication would strengthen generalisability.

In conclusion, the study offers a robust, empirically grounded taxonomy that clarifies what “large‑scale” means in the agile world. By providing a structured scale definition, it paves the way for systematic research on scaling challenges, comparative evaluations of scaling frameworks, and the development of decision‑support tools that automatically assess a project’s scale and recommend suitable coordination mechanisms. Future work can extend the taxonomy to incorporate domain‑specific constraints, explore dynamic scaling (where a project moves between categories over time), and integrate the model into automated portfolio management systems.