Adventures of a wannabe geek!

Ranting within

Why Scrum Doesn’t Suit Me but Kanban Does

I read a post from Nathan Gloyn today on his summary of Scrum, Lean and Kanban training courses here has been on this week. This post made me really think about where I sit on agile methodologies and want to reflect on what works for me.

Basics of Scrum:

Iterative process that uses a product backlog to help prioritise work. Work usually happens in short sprints (2 –4 weeks), has a load of roles and has 3 artefacts (product backlog, sprint backlog and burndown chart). Scrum has a lot of rules to follow! (more on scrum)

Basics of Kanban:

Process that doesn’t use times iterations, once something is removed from the task board, it is replaced by the next highest priority item. It doesn’t have many rules except, its focus on reducing work in progress, strict prioritization and limiting demand after capacity. (more on kanban)

What does scrum not work for me?

Well as scrum is timed iterations and NOT have a work in progress then for me too much got started and not enough was actually finished.

In the team I worked in Scrum with, we had 4 developers working on a 2 week iteration that has so many little tasks. This meant that lots of little tasks were in a “doing” state and any external influences that delayed the project meant that at the end of the sprint then we hadn’t finished everything and then the sprint had to be extended

I found this image from that illustrates the point. suppose we are in a 3 week sprint and we got to this stage after 2 weeks. If the QA was off sick and couldn’t test for a week (i know this is against Scrum but it can happen) then there is a risk that nothing in this sprint would be finished at the end of the sprint

So with Kanban if the same thing were to happen then we would have to have a limit on the columns. Then we would actually finish tasks BEFORE other tasks were started and thus we could identify a bottle neck a lot earlier as there would be a halt to the board due to a WIP violation

I found this image on to illustrate what a typical Kanban board looks like.

As you can see there are lots of tasks in “Done” and tasks are spread across the board rather than all piled in 1 column.

This seems to work well with the environment I’m currently involved with. We work in a reactive development environment that can change daily so therefore planning sprints would not be conducive whereas taking a task by task system helps us a lot.


Kanban works for me because:

  • the business decides what is the most important priority on a day to day basis as it can change
  • our teams can work on multiple projects and need to be moving in and out of projects fast
  • timed iterations may not actually reflect release points
  • expedites can be added to the current work in progress without affecting the work currently in progress and without changing the dynamics of a sprint

These are just my thoughts considering I don’t work in an environment where Scrum can benefit us. I haven’t been in an environment where we can spend time planning a few weeks work – work has always been reactive for me.

Just my $0.02 Smile