There’s an interesting article by Liz Keogh, comparing Scrum and Kanban.
Interestingly, she thinks they’re more similar than different, but for me, the differences are the most interesting bit.
The killer quote is this:
Kanban visualises what’s happening; Scrum visualises an ideal.
This is one of the biggest differences for me. The extend to which Kanban visualises reality is extreme enough that the board might not even have linear flow. Whatever the process policies are – whether helpful or otherwise – Kanban focuses on making them explicit, so that they can be addressed and improved. If the team happen to work with five different phases, this is reflected. If the team write technical stories, they go on the board.
In contrast, Scrum teams tend to set up a visualisation of an ideal process, helping teams to adopt that process. Done prescriptively, Scrum provides a “big bang” starting point. Because it consists of step-by-step practices, it’s easier for beginners to adopt. That could be Scrum’s blessing – but it’s also its curse.
‘Visualising reality’ is what I find most useful and absolutely essential with delivering a project. A methodology is fine, but the day to day realities may prevent the ideal implementation from being possible. And when you have Scrum practitioners telling you that you’re ‘doing it wrong’, I tend to dismiss Scrum (done 100% perfectly) as being impractical. What’s more important, the theory or the reality?
Liz suggests that Kanban provides more useful metrics. In my experience, Kanban highlights where blockers and constraints in delivery are (testing, deployment, bug fixes etc), where Scrum’s velocity system can be rigged to return a positive result, even when the situation is actually dire. This can easily be done by inflating your developer estimates to cover for other issues.
My biggest complaint with Scrum would be the reporting overhead. Trying to figure out what story card to assign your time against, and then to justify your actual recorded time at the end of the sprint was demoralising and does nothing to assist in actually delivering the product.
That’s why I prefer Kanban. It simply says what is happening, allowing people to take steps to remediate it.