When is Scrum the wrong choice for a team, and what would you use instead?
Answer
Short answer
Scrum's Sprint assumes work that can be planned a fortnight ahead, held stable for that fortnight, and shaped into a goal worth committing to.Where one of those fails - interrupt-driven support, single-item research, hard external gates - a flow-based approach fits better.
This is a Scrum framework judgement question. The Scrum framework helps when the team can work toward a Sprint Goal, inspect a potentially releasable Increment, and adapt based on feedback. The Scrum framework is a poor fit when work is purely interrupt-driven, when the team cannot own the outcome, or when the organisation wants predictability without empirical adaptation. A strong answer respects the Scrum framework enough to say when Kanban, incident flow, or a different operating model is more honest. The Scrum framework is valuable precisely because it has boundaries.
Was this answer helpful?
Likely follow-ups
- Your team is half feature work and half production support. Do you split the team, the process, or neither?
- A team asks to drop Sprints because planning is painful. How do you tell whether they are right?
- What would you lose by moving to Kanban that you would have to replace deliberately?
- How would you run a team whose work is gated by a regulator's fixed submission dates?
Related questions
- The team has missed its Sprint Goal four sprints in a row. What do you do as Scrum Master?mediumAlso on sprint-goal6 min
- Your daily scrum has turned into fifteen people reporting status to you. How do you fix it?mediumAlso on sprint-goal4 min
- Three teams building one product are on different cadences and each waits on the others. Would you align their sprints?hardAlso on flow7 min
- It is day seven of a ten-day Sprint and the team clearly will not finish everything. What do you do?mediumAlso on sprint-goal4 min