Scrum and Kanban – a developer’s perspective
By Nathan Donaldson
26 January 2010
We’ve been using Kanban for a few weeks now on some projects, taking over from Scrum where appropriate. We’ve used the Kanban process for projects in ongoing maintenance and for those that seem more like a list of tasks to be performed (Drupal CMS integration).
- Forces workflow.
- Easier to see each task’s status – it has a place in the workflow instead of being not started / working / complete as with scrum.
- Less satisfaction – you don’t see the burndown or how much work you’ve personally completed.
- Kanban is more about a flow of tasks, and one premise is that the number of tasks in each stage of the workflow is restricted. This can be difficult when there are tasks that must be dealt with by different team members – for example design tasks verses programming tasks. A design task may take up a slot in the workflow for a long period of time.
- Kanban can’t express dependent tasks. This sometimes causes tasks to move back and forth along the workflow to free spots for the tasks they depend upon. Scrum has a less confusing way of showing what’s happening.
- Harder to see overall project status. This is a problem when working with Kanban for the whole project, but not for projects in maintenance mode.
Some of these cons are things that we need to work around by improving our own processes. Ideally all the tasks can be dealt with by all team members (but this is impracticable for expressing our design tasks). We also need to work towards each task being a self contained unit of work with no dependencies.
I think with Kanban we’re still finding our feet. The tools aren’t yet as mature and easy to use as the scrum tools we use. Our task descriptions and workflows are still evolving. It seems to me that the Kanban structure requires more ongoing maintenance from the project manager than scrum where the structure is set at the beginning of each sprint. As we’re still only experimenting with Kanban we haven’t found a good balance and tasks tend to pile in the completed stack for too long before being verified.
My overall feeling is that scrum is a more satisfying process to develop under – you get better and more immediate feedback. Kanban is helpful in preventing work being done when the scrum process isn’t in place – a situation that is very tempting when bugs start appearing.
Create a Kanban board and go Agile in an instant
Scrum and Kanban: Less is more
The Board 22: Scrum and Kanban
The Board 34: Scrum and Kanban part 2
The Kanban game
Manage project risk by limiting work in progress