Day 60, 2015. February – the month of roses, chocolates, and love is sadly over. It was a little cold but it was still beautiful. I guess it was the warmth of love filling our hearts. Love really was in the air 🙂

Talking about love, I am sure you can see how much I love scrum, for all I have been talking about in my previous articles is just Scrum and better Scrum. I guess its time, I should shower some love and attention on some of other agile techniques as well – Kanban, XP, Lean, DSDM. Today, in this artice, lets touch upon a little bit on Kanban, and see how it differs from its close cousin ‘scrum’.

What is Kanban?

I believe I brisked through it a little while ago in one of my early articles – What? When? Where Who? Why? How? of AGILE. Let us now do a deep dive into the past, present and future of Kanban.

Dictionary meaning of Kanban (ref: dictionary.com) – a just-in-time method of inventory control, originally developed in Japanese automobile factories. Japanese, kamban literally, ‘signboard, shopkeeper’s in-business sign’, probably alluding to the shop or tavern keeper’s final call for orders beforetaking the sign down, hence ‘last-minute, just in time’ in the context of inventory control. Middle Chinese, equivalent to Chinese kàn ‘look’ + bǎn‘printing block’

History of Kanban 

Kanban as a Scheduling System in Manufacturing industry – In the late 1940s, Toyota was looking into ways to improve and maintain a high level of production without overloading the manufacturing system and they started studying Supermarkets with the intent of applying shelf-stocking techniques to the factory floor. The outcome of this study was KANBAN, developed by Taiichi Ohno. Kanban aligns production with the actual consumption by regulating the inventory levels. It uses the rate of demand to control the rate of production. In 1953, it was first successfully implemented in Toyota’s main plant machine shop. In order for Kanban to be effective Taiichi Ohno put in place six simple rules:

• Later process picks up the number of items indicated by the kanban at the earlier process.
• Earlier process produces items in the quantity and sequence indicated by the kanban.
• No items are made or transported without a kanban.
• Always attach a kanban to the goods.
• Defective products are not sent on to the subsequent process. The result is 100% defect-free goods.
• Reducing the number of kanban increases the sensitivity.

Kanban as a Software Development technique – Years later, David J. Anderson formulated Kanban as an approach to incremental, evolutionary process and systems change for organizations. It is pretty similar to how it is implemented in the manufacturing industry, laying emphasis on just-in-time delivery, while not overloading the team members. Just as in the manufacturing industry, Kanban in software development provides a visual process management system, that tells us what to develop, when to develop and how much to develop.

Present day application of Kanban in Software development

The key word in application of Kanban is WIP limit. By matching the amount of work-in-progress to the team’s capacity, Kanban gives teams more flexible planning options, faster output, clear focus, and transparency throughout the development cycle.

Flexibility in Planning – A kanban team will only focus on the work/tasks that are actively in-progress. Only once the team completes a work item, they pluck the next work item off the top of the backlog (ToDo column in the picture above). Just as in Scrum, the product owner is responsible for keeping the backlog prioritized, without disrupting the team’s current commitments.

Faster Output / Minimizing cycle time – Cycle time is the amount of time it takes for a work item to travel from the left most column (ToDo) to the right most column (DONE) in a kanban board. Which in other words is nothing but the time it takes for the work item to travel through the team’s workflow – from the moment work starts to the moment it ships. Cycle time in Kanban serves the same purpose as Velocity does in Scrum – it helps forecast the delivery of future work. And having a cross-functional team helps optimize the cycle time, just as it does in Scrum.

Clear Focus – High number of work items in flight leads to more context switching, which hinders their path to completion. WIP limit ensures clear focus on a limited number of work items, leading to a higher efficiency and less cycle time. WIP limits also help highlight the bottlenecks and backups in the team’s process, which can be anything from lack of focus, people or skills.

Transparency – Maintaining transparency is a core value in Kanban. But the question is how do we maintain transparency? One word answer – VISUALS.  When the team can see data, its easier to spot bottlenecks in the process (and remove them!). The visuals help the team continuously improve.

Future of Kanban

We all know about Continuous Integration (CI), one of the best practices to be implemented in any agile organization, the practice of building and validating code incrementally throughout the day, very essential for maintaining code quality. But did you know about Continuous Delivery (CD) – CI’s older, more sophisticated cousin. This is the practice of releasing work to customers frequently. Depending on the nature of application/software being developed, we can do hourly/daily/weekly releases to the customers.

Kanban and CD beautifully compliment each other as they focus on just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to its customers, the more competitive their product will be in the market. And Kanban teams focus on exactly that: optimizing the flow of work out to customers.

Are Scrum and Kanban competitors? 

The answer is a big NO! Both Kanban and scrum belong the same family – Agile, making themselves useful in different environments and at times even co-exist in the same organization. Scrum and Kanban share some of the same concepts and they are a little different too at the same time. As I don’t want you to get confused, let us draw some basic differences bewteen the two.

Oh but wait, scrum and kanban can get a little naughty too at times 😉 The result of such a naughtiness was an offspring, and guess what they named their offspring – SCRUMBAN! It is like combining the best of both worlds – take the fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from kanban.

However, for teams just starting out with agile, I will strongly recommend choosing one technique or the other and running with it for a while. You can always get fancy later on.

Happy Reading! 🙂

– Nirbhay Gandhi