What Actually Moves a Software Team
Some teams run the same ceremonies and deliver reliably. Others go through the motions and ship little of value. A seven-year research programme covering nearly 2,000 Scrum teams found that the difference comes down to five measurable factors, and none of them is ceremony adherence.
The situation
Scrum is the default way software organizations arrange their teams. Yet any engineering leader who runs more than a handful of teams sees the same puzzle: identical ceremonies, wildly different results. Some teams keep improving quarter after quarter; others plateau. When leadership asks why, the answers tend to be vague: culture, chemistry, seniority, luck.
For all its adoption, no validated theory existed of what makes Scrum teams effective. Practitioner wisdom was abundant; evidence was not. That gap is what this research programme, run together with The Liberators, set out to close.
Team effectiveness rests on how well a team understands what its stakeholders need, and how quickly it can respond. Continuous improvement, team autonomy, and management support matter because they create the conditions for those two capabilities.
The approach
The research ran for seven years in two phases. Thirteen exploratory field studies inside organizations running Scrum produced a theoretical model of team effectiveness: five high-level factors, thirteen lower-level ones, and the mechanisms connecting them.
The model was then tested with survey data from 4,940 professionals across 1,978 Scrum teams worldwide, one of the largest samples in software engineering research. Structural equation modelling confirmed ten of the twelve hypothesised relationships. The five factors together explained 58% of the variance in stakeholder satisfaction and 35% in team morale.
The collaboration model
The engagement is also a template for how industry and academia can run research together. The Liberators contributed field access, practitioner reach, and deep knowledge of Scrum practice; the academic side contributed research design, validated instruments, and statistical analysis. The programme produced peer-reviewed publications in ACM TOSEM, Empirical Software Engineering, and IEEE TSE, and its validated model now underpins a commercial product.
What the research found
- Responsiveness pays twice. Teams that release to stakeholders frequently show both higher stakeholder satisfaction and higher team morale. Many small releases make complexity manageable and emergent needs visible, and the steady rhythm of shipping is itself motivating.
- Stakeholder concern is the strongest single contributor. Teams that collaborate closely with stakeholders, use reviews to gather real feedback, and share a clear sense of what is valuable had the largest direct effect on effectiveness in the model. Concern alone is not enough: its effect strengthens further when the team can also respond quickly.
- A climate of continuous improvement drives both. Psychological safety, retrospectives that produce actionable change, and an explicit focus on quality raise both stakeholder concern and responsiveness. Teams with a strong improvement climate keep clearing the barriers that would otherwise erode both.
- Autonomy works through learning, not through mandate. Team autonomy showed its strongest effect on the continuous improvement climate, and a modest one on responsiveness. It did not predict stakeholder concern: the mandate to decide how to work is not the mandate to decide what is valuable. Those are different levers, held by different people.
- Management support means removing constraints, not attending standups. Teams that experience clear management support report higher autonomy, stronger improvement climates, and greater stakeholder concern. The mechanism is boundary control: removing constraints in the team’s immediate environment and strengthening the product owner’s mandate.
If some of your teams are effective and others are not, the difference is measurable. The five factors can be observed and assessed team by team, which turns “team chemistry” from an excuse into a diagnostic.
Invest in autonomy where the improvement climate is weak. Strengthen product ownership where stakeholder concern is low. Treat management support as the removal of constraints around the team, not as attendance at its ceremonies. And measure the five factors, not ceremony adherence: a team can hold every meeting in the guide and still miss all five.
The model is not only a diagnosis. It is the scientific foundation of Columinity, The Liberators’ team-improvement product, which lets organisations measure the five factors continuously.
Are your teams delivering but not accelerating?
The blockers are rarely the process. They live in stakeholder collaboration, the improvement climate, team autonomy, and how management engages. All five factors are diagnosable, and addressable.