Kanban is a great tool that has clear advantages, but as usual is not a silver bullet. It is not intended to replace the existing process as it will only facilitate and help you visualize the one already in place and help you to continuously improve.
Kanban has a relatively low entry cost, all you need to start is a board or a wall, a couple of sticky notes and a marker. Of course, technical tools are helpful but really not essential. There are also ways on applying some of the kanban ideas to other agile project methodologies like scrum. One of the ideas of Scrum-Ban is to make use of a Kanban board to facilitate daily standups.
The Three key aspects of Kanban are:
– Visualization
– Flow and pull
– Work in progress
Visualization
The board is the most significant and of course, the most visible part of a kanban powered system. Kanban in Japanese means a “sign board”, it gives you a visual representation of the work that is going on and awaiting execution. Each part of the system is represented by a column. Columns should represent whatever stages of production you have. In software development and software support services it generally is: To Do, Ready for development, Work In Progress, Implemented, Testing, Done. Board building is a team activity. It is very interesting to observe the board as the team engages in discussions on, for example what each of the columns represent and you can instantly understand the process that the team had adopted till now.
Swimlanes are also an important part of the visualization system and are used to illustrate some particular types of task or whatever the team needs to track.
Parking fields for blocked tasks or a special critical tasks area (with very limited capacity) are also used.
The structure of the board is certainly not set in stone and it will evolve as your team learns to cope with new types of work.
Flow and pull
Kanban is about ensuring that tasks flow steadily and continuously through the system. Each column is replenished in a pull fashion that basically means when a task is finished and moved to “Implemented” column; the same person pulls another task from “Ready for Development” column and places it in the “Work In Progress” column. When the “Ready for Development” column needs replenishing the tasks are pulled from the “To Do” column. The important rule in this respect is to start new work only after the old work has been finished and moved to another column so that you do not imbibe a false sense of progress on your board.
Ideally, the tasks should be assigned to a person as late as possible in the process. This, of course, assumes that every member of the team has the same expertise and knowledge but can also facilitate knowledge sharing inside the team, when members pull tasks which they have never done before and gain the needed expertise for your team to progress faster on future development cycles.
Work in Progress
The pulling nature of the Kanban system makes sure that we can have only a limited amount of work in progress in a certain state at given time. Setting the upper and lower limits for each column ensures that the team is not working over the capacity and can also be used to determine potential bottlenecks. Setting the limits for each column should be an ongoing process and can be fine tuned at any stage of your Kanban implementation.
The actual limits may depend on how you actually organize work within the team. For example, when you are doing pair programming, the numbers may be lower compared to a single developer working on all tasks.
So, whats the difference between Scrum, Kanban, and Scrumban anyway?
Hopefully you now have a good sense to what Kanban is in the software development world and how its different than Scrum and Scrumban!!!