2 min read research · delivery
Why software teams miss deadlines: notes from research and practice
My PhD research studies how software teams deliver — agile at scale, metrics, leadership. The most cited finding is also the least glamorous: methodology matters less than the discipline around it.
I lead product teams for a living and research software delivery on the side — a PhD at the Technical University of Cluj-Napoca, with a dozen peer-reviewed papers on agile at scale, delivery metrics, and leadership. Living in both worlds, one question keeps coming back from practitioners: “So which methodology should we use?”
It’s the wrong question, and the research says so fairly loudly.
The methodology wars are mostly noise
Our most cited paper compared agile, waterfall, and iterative approaches across IT projects. The unglamorous finding: the delivery model explains far less of the outcome than people assume. Projects succeed or fail on things that sit underneath the methodology — clarity of requirements, decision latency, the honesty of progress reporting — and every framework can host either discipline or theater.
I’ve watched a “waterfall” hardware-adjacent team out-deliver a “Scrum” team because their weekly review was real: numbers, blockers, decisions. The Scrum team had a better process on paper and worse conversations in the room.
What the metrics work taught me
A later line of our research looked at KPIs for iterative delivery — what’s worth measuring if you want adherence to the model rather than vanity charts. Three practical takeaways I use with my own teams:
- Measure flow, not activity. Cycle time and work-item age tell you the truth. Story points burned tell you a story.
- Instrument the policy, not just the outcome. If your rule is “no work without acceptance criteria,” measure how often it’s violated. Outcomes lag; policy adherence leads.
- Fewer metrics, reviewed more often. A small set that leadership actually discusses weekly beats a dashboard nobody opens.
Leadership is the multiplier
The leadership papers converge on something practitioners know intuitively: the same framework produces wildly different results under different leaders. The mechanism is mundane — leaders set decision latency. Teams miss deadlines waiting for answers far more often than they miss them writing code.
Why I still do research
Practice keeps you honest about what matters; research keeps you honest about what’s actually true. Most delivery advice online is a survivor story with a sample size of one. Peer review is slow and frustrating and it regularly kills my favorite hypotheses — which is exactly the point.
The full list of papers is on the Research page. If you want to argue about any of them, I’d genuinely enjoy that.