Kanban – Let’s get started
Kanban (refers to visual board or billboard in Japanese) is a lean scheduling tool that works on JIT (Just in Time) manufacturing concept. The JIT is a model in which products are built to meet pressing requirements over building it in excess. This helps to improve productivity, reduce waste by limiting work in progress items, support continuous delivery and maximizing customer value.
Kanban board is a visualization tool as shown above. The number of stages could of any number depends on your need. For instance, in my previous project, we were using
- To Do – When the item is groomed and ready to be picked
- In Progress – The item is picked and being worked on.
- QA – The development is completed. It is ready for integration testing.
- Done – Delivered to the customer.
The stages and conditions as I described earlier are subject to individual need. The Kanban process is highly Adaptive. It does not prescribe any roles. Let’s look at some of the processes or tools in specific order (rigid to adaptive)
Waterfall – More rigid
Kanban – More Adaptive
The work in progress plays a critical role. This ensures there is nothing at any stage over produced which result in reducing wastage. There is not a secret formula to set a WIP limit. All you have to look at is how many members you have in time and how many items they can work for you to have expected utilization. When you start, it is perfectly alright to have wrong WIP limit. You can always change it as you move on.
Just to make it more clear, this is how I set up WIP limits for my previous project example where my team size was 11. All of them used to play the role of Developer as well as QA.
To Do – 5 – Wanted to restrict to a number of groom items as we had customer dependency to unblock individual item (Access and other dependencies). Once we get the access to customer environment, we cannot wait for a long time to get started on that.
In Progress – 6 – I always wanted individuals to focus on QA as well as unblocking backlog item to continue the flow hence I limit this to 6.
QA – 2 – Sound interesting. Isn’t it? Well, anything which is dev-done (typically takes 3-4 weeks of development), the QA work was limited to 2 days. Anything which reaches to QA, should be quickly completed and delivered to the customer so that I can recognize my revenue. The advance of two is, an individual must complete it in order to move dev complete items to QA. If the WIP limit is full, even an item is dev complete, it used to remain there.
In addition to above, I kept WIP limited to leverage pair programming benefit as well. I wanted on complicated items folks to pair program. The above number, I reached over a period of time. The initial WIP limit turned our to be wrong which was expected.
The Agile Methods explain some of the core frameworks or agile process tools similarities and differences.
Please refer the following blog for step by step process to implement Kanban in your project.