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 bti360.com 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 agilejournal.com 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.

Summary

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

Comments (2) -

Paul Harrington
Paul Harrington
11/26/2010 3:19:49 PM #

Good post although I'd like to add that you can move yourself more slowly towards Kanban.

We do ScrumBan in our development shop where we use a mixture of the 2 concepts. We still plan and execute stories within a 2 week iteration but we set WIP (work in progress) limits on our columns which encourages a "whole team approach".

If the Dev column has more than 2 stories in it, the devs in that team aren't allowed to start new work until they've paired with the other devs to clear the column.

If the QA column has 2 stories in it then the devs can't add any new stories until they've aided the QA in getting stories signed off.

If your QA is off sick then you have a contingency that allows another QA to help out or the devs to sign off in the test environment.

The net effect (coupled with some other Agile practices of course) is that you get more stories through your process quicker and to a higher quality but everybody in the team is responsible for the flow.

Sid
Sid
12/20/2011 3:50:37 PM #

I'm unclear as to why you believe Kanban would provide an additional benefit in the case of testing being sick for week three? You state that you'd finish tasks "BEFORE" other tasks were started, but you don't say how you'd do that (in a way exclusive to Kanban). If testing is MIA does Kanban suggest a path to done which scrum does not?

In scrum if the testing team all fell ill, developers would simply fill in for the testers. I'm not familiar enough with Kanban to understand how it would be any different there.

Also, the scrum board image you have is a bit misleading. You shouldn't have such a bottleneck at testing, things should be flowing from left to right. That sort of bottleneck would be easily identified by looking at the burndown chart. Then something would need to be done.

It's interesting because looking at it in this way it now appears that Kanban has more restrictions. You mention that there's a WIP violation, which I'm assuming means a Work In Progress violation, which is managed by the numbers at the bottom of the board (right? like I said, I'm not too familiar with Kanban). In scrum you'd look at the burndown and try to reconcile any inconsistencies with the reality of the situation. In effect making a judgement call instead of relying on a fixed "trigger".

IMHO, you don't really back up your assertion that "too much got started and not enough was actually finished." You cite "external influences" as being the source for delays. I'd suggest that it is the way that these influences are allowed to effect the sprint that might have been your problem. You should mitigate external influences as much as possible then adjust your team/efforts in response to the ones which cannot be avoided.

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

About Me

 

Web Developer. My most used framework is C# with MVC but use Webforms on occasion. Im an advocate of clean, maintainable code and am very passionate for what I do. Absolutely obsessed with Continuous Integration and how it should be used in every day development scenarios. Trying to move towards a system of Continuous Deployment
Follow Me on Twitter

Jetbrains Academy Member

 

MVB Blogger

 

Friends Of Redgate

Month List