Kanban vs. Scrum Is Usually the Wrong Question
The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration. Software product development with a defined roadmap fits this model reasonably well. The sprint boundary creates a forcing function for prioritization and a natural rhythm for retrospection.
Kanban works well when work arrives unpredictably, priorities shift faster than a sprint boundary can accommodate, or the team’s primary obligation is responding to incoming requests rather than building toward a planned outcome. Support teams, platform teams, and teams maintaining multiple existing products often fit this model better than a scrum cadence allows.
The mistake most teams make is adopting one framework and then adding elements of the other as exceptions: a kanban team that holds something like sprint planning every two weeks, or a scrum team that maintains a permanent fast lane for urgent requests outside the sprint. These hybrid approaches are not failures of discipline — they are signals that the underlying work has characteristics the chosen framework was not designed for. The pragmatic response is to formalize the hybrid rather than defend the purity of either model.
What both frameworks share is more important than what separates them. Both require explicit work-in-progress limits, either as sprint capacity or as column limits. Both require regular inspection of flow and outcomes. Both improve only if the team is honest about what the data is showing. The ceremonies and artifacts differ. The underlying discipline is the same.