When Scrum Doesn't Fit: Kanban for Ops Teams

I'm a certified Scrum Master and Product Owner. I believe in Scrum. And I'm telling you it doesn't work for every team.

Our platform operations team was running two-week sprints and hating every minute. Half their work was unplanned — incident response, infrastructure requests, security patches. Sprint planning was fiction. Retros became complaint sessions about interrupt-driven work blowing up commitments.

So I did the uncomfortable thing: I killed Scrum for that team and moved them to Kanban.

Why Scrum failed for ops

Unplanned work destroys sprint commitments. When 40-60% of your work is reactive, a two-week plan is a two-week lie. The team felt like failures every sprint because they kept missing commitments that were unrealistic from the start.

Sprint boundaries are artificial for continuous work. Deploying infrastructure changes doesn't map to two-week cycles. Some changes take 3 days, some take 3 weeks. Forcing them into sprint-sized chunks created unnecessary handoffs.

What Kanban gave us

Flow visibility. WIP limits immediately showed us that code review was our bottleneck, not development. Three engineers were always waiting on reviews.

Honest metrics. We started tracking lead time and throughput instead of velocity. Leadership could actually see how long requests took from intake to completion.

Reduced context switching. WIP limits of 2 per engineer meant they finished things before starting new things. Revolutionary concept, apparently.

No more planning theater. Instead of pretending we knew what the next two weeks would look like, we maintained a prioritized backlog and pulled work as capacity freed up.

The nuance

Our feature teams still run Scrum effectively. The difference is predictability of incoming work. Scrum works when you can plan. Kanban works when you can't. The framework should serve the team, not the other way around.

Being agile means adapting — even your choice of agile framework.