In classic Microsoft Press fashion, Agile Project management focuses on execution and pragmatism. To that end, I’ll structure this recap a bit differently.
Overall, where Scrum feels like a structured approach with an eye on speed, Kanban feels like a flowing river. There’s no time-boxing. Instead, Kanban focuses on creating a clean and narrow channel for your work to flow though.
Let’s take a look at the Kanban process.
The core idea of Kanban is similar to what Andy Groove talks about. Find your limiting step and optimize the rest of the process around it.
Here are the basics steps, simplified for brevity:
A simple Kanban board in VSTS
After you set up the process, you need to fill it up with work. A frequent way to do this is to define an MVP (Minimum Viable Product). How do you know what fit’s in the scope on an MVP tho’?
All task are sorted into four priorities:
Having work item buckets like this should make the backlog ordering much easier and enable you to react when the scope needs to change.
If you're not familiar with the essential traits of Scrum, it might be worth skimming my post about Scrum before continuing.
In some ways, Kanban shares a lot of traits with Scrum, but they have significant differences as well.
Since Kanban doesn’t have time-boxing, effort estimation might not be needed at all in a lot of cases. Instead of the burn-down chart in Scrum, Kanban works with the Cumulative flow diagram.
Cumulative Flow Chart in VSTS
There are a few things going you can see from the chart:
Notice that the unit of the Y axis is Work Items Count. If this was Scrum, it’d say Story Points. But Kanban doesn’t work with Story Points.
Instead, Kanban assumes all tasks are roughly equal in size. This means that in practice, 1 task = 1 story point. From there, you can easily deploy estimation methods like wideband Delphi in case you need to. The only difference is that you go from “How many story points will this user story cost” to “How many tasks will this feature result in?”.
In Scrum, you can choose whether you assign team members to specific user stories or tasks as part of the sprint planning meeting or if assignment happens organically during the spring.
In Kanban, late binding seems more mandatory. When a team member finishes a task, they should ideally take the top one from the backlog.
It’s going to be key in Kanban to make sure people still work on stuff that excites them instead of working on an item simply because it was on top of the queue.
In Kanban, there are no sprints and in extension, no sprint retrospectives that generate kaizens. Instead, Kanban relies on WIP limits to expose friction and create motivation to fix problems. When work starts piling up in a specific step, it’s time to start asking questions.
The assumption of daily standups is an Achilles' heel of both Srum and Kanban from a remote team’s perspective.
A major advantages that remote teams have is that members can do deep work for days at a time without any distractions. At least for us at Doist, this makes daily meetings a no-go.
We will need to experiment with this at Doist Windows, but initially it looks like Scrum will be more welcoming to dropping the meeting requirement. Time-boxing creates strong commitments, sohaving a single meeting per sprint to do planning as well as retrospective could be enough. For Kanban, the daily standups feel a more key as it’s the main vehicle to discuss kaizens and re-prioritize work when needed.
Eric had a few interesting remarks that are not strictly related to Kanban, but still peaked my interest :-)