Impressions of Lean and Kanban 2010 Europe
This post is short summary as well as a collection of ideas and impressions of the Lean and Kanban gathering in Antwerp organized by Agile Minds. According to David Anderson (one of the speakers) it has been the biggest conference on this topic so far: agilility is spreading in software development ( let it be Scrum, Kanban or any other agile methodology) and it is also growing on enterprise level.
Scrum and Kanban
There a some situations in which Scrum is not really applicable to manage a project because you might not be able to even plan the backlog items for one sprint. A good example is maintenance of a software product, where new bug reports come in at every time and need to be addressed as soon as possible. In this scenario scrum does not scale very well, even if you select the time for a sprint to be very short. This is where Kanban can help.
Kanban and Scrum differences:
The key concept of the two methods is to create a structure to deal with changes as well as limiting the workload which is in progress. Scrum does so by introducing sprints ( iterations which are planned and executed). The plan for a sprint is fixed (negotiated by the product owner and team) and should normally not be changed. If the sprint goal is not needed any more, it is possible to cancel a sprint. This means Scrum limits the workload of the team by ad-hoc planning of only one sprint in advance and by using the sprint time limit. The process is inspected after each iteration and adapted.
Kanban on the other hand focuses on visualizing processes and it limits workload by explicitly setting limits on each step of the process. There are no iterations, but value stream instead. The idea is to maximize the throughput of the process and eliminate waste (everything which can lead to bottlenecks and impediments). Kanban also implements the so called pull principle. This means the work item needs to be pulled from one process step to the next one and not pushed. It ensures that people only take an item when they are ready and thus are not overloaded with work.
Both methods emphasize that the goal is to deliver as much value as possible to the customer to achieve the highest customer satisfaction. They rely on a prioritized backlog of items which are then broken down into user stories.
Definition of done and definition of ready
Scrum uses the Definition of Done to create an agreement on when a work item / piece of software is finished and ready to be delivered. The Definition of Ready is an instrument for the team to define what they need to start working on an item.
Kanban can also uses those definitions. Kanban defines when something is ready or done on the process steps which is more fine-grained than the over all definition of done.
The Scrum Board
The Kanban Board
- Kanban board can also be used for Scrum. It helps to achieve a higher visibility.
- Use input and output queues to implement the pull principle
- Color-Code different types of items on your board (user stories should have a different color than bugs to be solved or change requests and improvements). You can also introduce rates, let's say 60% new user stories and 40% bug fixes.
- Additional work load limits could also introduced in Scrum. It could enforce pairing and helps keeping the focus on finishing things rather than starting new user stories. This is especially helpful if incomplete user stories are taken very often from one sprint to the next (because they are still of the highest priority). Stop starting, start finishing!
- Introduce classes of service if needed. Classes of service define a different mode of operation, e.g. one class of service could be normal, another one urgent. This can help to get specific items faster through the process steps, even though it will slow down the overall process.
- Avatars can be used to visualize who is working on which item. It can also indicate pair programming on directly on the Scrum / Kanban board
- Retrospectives should also be done in Kanban to identify problems
- Planning Poker
Which flavor to use?
Well this is depending on you, your project and your company culture. My personal résumé is that there are a lot of agile practices which can be used on all different agile processes. It seems to me that starting Kanban can be easier to do because it requires less changes to be done. Also Kanban or Lean Management seems to be easier to integrate on enterprise level than for example Scrum of scrums which makes a lot of synchronization necessary between different teams.