Does Agile Work? The Study of Over a Thousand Projects
The debate about agile ways of working is often driven by anecdotes: one person has seen Scrum rescue a project, another has watched it dissolve into meetings without a plan. In 2015, researchers Pedro Serrador and Jeffrey Pinto contributed something that had long been missing — numbers at scale. Their study 'Does Agile Work?' was published in the International Journal of Project Management.
It is one of the most cited quantitative studies of agile methods, and its answer is more nuanced than either the enthusiasts' or the sceptics'. That makes it a good starting point for anyone who wants to base their choice of working method on evidence rather than belief, tradition, or whatever happens to be popular at the moment.
What does the research say?
Serrador and Pinto analysed data from over a thousand projects across industries and countries. Instead of sorting projects into 'agile' and 'traditional', they measured the degree of agility — what share of the work was done iteratively — and set it against project outcomes. Success was measured in two ways: efficiency, meaning how well the project kept to time, budget and scope, and broader success in the form of satisfied stakeholders and business goals achieved.
The result: a higher degree of agile, iterative working had a statistically significant positive relationship with both measures of success. This held not only for software projects but across several industries. In other words — in this large dataset, projects that worked more iteratively did better on average.
But the researchers are careful with the nuances. A correlation is not a recipe: the study does not prove that agile fits everywhere, and it does not say that planning is unnecessary. How well the method works depends on the context — including what kind of requirements the project has and how clear the goal is. The real conclusion is that the choice of working method is a genuine decision with genuine consequences, one that should be made deliberately rather than out of habit.
What does this mean for you as a project manager?
Choose your working method based on the conditions, not on fashion. If requirements are uncertain and learning along the way matters, the evidence favours more iterative elements. If requirements are stable and dependencies are hard, a more traditional plan may be right. Being able to justify the choice — to the team, the sponsor and yourself — is part of the profession, whichever approach you land on.
Dare to mix. The study measured degree of agility, not methodological purity. A hybrid setup — for example iterative development inside an overarching phase plan — is entirely legitimate, as long as it is well thought through and clearly communicated.
Anchor the choice with your sponsor and steering group. An agile way of working changes what a steering group can expect in terms of reporting and decision points. That conversation needs to happen early, not when the first delivery looks different from a traditional schedule and surprise has already turned into irritation.
How to practise this
Explaining and defending a choice of working method to a sceptical sponsor — or to a team used to something else — is a conversation many project managers face unprepared, even though the arguments exist in the research. In Project-simulator you practise it — and other difficult project conversations — against AI counterparts in a safe simulator environment, with evidence-based feedback that points to your own words. You can try it free for a week.
In Project-simulator you practice these conversations against an AI counterpart and get feedback grounded in research like this.
Try free for 7 days