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
