I considered starting this post off with, “Some dude got paid to study people standing in line and now we have Kanban,” but I was told it wasn’t very professional. Also, I don’t actually know if he got paid, I just assume he was. Probably more importantly, that isn’t actually how Kanban started.
So… some dude from Japan came to the United States and watched people grocery shop and now we have Kanban.
(*I also considered starting this post off with, “It was the best of Agile, it was the worst of Agile,” but I think Kanban is a pretty good idea and that play on the famous quote just wouldn’t work.)
The Origins of Lean kanban
That grocery shopping dude’s name was Taiichi Ohno. In the 1940’s and 1950’s, he was a production engineer at Toyota. He was tasked with making Toyota as efficient as Detroit automakers (Toyota). He came to the United States during that time and noticed something different about how Americans shopped for groceries compared to how the Japanese did it at the time. Customers only took the items they needed, and stores only provided a limited supply on the shelves (IBQMI).
Taiichi Ohno began to view processes as a store (IBQMI). The preceding process being the supplier for the process next in line. If one process was not ready to consume the efforts of the prior process, then the prior process must stop producing. Remember what I said about having an idea in a prior post? Probably not, so here is the link: AUTONOMATION AND THE HELPER ROBOTS.
“Something amazing begins to happen when you have an idea, define that idea, and give it a name. You begin to think about it as an entity and it can help change your perspective.” – AUTONOMATION AND THE HELPER ROBOTS
The rate of demand controls the rate of production (IBQMI). This creates the pull system effect. You pull the items through the process flow. If the last process needs input from the prior process, it pulls in that input creating a chain reaction down the line that keeps processes producing.
This is different than a system that tries to push the outputs through the process flow. Those processes will keep producing as long as they have the required inputs to the process. Imagine a grocery store loading up all their inventory on the shelves and producers of food items sending their goods whether the store needs them or not.
This idea of Taiichi Ohno’s became known as Just In Time (JIT) manufacturing. It formed part of the Toyota Production System and later became part of Lean Manufacturing. Lean kanban became part of JIT manufacturing as a way to organize the workflow in a visual way.
Agile Kanban and Lean Kanban
Taiichi Ohno’s idea for Just In Time (JIT) manufacturing, described in the above section, pretty much describes Kanban in Agile. Kanban in Agile is more or less JIT manufacturing. Although In Agile Kanban, just in time manufacturing is known as just in time delivery and it is actually a part of Agile Kanban.
Confused? Let me phrase it another way.
Agile Kanban is a method for managing knowledge work that includes JIT delivery practices such as limiting Work In Progress (WIP) and using a visual system, such as a kanban board, to display the current state of the work. It also has some accompanying practices to help enhance or improve the flow of work through the system.
Lean kanban is just the sign cards.
|Agile Kanban||Lean kanban|
|Derived From Lean||Part of Lean|
|Defines Just In Time Delivery||Complements or part of Just In Time Manufacturing|
|Named after Lean kanban, consists of JIT delivery, kanban boards, process flow controls||Consists of kanban (visual signaling), or a kanban system using signal cards|
|Method for managing knowledge work||System for visualizing the status of work|
|Has a capital “K”||Has a lowercase “k”|
|Uses Work In Progress (WIP) to provide structure||May have cards that say WIP on them|
Kanban in Lean Manufacturing consists of the signboards used to define which items are a Work In Progress (WIP) and where they are at in the process flow. Lean kanban is more like a control for JIT and keeping that control very visible.
To make things a little more confusing, you can have a kanban board in Scrum, but not actually be doing Kanban. The kanban board is just the visual signboard often used in Scrum implementations.
What is Agile Kanban?
First, let us start with what it is not
- It is not project management, nor does it have to be used exclusively within projects
- It is not a method for developing software, nor does it need to be used only within software development
- It is not just post-its on a board you shove through from beginning to end, that is a kanban board.
Agile Kanban is about continuously delivering. Where other Agile approaches deliver incrementally, often with set iterations, Kanban is more of a continuous workflow. Work items need to be pulled through the processes. If there is no capacity, items are not pulled forward in the process flow and new items are not added to the queue.
Kanban defines no roles. Kanban describes a way to organize work to provide a continuous delivery stream of that work. You would not change out the existing way you do work, but implement Kanban within that existing structure.
For example, If you have an organization that needs to bill outside organizations for work performed, like a doctor’s office that needs to bill insurance companies. You have 3 medical billers. You already have a process in place for how they perform those duties, you just want to help streamline and structure the activities and ensure no overlap.
Within a kanban board, I would create a backlog of work items and that work would be assigned to the medical billers using our existing process. I would lay out different columns based on the aspects of the billing, maybe “Services Rendered”, “Preparation”, “Sent/Pending Payment”, “Payment Received”, “Payment Disputed”, “Revision Sent”, and “Bill Closed”. I am not a medical biller, I am mostly just guessing at what it might look like based on how my wife describes it (She works in medical and foster care billing).
After the process steps are created, I would work to set a Work In Progress (WIP) limit. Maybe I will write a post in the future on setting WIP limits, but I won’t go into it here.
The goals of the WIP limit are:
- Reduce task switching
- Make the status of work visible to anyone that might have a need for the information
- Improve any handoff of items
- Reduce work overlap
- Eliminate excessive meetings about the work
- Streamline the overall process
- Provide metrics and a structure of tracking the work getting done – which can provide the means to improve the overall flow of the work being performed
This is a general description of how you might go about taking your existing process and implementing Kanban within it. Not much changes in regards to how the work is getting done, but the flow of work and how you think about that work changes. You lay it out in a series of defined steps, and it may be that some items move backward in the queue, that is sometimes the nature of work.
*Just a side note, the kanban board above does not take into consideration the level of work effort for each item.
So what does this have to do with some dude studying people standing in lines? I am going to tell you right now.
Here it is:
L = λ W
Little’s Law helped to prove the idea behind JIT Manufacturing and JIT Delivery, through the study of people standing in lines. Little’s Law shows that a relationship exists between the average number of people in a line, their rate of arrival to the line, and the average time spent in the line.
If you think about a line (or queue), say a line in a grocery store waiting to check out, one person at a time is getting their groceries totaled up and paying. Once they are done, they exit the line and each person moves up one spot. If the flow of customers to the store increases, the line gets longer, the average duration of time spent in the line increases and the cashier’s work in progress increases. Hopefully, the store will open more registers, but probably not.
This seems fairly logical, you put more people in line and it takes them longer to get through the line. The psychological implications on the cashier of the long line, the one doing the work, may cause him or her to slow down. They see this huge amount of work and come to the conclusion that they will never make any progress, maybe they go home frustrated and dream of quitting their job. The customers also become restless, perhaps they leave after an hour in the line and go somewhere else.
What can be done about this? Try to limit the number of people in the line. Open up extra cash registers when lines reach a certain length helping to keep the flow smooth.
The basic formula for Little’s Law in relation to Kanban is WIP = Throughput * Cycle Time.
WIP, or Work In Progress, is the average number of items in the process. Throughput is the average rate that the WIP items get through the queue. With cycle time being the average time spent in the queue. If you want to increase throughput and cycle time, you can limit the Work in Progress.
*Some people define cycle time a little differently than the time spent in the queue from beginning to end, feel free to call it something else (Lead time, Throughput duration, I don’t care what you call it).
To sum things up:
Agile Kanban = Just in Time Manufacturing – Manufacturing + Delivery
Agile Kanban ≠ kanban board
A better name for Agile Kanban would be Just in Time Delivery, but it doesn’t sound as cool, so we call it Kanban.
The basic idea was thought up by some dude watching people grocery shop, and some other dude helped to prove the basic concept. I didn’t cover the dude that decided JIT Manufacturing would work with service delivery, that might be important to the origins of Agile Kanban but this post is long enough.
While this post wasn’t intended to champion the use of Kanban, just to give a brief history and overview of it, Kanban does have a lot of uses. Of probably all Agile approaches, it is the most versatile. You take your existing business structure and shove Kanban into it. You can use it in Waterfall, and you can make it part of your daily work organization structure outside of projects. The key to that extra versatility lies in continuous delivery versus other Agile approaches incremental delivery.
Companies have also reported huge gains to productivity by implementing Kanban. It isn’t magical, it does require monitoring the processes, but Kanban provides you with the ability to do that more easily – so if you notice bottlenecks in the overall system you can work to alleviate those bottlenecks. (You can use a Cumulative Flow Diagram)
I am, however, growing more skeptical when I hear people say they use Kanban inside of another Agile approach. Kanban’s very nature would seem to conflict with the incremental delivery of most Agile approaches. More likely, they are using a kanban board. A kanban board is not Kanban.
Scrum, for example, already has a process for limiting work into the increment, it can use a kanban board to track the flow of that work. Work in Scrum is also supposed to be finished up at a defined set time for each iteration, whereas Kanban is supposed to be a continuous flow of work. The hybrid Scrum/Kanban approach, Scrumban, was created more to transition from Scrum into Kanban – but it utilizes the continuous flow of Kanban rather than the iterations of Scrum; making it more acceptable in my opinion to be called Kanban.
If you are interested, here is a good post about Scrumban from the Agile Alliance: https://www.agilealliance.org/what-is-scrumban/.
IBQMI (2017), “Certified Kanban Coach; The Official Training Material” International Business and Quality Management Institute. Cheyenne, WY.
Toyota: Toyota Production System- http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/
Informs – Information on John Little: https://www.informs.org/Explore/History-of-O.R.-Excellence/INFORMS-Award-Namesakes/Little-John-D.-C
Images from https://www.pexels.com/