Most teams I work with tell me they run Scrum. Fewer than half do. Scrum is the default name because it is the best known, not because anyone sat down and decided it fitted the work.
That sounds like a pedantic point about labels. It is not, and the reason is worth spelling out.
The team that was really doing Kanban
I recently worked alongside a team that described itself as Scrum. In practice, tickets were pulled into the sprint continuously. There was no meaningful sprint goal, velocity was recorded but never used to plan, and work carried over every fortnight. When it was pointed out that this looked a lot more like Kanban, the idea was dismissed. The team does Scrum.
The problem was not that they were doing Kanban. Kanban is a perfectly good way to work. The problem was that they were judging themselves against Scrum's rules and failing every sprint, while having none of Kanban's controls to stop the overload. They had the worst of both.
Every process comes with a brake
This is the part that makes the label matter. Each delivery process has one mechanism whose job is to stop a team taking on more than it can finish:
- Scrum uses the sprint commitment, set against measured velocity. New work only enters mid-sprint if the product owner renegotiates.
- Kanban uses work in progress limits. The board itself says no.
- SAFe uses increment planning across teams and a release train that owns dependencies.
- Stage-gated delivery, including PRINCE2, uses change control and tolerances.
Run Kanban under the Scrum name and you drop the sprint commitment because it keeps failing, but you never add work in progress limits because you do not think you are doing Kanban. You end up with no brake at all. I call that unmanaged flow, and it is the most common thing I find in teams that are struggling.
A short field guide
| Process | How work moves | What stops overcommitment | Fits best when |
|---|---|---|---|
| Scrum | Fixed sprints with a goal | Sprint commitment against velocity | One stable team, product work, a product owner who can say no |
| Kanban | Continuous flow | Work in progress limits | Support, maintenance, operational work, lots of interruptions |
| Scrumban | Sprint cadence for planning and review, flow within | Both, lighter versions of each | Product teams with a heavy interrupt load |
| SAFe | Increments planned across several teams | Cross-team increment planning | Several teams on one product with real dependencies |
| Stage-gated (waterfall, PRINCE2) | Signed-off phases | Change control and tolerances | Requirements that genuinely do not move, contractual or regulated work |
A few notes on that table.
Scrumban is underrated. A lot of teams that call themselves Scrum actually want Scrumban. They value the review rhythm but their work arrives unpredictably. Naming it honestly often fixes more than any amount of Scrum coaching.
SAFe is honest about something Scrum is not. It reintroduces architects, release roles and portfolio management, because most enterprises need them. The cost is ceremony, and it can add weight faster than it adds value.
PRINCE2 is governance, not delivery. It is frequently wrapped around agile teams. From the team's point of view it behaves like stage-gating, because the board and the tolerances sit above them.
Waterfall is rarer than people claim, and more common than agile people admit. If your requirements genuinely do not change, sequential phases are a legitimate choice. If they do change, you are paying for change control on every one of them.
Diagnose before you choose
Before choosing a process, find out which one you are already running. Five questions get most of the way there:
- Do you plan in fixed time boxes and hold to them? If the box never holds, you are not really iterating.
- Can new work enter mid-cycle without anything leaving? If yes, you have no brake.
- Do you plan against measured capacity? Velocity or throughput that nobody plans against is decoration.
- Who can say no to a new ticket? If the honest answer is nobody, that is your finding.
- Who sets scope and funding, and how often? This tells you what the business around the team is running, which may be different from what the team runs.
That last question matters more than most teams expect. A team can run textbook sprints while the business around it runs annual budgets, fixed launch dates and signed-off scope. The team is agile in the middle of a waterfall. That is a hybrid, whether anyone chose it or not, and it is worth being honest about.
Rename first, then improve
The most useful change is often the least glamorous one. Call the process what it is. If you are running Kanban, say so and add work in progress limits. If you are running Scrumban, name it and let your retrospectives measure you against the right thing.
It does not feel like progress. It is the change that lets you measure yourself fairly, and only once the current process is honest is it worth choosing a different one.
Find out which one you are running
I have put these questions and a few more into a short diagnostic. Twelve questions, about five minutes. It scores your answers against Scrum, Kanban, Scrumban, SAFe, stage-gated delivery and unmanaged flow, compares the result with what you call your process, and tells you which control you are missing.
Take the Delivery Process Diagnostic.
If the result surprises you and you would like to talk it through, I am happy to compare notes.
