Scrum — the framework, not the religion.

Scrum is the most over-claimed and under-read framework in modern software. Almost every team I walk into says they "do Scrum". Almost none of them have read the Scrum Guide in the last three years. The Guide is fourteen pages. It is free. It takes thirty minutes to read end to end. That nobody on the team has done so is the first signal that what's actually running is not Scrum. It's a folk-memory of Scrum, mediated through whichever certified Scrum Master ran the onboarding, weathered by however many sprints the team has limped through since.

This issue is not a manifesto-style defence of the framework. Scrum is not sacred. It's a defined set of roles, events and artefacts designed to deliver value in two- to four-week cycles. It works brilliantly for some teams, badly for others, and not at all for a handful. The honest move is to know what it actually says, decide whether the assumptions hold for your situation, and then commit to running it as written, or pick something else. The half-measure is the failure mode.

Three roles, five events, three artefacts.

Scrum is small. The whole framework fits on a single sheet: three accountabilities, five events, three artefacts. Everything else (story points, velocity, burndown charts, planning poker, Jira workflows) is convention, not Scrum. Treating those conventions as part of the framework is most teams' second mistake.

The three roles, sharp.

The Product Owner owns the what. They own the Product Backlog. They set ordering. They accept or reject what the team builds. The 2020 Guide is unambiguous: the PO is one person, not a committee, and the team and stakeholders respect that ordering even if they disagree with it. A PO who can't say no, to stakeholders, to the CEO, to engineering wanting to refactor, isn't doing the role. Read more on the PO Piece for what this looks like in practice.

The Scrum Master owns the process. They are accountable for the team's effectiveness. That means the events running well, blockers being removed, and the organisation around the team understanding what Scrum requires. The 2020 Guide pointedly dropped the "servant leader" language that had defined the role for a decade. The SM is now described as a true leader who serves the team. A quiet but important shift. Servant-leader had become an excuse for passivity. The new framing puts the SM as a leader with real authority on process.

The Developers own the how. Note that this is plural and that the 2020 Guide retired the term "Development Team". There are Developers within a Scrum Team, not a sub-team. That sounds pedantic but it has a point: it removes the implicit hand-off between "the business" (PO) and "engineering" (Dev Team). There is one Scrum Team with one set of accountabilities, internally divided into who owns the what, the how, and the process. Three accountabilities, one team.

The 2020 changes most teams missed.

The Scrum Guide was rewritten in November 2020 and the changes were material. Most teams still run a pre-2020 mental model. Four shifts worth knowing:

• "Development Team" became "Developers". One Scrum Team, three accountabilities, not a Scrum Team containing a Development Team.
• "Servant leader" became "true leader who serves". The Scrum Master has real authority on process, not just facilitation.
• The Product Goal was added. A new commitment tied to the Product Backlog, a longer-horizon objective the sprints ladder up to. Most teams skip this and run sprints with no Product Goal, which is why the work feels directionless after a quarter.
• The framework was de-jargoned. "Best practices" became "options". "Mandatory" became "intended". The Guide moved closer to being a framework you adapt and further from being a rulebook you follow. Most consultancies haven't updated their training to match.

Where Scrum lands.

Scrum was designed for a specific shape of team and work: five to nine people, ongoing product work, a clear PO, and the ability to release something usable every fortnight. When those four conditions are met, it's an excellent framework. The cadence creates predictability. The PO role concentrates decision-making. The retrospective compounds learning. The Increment forces the team to define "done" honestly. Most genuinely Scrum teams, run well, deliver more value per quarter than any other shape I've worked with.

Where it lands badly is also predictable. Teams smaller than four don't have the ceremony economics. The overhead of five events with four people eats too much of the week. Support-heavy teams, where most of the work is unplannable interrupts, can't commit a sprint backlog meaningfully. Kanban is a far better fit. Hardware-heavy teams can't deliver an Increment every fortnight, full stop. Anything where the customer can't see or react to a fortnightly Increment loses the feedback loop the framework depends on.

Cargo-cult Scrum.

The most common pathology I see isn't bad Scrum. It's Scrum-shaped. The team runs the five events. The Jira board has the three columns. There is a Scrum Master title. But the PO has no authority, the Developers don't own the how, the sprints regularly extend, the Increment doesn't ship, and the retro hasn't produced an action in eighteen months. The form is there. The substance has been quietly removed, usually by leadership decisions taken outside the team's awareness.

The fix is rarely "more Scrum training". The fix is leadership clarity on three things: is the PO actually empowered to say no, are the Developers actually allowed to choose the how, and is the organisation willing to accept what an honest Increment costs when "done" is enforced. If the answer to any of those is no, run something else and stop calling it Scrum. The mis-naming is what makes it expensive.

How we use this at Product Pieces.

When we plug into a team that says it runs Scrum, the first session is usually a re-read of the Guide together. Twenty minutes. Everyone in the same room, comparing what they think Scrum is against what the fourteen pages actually say. Eight times out of ten the team has been carrying around assumptions that aren't in the Guide: "sprints can't change scope", "the PO sets velocity", "the Scrum Master assigns tickets". Clearing those out, in one session, fixes more than any framework swap would.

If the diagnostic shows the four conditions for Scrum to land are absent, we say so. Scrum is a tool, not a religion. The honest call is sometimes Kanban, sometimes a hybrid, sometimes no framework at all. The work decides; the framework follows.

Next issue: the Sprint itself, and why the timebox is the point, not the rituals around it. All issues →