A lot of companies run Scrum simply because it was the default. A new head of engineering brought it in, or an investor asked whether the teams were “agile”, or everyone else seemed to be doing it.
That’s a weak reason to commit a whole organisation to a set of roles, events and rituals. Scrum is a good answer to one specific problem. If you don’t have that problem, you get the overhead and very little in return.
What Scrum is actually for
Scrum works best when a team is building a product under uncertainty, priorities shift often, and nobody gets to see progress until something ships. A fixed sprint protects the team’s focus for a couple of weeks. Planning forces someone to choose. The review puts working software in front of the people who asked for it.
If that describes your situation, Scrum helps. Many product teams in their first years of growth fit this pattern well.
When it gets in the way
We regularly see teams where half of every sprint goes to unplanned work: production issues, partner requests, regulatory changes with short deadlines. The sprint plan is fiction by day three, everyone knows it, and planning turns into a ritual nobody believes.
Those teams usually do better with plain Kanban. Work comes in, gets prioritised, flows across a board, and a limit on work in progress makes sure things finish. No pretending that next week is predictable when it isn’t.
Other cases where full Scrum adds little:
- a team of one or two people
- work that’s mostly known in advance, like a platform migration or implementing a published technical standard
- an organisation where nobody can act as product owner and actually say no
Many teams end up somewhere in between, with Kanban flow plus a regular planning and review rhythm. Scrumban is a perfectly respectable answer.
What we keep and what we cut
Our own default is light. We keep the skeleton: two-week sprints and a short daily standup. That gives the team a rhythm and gives the business a predictable point to check progress and change direction.
Most of the rest is negotiable. Long refinement sessions with the whole team, ceremonial reviews nobody outside the team attends, retrospectives that produce the same three complaints every time. If a meeting doesn’t produce a decision or unblock work, we cut it and give the time back to the people building the product.
That surprises some leaders, who expect an advisory firm to add process. In practice, a team with fewer meetings and clear priorities ships more than a team running every ceremony by the book.
Questions to ask before committing
If you’re deciding whether to introduce Scrum, or whether to keep it, these are the questions we’d put to the leadership team:
- Can priorities realistically hold steady for two weeks?
- Is there one person who owns the backlog and has the authority to say no?
- How much of the team’s time goes to unplanned work today?
- What problem are we trying to fix, in one sentence?
If the honest answers are mostly yes and the problem is focus or visibility, Scrum is a good fit. If a big share of work is unplanned, or ownership of priorities is unclear, start with a board, a work-in-progress limit and one person who decides. You can add structure later, once you can see where it’s missing.
Your customers don’t care whether the team uses story points, and neither does your P&L. Pick the lightest process that gets the right things shipped, and change it when the business changes.
