This article is an introduction to the Kanban Method (or Kanban Methodology) where we explain the origins, its evolution, the benefits it brings and it answers the fundamental questions that you may have about Kanban, like when is Kanban appropriate or when is Kanban better than Scrum.
What is Kanban?
Kanban is like the milkman. Parents didn’t give the milkman a schedule. Parents didn’t use material requirement planning system (MRP). They simply put the empty bottles on the front steps and the milkman replenished them. That is the essence of a pull system.
Kanban (看 板, also かんばん) (English: sign, index card). A Kanban is a signal designed to trigger an event and it can be an empty space, an empty bin, a piece of paper, an electronic signal, or an icon.
Kanban is a Lean tool that supports Just-in-time production (JIT) as opposed to Material Requirements Planning (MRP) and batching.
Technique devised by Taiichi Ohno – the godfather of Toyota Production System (TPS) – to enable Just-in-Time production.
Kanbans facilitate inventory management by providing a sign or signal for replenishment. According to Taiichi Ohno Kanban is a means through which JIT is achieved.
Kanban is a visual management tool to help prevent the waste of overproduction and for detecting delays in the process or when processes are producing ahead of schedule.
There are additional benefits of Kanban like increased flexibility to meet customer demand, reduction in scheduling by production control and manufacturing, and competitive advantage by sequencing shipments to customers to ensure they receive what they want, when they want it, and in the order they want it.
Kanban is similar to the resupply of milk when the milkman would take your empty bottles and replace them with full bottles.
Types of Kanban
In manufacturing there are several types of Kanban:
- Interprocess: Specifies the kind and quantity of a product that the subsequent process should withdraw from the preceding process
- Supplier: Specifies the kind and quantity of a product to be supplied from the supplier
- Production Ordering:
- One-piece flow production
- Small lot (segmented batch) production
- Job Order
- Issued for each job order
- When two processes are very close, it doesn’t make sense to issue two kanbans. Used where one process directly feeds the next process
- Where a withdrawal kanban is used as a production ordering kanban if the distance between two processes is very short and share the same supervisor
- Temporary, when there is a defect or problem, can be withdrawal or production
- Temporary, issued when there is a shortage, can be withdrawal or production
The simplest type of Kanban is called a two-bin system. A two-bin system is composed of two separate bins containing the same parts, with one bin placed behind the other. When the first bin empties, the next full bin slides down. The empty bin becomes the kanban signal or trigger visually indicating that the bin needs to be replenished.
The empty bins are then collected, taken to the stock room (or sent back to the supplier), and refilled. The new bin of materials is then returned to the original location in the area. This is called a withdrawal kanban system.
Kanban systems can also utilize card systems. In this system, the card is taken from the empty bin and placed in a holder (to be ordered). This is called a kanban post.
At certain frequencies during the day, the material handler comes and collects the cards in the post. The cards are used to reorder the parts from the supplier. Once the material is ordered, the card is placed back in the kanban post in the ordered slot.
When the new bin of materials arrives, the card from the reordered slot is placed on the arriving bin of materials. The new bin of materials is returned to the original location in the area. This is called a withdrawal kanban system.
The purpose of a Kanban System is to control the flow of material by providing inventory as a buffer to synchronize two disconnected processes. If this system is used skillfully, all the movements in the plant can be unied.
One piece of paper is providing the information of production quantity, time, method, sequence, or transfer quantity, transfer time, destination, storage point, transfer equipment, container, etc. clearly for grasping at one glance.
Kanban systems regulate the inventory in a production system as the volume or rate of the process changes.
Kanban cards are normally paper-based cards that are used to disseminate three types of information:
- Pickup information
- Transfer information
- Production information
Kanbans can be replenished in two ways:
- Constant time means they are replenished the same time each day or several times a day. This is similar to grocery store shelves being restocked each night
- Constant quantity is similar to the two-bin system. It may empty out at any time, and we refill it with the same quantity every time.
Origins of Kanban
Also known as the Kanban Method or just Kanban, this methodology has been developed and evolved as a business by David J. Anderson and some others, and it gained a lot of traction in recent years as an alternative path to agility.
Like Scrum, XP, Lean or Agile, Kanban is one of the methodologies available in the market today to improve operations in software development and other knowledge-based work.
Although it started in the software industry, Kanban is a method for defining, managing and improving all sort of services delivering knowledge work, such as professional services, HR, design or product management.
The method is based on the concept of a Kanban System – a delivery flow system that controls the amount of work in progress using visual signals.
The visual signals are referred to as Kanbans, which, together with the policies associated with them, create a pull system, where work is “pulled” into the schedule from the upstream process when other work is completed by a downstream process, rather than “pushed” based on a production plan.
The Essence of Kanban
Kanban methodology is used to define, manage and improve systems which deliver services to internal or external customers. A service can be composed by a few people from different functional areas, it can be a team or several teams.
As Kanban is applied principally to knowledge work, where there is no physical work, processes can be easily visualized in virtual kanban systems (or dashboards) where the processes are defined as a series of activities, and associated policies, such as shown in the picture, depicting a flow system where work items flow through various stages of a process, ordered in this case from left to right, including all visual controls and information.
Kanban methodology is based on a very simple idea, which is in our experience the most difficult to explain as it is kind of counterintuitive.Work In Progress (WIP) should be limited and something new should be started only when an existing piece of work is pulled by a downstream function.
There is a famous saying by Kanban acolytes which says “Stop starting, and start finishing”.
The space left in absence of a kanban (or signal card) indicates that new work can be pulled because current work in progress is less than the agreed limit. This doesn’t sound very revolutionary but it is the essence of Just-in-time production (JIT) and the beginning of a huge change in your business.
The Kanban method is an approach to introducing change to an existing software development process or knowledge work process where, unlike other approaches, you start with whatever you are doing now.
Kanban assumes an organization is an ecosystem of interconnected services and it doesn’t require reorganization, just mapping a Kanban System on top of a value stream.
You start by understanding your current process by mapping your value stream and then you define WIP limits for each stage in the process. Then you start to move work through the system by pulling it when Kanban signals are generated.
Because WIP is limited in a Kanban system, anything that becomes blocked for any reason tends to congest the system. If enough work items become blocked the whole process gets to a halt. This has the effect of focusing the whole team and the wider organization on solving the problem, unblocking the item and restoring flow.
Kanban uses a visual control mechanism to track work as it flows through the various stages of the value stream. Typically, a whiteboard with sticky notes, or an electronic card wall system, is used. The best practice is probably to do both, so you have the benefits of human interaction and visual controls as well as the control charts and metrics that electronic tools such as Kanbanize provide.
Kanban as Change Management Tool
Many of the results with Kanban are counter-intuitive. What appears to be a very technical approach – limit WIP and pull work – actually has profound effects on people and how they interact and collaborate with one another.
The transparency that this generates also contributes to mindset change. Kanban provides transparency into the process and its flow. Kanban exposes bottlenecks, queues, variability and waste.
Kanban provides team members and management with visibility into the effect of their actions (or inactions.) Which, in our experience, encourages greater collaboration and teamwork.
The visibility of bottlenecks, waste and variability also encourages discussion about improvements, and teams quickly start implementing improvements to their process. As a result, Kanban triggers incremental evolution of existing processes.
Kanban does not ask for a dramatic revolution of how people work, instead it encourages gradual change.
Kanban encourages delayed commitment on both prioritization of new work and delivery of existing work. Typically, teams will agree to a prioritization cadence for meeting with upstream stakeholders and decide what to work on next.
These meetings can be held often because they are usually very short. A very simple question has to be answered, e.g. “Since our last meeting three slots have become free. Our current cycle time is 2 weeks to delivery. Which three things would you most like delivered 2 weeks from now?”
This improves agility by managing expectations, shortening cycle times from commitment to delivery and eliminating rework since the chance that priorities will change is minimized.
Another effect of limiting WIP is that it provides predictability of lead time and makes deliverables more reliable.
Benefits of Kanban
Kanban methodology brings a lot of benefits within a short period of time and with minimum hassle.
Based on our own experience as Kanban Consultants we can definitely affirm that Kanban will bring to your teams and organization the following benefits in no time:
- Reduction of WIP – this may not seem like a benefit on itself, but it is indeed. Less WIP means less working capital and it is the condition for all of the subsequent benefits.
- Reduction of time-to-market – needless to say how important is to be fast in todays competitive and unpredictable world.
- Reduce overburden – by limiting WIP, establishing policies and implementing pull you maximize system productivity while reducing overburden and multi-tasking. This has the side effect of improving team’s morale.
- Reduce waste of over-production – this is one of the usual wastes in software development – developing more than it is needed or required by the customer – By implementing pull, you reduce the amount of useless additional work
- Productivity – productivity improves by doing less things at a time but finishing more. The focus in Kanban is on making items flow as fast as possible through the system
- Predictability – limiting WIP and implementing pull is a way to reduce variability in a system as well as systematically working to reduce queue size and bottlenecks. This has a direct impact in time-to-market and predictability by reducing risks inherent to the system or work
- Customer satisfaction – customer gets what she expects more often and with better quality so their satisfaction improves. She also has a better understanding of when she can expect things to arrive so she can organize herself better.
- Enables continuous improvement – visualizing everything and limiting WIP provokes conversations that you wouldn’t have otherwise. This leads to a relentless improvement of the process.
When is Kanban Appropriate?
Here we present several situations where Kanban methodology is appropriate.
An Artificial Time-boxed Delivery
Thanks to the spread of Scrum many teams have been forced by consultants and managers to adopt Scrum when clearly their way of working would have benefit from a pull system like Kanban.
You can see these situations just by asking the team members, but there are other clear signs that Scrum is not an option.
We usually find the following symptoms:
- the future is uncertain
- priorities are often changing
- replanning is common and frequent (even within the same sprint with the addition of urgent work or bug fixes)
- high abandonment rate (ideas that are never started and always deprioritized)
- high discard rate for incoming requests
- high abort rate for committed requests where work already started
- there is a high level of delivered work which is ignored, never used or never commissioned for use in the field
Teams are forced to commit early to things for which they are not certain. This is a strong indicator that we need to be able to defer commitment. Kanban systems enable us to defer commitment and would be better choice.
Over the years we have found many different situations, but a usual one, despite the size of the organization, is where teams suffer from overburdening.
These teams are implementing some sort of Scrum but as Scrum is by default a push system their workflow is clogged up, they are unpredictable, and they are suffering from stress and demotivation. This is usually cause by too many requests and too many work in-progress.
Thanks to limiting WIP and making policies explicit, in just a few weeks you can revert the situation with Kanban and in just three months you can transform those teams into high-performing.
Variability in the Flow of Work
Typically variability in the flow of work affects our predictability. If we want to be predictable or we want to produce good quality we need to smooth the flow of work through the service.
Variability in flow can be caused by large batches, by arrival of unplanned work in an unpredictable fashion, or by blockages which prevent work from being completed.
Unplanned work is often of a speculative nature and often comes with a desire for a high class of service. This results in planned work being set aside in order to service the unplanned, speculative work.
Requests for information such as estimates for future work are typical of unplanned, unpredictable, speculative demand. The arrival of this work prevents planned and committed work from being delivered in a timely manner and within customer expectations and service level agreements.
In summary, variability in flow is caused by
- large batches
- unplanned, speculative, disruptive work requests
- blocking issues
Cross-functionality is expensive. Although it is desired and the best approach if you can create cross-functional teams or value streams often times that’s not possible.
Organizing in value stream is always the preferred option, but that’s usually only possible for big companies who grew by adding a lot of people, bureaucracy and waste. If your company is smaller or you want to improve a smaller organizational unit with a limited budget then you should consider adopting Kanban as an alternative.
A typical situation we find is that some teams are already working with Scrum and then there are some shared services that deliver work to those Scrum teams.
What you must do if you have some teams delivering who depend on other teams like Analytics, UX, Design or Content, is to make sure all those shared services use Kanban otherwise the flow of the whole organization is going to be harmed.
For most of these types of teams Scrum is usually not an option due to the nature of their work, so they must adopt Kanban.
Shared services need to implement pull and have adequate policies so that work from different teams and stakeholders can be adequately scheduled and delivered on time.
Variability in Demand
When the nature of the incoming work if highly variable we recommend Kanban over any other methodology. By variable we mean different sources of demand, types of work, sizes, complexities and priorities.
This is case of IT service teams, Operations, Help Desk and so on.
Startups and Innovation Teams
Startups and Innovation Teams suffer from most (if not all) the above problems. So, we strongly recommend Kanban as the default methodology for such organizations.
If you want more details on this you can take a look at our article about Discovery Kanban (Kanban for product teams or innovation teams).
The Kanban System
A Kanban System is a production system operated with Kanban as a means to implement pull.
As well as visual signals to limit work in progress, Kanban systems have identified commitment and delivery points. The commitment is an explicit or tacit agreement between customer and service that:
- the customer wants an item and will take delivery of it, and
- the service will produce it and deliver it to the customer.
Before the commitment point there may be a set of outstanding requests (or a pool of ideas) which may or may not be selected, and a process which has the purpose of selecting items from these options. Kanban applied to processes prior to the commitment point is sometimes referred to as Upstream Kanban. The delivery point is where items are considered complete.
The time that an item is in process between the commitment and delivery points is referred to as the Lead Time for the item.
The number of items that are within the system under consideration at any point in time is known as the Work in Progress or WiP.
The rate at which items are being delivered is known as the Delivery Rate.
The Core Practices of Kanban
The Core Practices of Kanban define essential activities for those managing Kanban systems:
- Visualize (with a kanban board 看板)
- Limit work-in-progress (with kanban かんばん)
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively, evolve experimentally (using models & the scientific method)
Kanban vs Agile
Many people consider Kanban a flavor of Agile and include it under the famous Agile umbrella. Well, it doesn’t belong there.
Kanban methodology will bring agility into your organization but it doesn’t belong to the Agile Manifesto family.
First of all, if you look at the Agile Manifesto, is focused on software development and Kanban it is not, in principle, although it started in the software industry, Kanban allows you to improve knowledge work processes, not just software development.
Second, Kanban is not complying with several of the principles of the agile manifesto, specifically those with regards to teams and self-organization.
Kanban vs Scrum
We can think of both Scrum and Kanban as process improvement tools in that they help you work more effectively by telling you what to do. Both are tools for improving your operations, for making for organization more flexible, faster and adaptable, for improving agility of your business.
Like any tools, Scrum and Kanban are neither perfect nor complete. They don’t tell you everything that you need to do, they just provide certain constraints & guidelines. For example, Scrum constrains you to have time-boxed iterations and cross-functional teams, and Kanban constrains you to use visible boards and limit the size of your queues.
As a general rule of thumb, Kanban methodology applies to any place where Scrum is already working. Besides, you should avoid Scrum in environments with high variability in demand and/or high variability in flow.
The Myth of the Mature Team
Some people affirm that Kanban methodology is for mature teams that have already a strong experience in Agile. I don’t think so. I’ve worked with more experienced and less experienced teams with Kanban and all ramped up pretty quickly.
Similarities between Kanban & Scrum
- Both limit WIP – Scrum by limiting the amount of work per sprint and Kanban in many different ways by Class of Service, by activity or using CONWIP in less mature implementations
- Both use transparency to drive process improvement
- Both focus on delivering releasable software early and often
- Both require breaking the work into pieces
Differences between Kanban & Scrum
|Scrum is a push system. Despite the fact that teams pull a batch of backlog items into the sprint backlog that doesn’t mean it is pull.|
In Scrum you plan your production in advance based on a prediction of productivity for a given period of time. That is push.
|Kanban is pull by definition.|
|Time-boxed iterations (Sprints)||Kanban dispenses with the time-boxed iteration an instead decouples the activities of priorization, development and delivery. The cadence of each is allowed to adjust to its own natural level. Kanban does not dispense with the notion of a regular cadence, though. Kanban teams still deliver software regularly, preferring a short timescale. However, Kanban avoids any dysfunction introduced by artificially forcing things into time-boxes.|
|Scrum only talks about Definition of Done as a policy||One of the fundamental principles of Kanban method is to make all policies explicit. That includes DoD, DoR, policies in between activities in the value stream, policies for blocking/unblocklng work, policies for shaping demand, etc.|
|Although not explicitly mentioned in the Scrum guide, most Scrum teams use velocity in story points for planning and process improvement||Kanban uses basic Lean process metrics like Lead Time, WIP, Aging or Throughput for planning and process improvement|
|Cross-functional teams prescribed||Kanban doesn’t explicitly mention teams. The focus of Kanban is to improve service delivery, if that service is made up of 3 people, several functional teams or several cross-functional teams we don’t care. We map the value stream and connect everything with a kanban system|
|Push scheduling of a batch with cadence (time-box)||Pull scheduling with single-piece flow|
|Estimation is required||There is no specification in Kanban to estimate. Most teams do it as a inertia from the past, but they stop doing it as soon as they realize it is not needed in order to improve and increase predictability|
|A Scrum Board or Scrum Backlog is owned by one team||A Kanban System can be composed by more than one team (Horizontal) or levels within the organization (Vertical)|
|Prescribes three roles (Scrum Master, Product Owner and Team)||Doesn’t prescribe any role, although some people in the Kanban community started mentioning the roles of Service Delivery Manager and Service Request Manager|
|Prescribes a prioritized Product Backlog||In a pull system there is no prioritization things get done as they are pulled into the system. What you need to define are the policies for getting things into the system. Think of a Kanban System as an airport in rush hour. There is no an “Airport Owner” ordering/reordering and estimating people as they arrive to the airport, instead every person has a class of service and is automatically directed to their specific queue where they will be processed in arrival order (VIP, Crew, Staff, Business Travellers, Families, Disabled, Special Objects, Normal Traveller)|
Getting Started with Kanban
Kanban methodology is an approach that drives change by optimizing your existing process. The essence of starting with Kanban is to change as little as possible.
The main target of change will be the quantity of WIP and the interface to and interaction with upstream and downstream parts of your business.
You must work with your team to map de Value Stream as it exists. Try not to change it or invent it in a idealistic fashion. You can only benefit from a card wall if it reflects what you actually do.
In other articles we will discuss in more detail different approaches to introducing Kanban into organizations, such as STATIK (Systems Thinking Approach to Introducing Kanban) or Kanban Kickstart, but for now, you can just get started with this simple process with ten steps based on our own experience.
- Agree on a set of goals for introducing Kanban
- Map the value stream
- Define some point where you want to control input (Commitment Point)
- Define some exit point beyond which you do not intend to control (Delivery Point)
- Define a set of work item types based on the types of work requests that come from the upstream stakeholders
- Analyze the demand for each work item type
- Agree policies with upstream and downstream processes:
- Discuss policies around capacity your Kanban System and get an agreement on a WIP limit
- Discuss and agree on an input-coordination mechanism, such as regular replenishment meeting, with the upstream process
- Discuss and agree on a release/delivery-coordination mechanism, such as regular software release, with the downstream process
- You may need to introduce the concept of different classes of service for work requests
- Agree on a lead-time target for each class of service of work items. This is known as a Service Level Agreement (SLA)
- Create a dashboard to track the value stream (Ideally both physical and electronic)
- Agree with the team to have a standup meeting every day in front of the board (Daily Planning Meeting)
- Agree to have a regular service delivery review meeting for retrospective analysis of the process