Scrum, at its core, is one thing: a team commits to deliver something in a fixed timeframe. That’s it. Two weeks, a defined scope, a promise. Everything else — the ceremonies, the roles, the tools, the certifications — is optional scaffolding that may or may not help you keep that promise.
I realise that’s a reductive thing to say about a methodology that has spawned an entire industry of coaches, frameworks, and enterprise scaling patterns. But I’ve spent enough years watching Scrum implementations succeed and fail to believe it’s also the most useful thing to say. When teams forget that the commitment is the point, they end up performing Scrum instead of doing it.
Take the backlog. There’s a persistent belief that the Product Organisation owns it. I’d argue that’s wrong. The Product Organisation brings business priorities and market insight to the table — that’s their expertise, and it’s essential. But the backlog is influenced by technical debt, operational constraints, dependencies, infrastructure needs, and a dozen other factors that only the team can see. The team manages the backlog. Product informs it. The distinction matters because when Product “owns” the backlog, you get a prioritisation exercise. When the team manages it, you get a delivery plan.
I spent more than half my career without any of these tools — no Jira, no Monday.com, no sprint boards. Three different startups, all successful, all built by small groups of people who were aligned on what mattered. The founders were in the room. We didn’t need sprint reviews because they saw the progress firsthand. We didn’t write internal release notes because everyone was involved. The commitment existed; the ceremony didn’t.
That’s not a scalable model, obviously. When things get bigger, you need the tools and the structure. But the tools are exactly that — tools.
“A fool with a tool is still a fool” — Ron Weinstein
Jira doesn’t make you agile. It makes your non-agility visible in a more organised way. The tool works when the commitment culture already exists. It fails — expensively — when it’s used as a substitute for that culture.
Which brings me to the uncomfortable question: what problem is Scrum actually solving? The answer is uncertainty. Specifically, the business risk that comes with uncertainty. Uncertainty is hard for humans in general, but it’s particularly hard to manage in large, established organisations where entire departments exist to reduce it.
Scrum addresses this by shrinking the risk window. Instead of betting twelve months of budget on a project that might miss the mark, you bet two weeks. At the end of those two weeks, you have something concrete — not a status report, not a Gantt chart update, but working output you can evaluate. The timebox makes it safe to be wrong, because being wrong for two weeks is a manageable loss.
This is why the “Agile transformation” driven by IT departments almost always fails. The transformation has to change how the business thinks about risk and commitment, not just how engineers organise their work. When it’s an IT initiative, you get process without culture. You get PMOs translating between “Agile teams” and “traditional management.” You get rigid frameworks designed to control teams that were supposed to be self-organising. ITIL anyone?
The management, business, and sales teams end up frustrated because they can’t get straight answers about delivery dates. The engineering teams are frustrated because they’re doing standups and retrospectives but nothing has actually changed about how decisions get made. Everyone is performing agility. Nobody is being agile.
I recently came across a 1986 Harvard Business Review article, “The New New Product Development Game” by Takeuchi and Nonaka — the paper that gave Scrum its name, borrowed from rugby. What struck me is how much it emphasises things that modern Scrum implementations have lost: hard work, closely-knit teams with overlapping functions, and absolute focus. The paper describes product development as a relay race where the baton never actually leaves the field. Everyone runs together.
Somewhere between 1986 and today, we turned that into a process with certified roles and prescribed meetings. The commitment is still the point. The question is whether your implementation remembers that.