What Makes Agile Software Development Agile?

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15%). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

💡 Research Summary

The paper tackles the fundamental question “What makes agile software development agile?” by conducting a large‑scale empirical study that links development methods, concrete practices, and the perceived agility of project disciplines. An international online questionnaire was distributed to 556 software practitioners from a variety of domains and regions. The survey collected three types of information: (1) the development methodology used (e.g., Scrum, XP, Kanban, Waterfall), (2) the specific agile‑related practices employed (daily stand‑up, pair programming, continuous integration, test automation, frequent customer feedback, etc.), and (3) the perceived “degree of agility” for each standard project discipline (requirements management, scheduling, risk handling, quality assurance, etc.). Respondents rated each discipline on a five‑point Likert scale indicating how closely it aligned with agile principles such as customer focus, responsiveness to change, and short feedback loops.

Statistical analysis revealed that pure traditional projects (no agile practices) and pure agile projects (no traditional procedures) together account for less than 15 % of the sample (approximately 7 % and 8 % respectively). The overwhelming majority of teams operate in hybrid configurations, blending elements of both paradigms. This confirms the anecdotal observation that agile adoption is rarely a binary switch but rather an evolutionary adaptation to organizational context.

A multivariate regression was performed to assess the relative impact of the chosen methodology versus the set of practices on the agility scores of the disciplines. The results show that practice selection explains a significantly larger portion of the variance than methodology choice. For example, continuous integration, short sprint cycles, and regular customer reviews each raise discipline agility scores by roughly 0.6–0.9 points on the five‑point scale, whereas merely declaring the use of Scrum or XP contributes only about 0.2–0.3 points. Correlation analysis further identified clusters of practices that tend to co‑occur (e.g., daily stand‑up with short sprints) and clusters that are negatively associated with agility (e.g., heavy documentation gates, fixed‑phase approvals).

From these findings the authors draw several key insights:

1. Agility is practice‑driven, not method‑driven. The mere adoption of a named framework does not guarantee agile behavior; it is the concrete practices that teams actually perform that determine the level of agility.
2. Hybrid models dominate. Over 85 % of respondents use a mixture of traditional and agile elements, suggesting that agility is a spectrum rather than a dichotomy.
3. No practice is a silver bullet. No single method or practice guarantees high agility, nor does any single element categorically prevent it. The overall combination and the way practices are integrated matter most.
4. Organizational context matters. Since methods have limited explanatory power, factors such as culture, leadership, team autonomy, market volatility, and regulatory constraints likely play a decisive role in shaping how agile a project truly is.
5. Implications for improvement initiatives. Organizations seeking higher agility should focus on introducing and institutionalizing high‑impact practices (continuous integration, short feedback loops, frequent stakeholder collaboration) rather than simply “checking the box” of a particular framework.

The paper also acknowledges limitations: the reliance on self‑reported perception introduces subjectivity, and the cross‑sectional design cannot capture longitudinal evolution of practices. Moreover, the survey did not explicitly model non‑process variables (company size, domain, regulatory pressure) that may mediate the relationship between practices and agility.

Future research directions proposed include (a) in‑depth case studies to map how hybrid configurations are concretely instantiated, (b) quantitative modeling of contextual factors (e.g., market uncertainty, organizational size) to extend the explanatory framework, and (c) development of a standardized, validated metric for “degree of agility” to enable more reliable cross‑study comparisons.

In summary, the study provides robust empirical evidence that agility cannot be defined solely at the process level. While development methods provide a structural backdrop, it is the selection, combination, and consistent execution of specific practices—within the broader organizational environment—that truly make software development agile. This nuanced view challenges simplistic “agile‑or‑not” narratives and offers a roadmap for both scholars and practitioners aiming to understand and improve agility in real‑world software projects.