I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt.
My conclusion is, not very surprisingly, that it depends on the situation.
In this entry I take the Kanban hat on. Click here if you like to read the one where I love Scrum.
I concentrate on some area where Scrum and Kanban differs:
Iterations – In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do.
Commitment – In Scrum team commits to what they will do during a sprint
Estimations – In Scrum you must estimate. In Kanban it’s optional.
Crossfunctional teams – That’s one of the pillars of Scrum. For Kanban it’s optional.
Prioritized backlog, self-organizing team, transparency, inspect & adapt, pull scheduling and good communication/collaboration are things they have in common.
Kanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It’s just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of quality, just-in-time (quickly from concept to cash), Kaizen (continuous improvement) and minimizing waste. No meetings if it’s not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas were Scrum practices can be waste.
Estimations – If product owner knows what needs to be done and the only interest is to have it done a soon as possible, why spend time on estimating? In Scrum, estimations are needed for team to know how much to commit, to calculate velocity and for product owner to decide on prioritization. If none of this is needed, it’s waste and we shouldn’t do it. If you like to measure velocity you can instead count number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, cycle time. That is, the time it takes for the customer to get what he or she ordered.
Last day in Sprint. If team is done with a story and there is not enough time left in the sprint to complete the next, it’s likely no one works hard the remaining time and that’s waste.
In Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth anything since the ones disturbing them doesn’t care about commitment. A commitment you can’t control gives either frustration and stress or demotivation.
In Scrum a team is crossfunctional and sits together with the people working with the same project and not with the ones with the same knowledge. Let’s say you work with sound effects for a computer game. Then it’s not much help to have a java-programmer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practises.
Please, help me Kanban-fans, what have I been missing?
Best regards,
Tomas
Really good idea with these very informative blog entries!
I agree. love coming here for insight and news from the Agile experts ; ) There are also some great resources (with a lot of attachment to blog.crisp.se as well) here. We are just now starting to transition from Scrum to Kanban with my team.. exciting times 😉
Nice angles!
Thanks for the article.
Lead time vs cycle time:
“…why not look at something the customers are interested in, cycle time. That is, the time it takes for the customer to get what he or she ordered.”
Shouldn’t that be lead time, which is the average time to complete an item. Cycle time is the rate (in time/unit) items leave the kanban “production line”.
See Lean Glossary
One other major difference I noticed is that in a daily scrum, people focus on what they do – so they are in some kind of “I am in the center of the universe”-mode. In a daily stand-up, the discussion is about why does an item not flow i.e. the “work is in the center of attention” independent what an individual has been doing or is going to do.
And that makes IMO a big difference and favors Kanban.