Tomas Björkholm

Tomas Björkholm

Scrum, Kanban, Agile and Lean

Why Scrum is better than Kanban

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 suprisingly, that  it depends on the situation.

In this entry I take the Scrum T-shirt on. Click here if you like to read the one where I love Kanban.

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.

By asking team for a commitment they will get a positive stress knowing that people from outside will see if they can do what they committed to. It also gives an extra energy at the end of the sprint when team have the goal within reachable distance. After the sprint, the team can feel relaxed and gather some new energy for the next sprint. It’s psychologically nice to not feel you are in the middle of a never ending stream of things to do. Instead Scrum concentrates on one sprint at a time and give possibility to focus only on those things, decided to take in to the sprint. By working in fixed length iteration you get a nice rhythm the whole company can feel and adapt to.

Estimating is not waste since valuable information is transferred from product owner while the team ask what is needed to know what they are estimating. The same thing with commitment. To be able to commit they need to know what they are committing to. They simply have more interest of getting information from product owner.

Even though you can predict when a project is done just by counting stories left it is more precise if each story is estimated as well. Prediction is important when more departments, like marketing, is dependent on your work. It gives a more serious feeling.

If there are some time at the end of a sprint that’s valuable even if no new features are developed. This is time developers can use to improve code quality or development environment. Both will give better efficiency in the long run.

Working together in a cross functional team is a psychological thing. You are able to go the whole way from concept to released product together as a team without dependences. You are not just a cog in the machinery. It’s also fun and helps you grow as a person. By helping each other, knowledge is spread which gives less person dependency. It also helps prioritizations since features can be built without considering which knowledge is available. To coordinate between people with the same skills but sitting in different teams you can have virtual teams meeting as often as needed.

Please, help me Scrum-fans, what have I been missing?

Best regards,
Tomas

Why Kanban is better than Scrum

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