Comments on: From Scrum to Kanban

By: siddharta

siddharta — Tue, 02 Feb 2010 16:47:53 +0000

Mario, then why bother with the Sprint plan meeting? Let the team do whatever they can in the sprint and what is done in the end gets delivered.

By: Mario

Mario — Wed, 09 Sep 2009 21:34:47 +0000

I would be a cautious about your statements on Scrum. When the blog says “Now, assume that you have committed for 20 points, but you are only going to make it to 15 points. What then? In Scrum, you would work harder (extra nights or weekend maybe) in order to make the commitment”, this is not the case. Most Scrum teams I work with are not focused on the “number” of points but instead ensuring that the work gets done correctly. If it happens that people are working late, it is a sign of a working culture that makes people work long hours, but certainly not advocated by Scrum. In fact, Scrum advocates a regular work work. Also, then it says, “The problem is that Scrum ignores the reality of variation in velocity and attempts to force teams to a constant velocity.” This again is not true. You cannot assume that the team is focused on delivering a specific set of story points when in reality, the team hardly cares about this and instead cares about delivering quality product. How many story points that actually get finished is a number that is used as a point of reference to understand velocity but certainly not to drive it. There are advantages to Kanban, but be cautious in unecessarily placing assumptions to Scrum that are not true.

By: siddharta

siddharta — Sun, 16 Aug 2009 03:12:38 +0000

@Prasad :

Yes, Kanban is less prescriptive. While it does not say you should use unit testing or any engineering practices, that is possibly a good thing to do anyway. Kanban mainly talks about the end to end flow and how to optimize it.

Again agreed that its hard to figure out what WIP limits you should use. As a starting point I’d limit it to the number of people, then identify where there are piling up of work and where its smooth and adjust it to match capacity.

About roles, Kanban doesn’t specify any, so it can fit in with whatever you are currently doing.

By: siddharta

siddharta — Sun, 16 Aug 2009 03:06:53 +0000

@Neal :

Agreed, thats why kanban gets rid of the concept of sprint.. since anyway everything is decoupled from it.

About working less hard, well I’m not sure about that. You still want to minimize lead time, so everyone will be working towards that. You can still have standups if items are stalled. Plus, if something is going slow it blocks the pipeline and attention is quickly drawn towards getting it done.

As for your third question, you need to set the work in progress limit appropriately. Not everyone has to work on the same item, its okay if each works on a different one. What you want to avoid is to start working on one, then stop and start another one. Also, practices like pair programming will allow you to focus two people on one task and get it done quicker with better quality.

By: Prasad

Prasad — Tue, 11 Aug 2009 12:26:03 +0000

Hi Siddhart, Thank you for an excellent post. Currently I am doing a PoC using Kanban. I am in a midway
challenges
a) Kanban is less prescrptive- team need to be highly matured and experineced to adopt right engineering methods
b)SLA’s and cycle time – WIP limit very difficult to put a number
c) confusion with roles & responsiblities

By: neal

neal — Wed, 05 Aug 2009 08:32:18 +0000

It’s interesting article, but 3 questions still,

a. if we go without commitment sprint and sprint planning, why do we still keep sprint? The concept of sprint lost its sense after this change.

b. if there’s no commitment sprint, team tends to work less hard and they don’t have clear target for their tasks at hand. How does Kanban handle this?

c. in a scrum team of 8 people, usually it’s not likely that whole team work on one item all together and move to next when it’s done. More people working on one item doesn’t make it faster. The result is people start with several items at the same time and that’s just natural I think. How do we handle this in Kanban to limit the work in progress?

By: siddharta

siddharta — Sat, 01 Aug 2009 03:46:00 +0000

Hi Rainwebs,

Good question. The key to getting this to work is to limit work in progress.

If no one has started any work on an item, and if I take that out and put something else of equal size, then it should not make a difference to the team?

The problem arises only when someone has already started working on the item.

When you limit work in progress, then changing the sprint backlog is no longer a disturbance.

By: rainwebs

rainwebs — Fri, 31 Jul 2009 00:36:54 +0000

If you skip the Spring Backlog how do you manage task dependencies then? Why do you have problems to persuade the Product Owner for a period of 4 weeks to keep what was planned? For me this is too much disturbance for the team.

By: siddharta

siddharta — Thu, 30 Jul 2009 12:36:09 +0000

Eben, agreed. That is pretty much what we did too. Basically stop looking at it as a commitment, but something that changes according to what happens.

But that is not how the official scrum states things.

There is a difference between “committing” to the sprint plan, and saying we’ll work at a natural pace and see what gets done. Scrum asks for the former, and this is the way people are trained.

Of course, if there are major issues, you can ask for sprint termination. And sometimes stuff is left out even after all efforts. But otherwise the team is expected to meet the commitment.

If you just do whatever you are able to do, sometimes less, sometimes more, then there is no meaning to creating a sprint plan, is it not? Wouldn’t you be better off just taking a prioritized backlog and doing stuff from the top and whatever gets done is what gets released?

That is what we ultimately started doing. We just got rid of a sprint plan, and took stuff one by one off the top of the backlog. Whatever got done, we released. If we were going slower, we would end up taking fewer items from the backlog. If we were going faster, we took more.

By: Eben Halford

Eben Halford — Thu, 30 Jul 2009 10:59:57 +0000

Interesting article – I have some ‘common cause variation’ with your stated version of Scrum however.

“In Scrum, you would work harder (extra nights or weekend maybe) in order to make the commitment”

Umm not in my experience – the team and/or scrum master would simply talk to the product owner and negotiate the depth of acceptance criteria on the least valuable item you have in the sprint – basically reducing it’s point value. You’d do this by watching the burndown which will guide you in knowing if you’ve over or under shot.

“Scrum says you should not take up new features mid-sprint”

I don’t agree with this either – if you finish all your stories then you take the next highest priority item on the backlog after discussion between the team and the product owner.

Cheers,
Eben