Smartpedia: Kanban is a work and process management method for visualising work progress, which helps to identify bottlenecks and continuously improve processes.

Kanban – production and knowledge work within view

In a production hall, every machine must run smoothly, materials must be delivered just-in-time and every part must be in the right place at the right time. At the same time, an IT team is working on managing software development projects in which various tasks and requirements are interlinked. In both scenarios, there is a risk of chaos if there is no precise control over what happens when and how. This is where Kanban comes into play:

Kanban is a method of work and process management that was developed in the 1940s in the Japanese automotive industry to optimise the flow of materials in production processes. Since the 2000s, Kanban has also been used in knowledge work and is considered a method in agile project management and in software and product development.

Kanban - production and knowledge work within view

The history of Kanban

The Japanese word Kanban consists of the parts kan = signal and ban = card, which together means ‘signal card’.

Inspired by the processes in supermarkets, where customers help themselves and employees ensure sufficient stocks on the shelves, Taiichi Ohno [1], a production manager at Toyota, developed Kanban in the late 1940s as part of the Toyota Production System. The aim was to make the material flow more efficient by only producing what was actually needed. Kanban cards were used as visual signals to indicate when new materials needed to be produced or delivered, thereby avoiding overproduction and unnecessary stockpiling.

Around 2005, computer scientist David H. Anderson [2], who had worked for Motorola and Microsoft, among others, transferred Kanban as a method to knowledge work. He recognised the potential to optimise abstract work processes, for example in software development, through the visualisation and continuous flow of work.

Today, the method is used in many industries and disciplines, whereby a distinction is made between two different types of Kanban:

  • Production Kanban, also known as Manufacturing or Operational Kanban, and
  • Knowledge Work Kanban, also known as Agile or IT Kanban.

Although both types have different origins and areas of application, they are based on the same principles:

The principles of Kanban

Kanban is based on four basic principles that ensure that processes can be improved efficiently and continuously. These principles are universally applicable, whether in production, software development or other areas of knowledge work.

Principle 1: Start with what you are doing now

The 1st principle is a clear invitation to apply the method in a current work situation and, if possible, without delay. It is not about identifying a perfect project or finding a team that is particularly motivated, it is about getting into the application quickly and starting the implementation with the existing processes and structures.

Example:

When Taiichi Ohno introduced the Kanban system at Toyota, he did not start with a radical reorganisation of the production processes. Instead, he took the existing production process as a starting point and introduced signal cards to control the material flow. The aim was to make the production line more efficient without changing the entire structure.

Ohno looked at the existing processes, identified bottlenecks and inefficiencies and then gradually introduced the new system. The introduction of the cards made it possible to control material replenishment by only producing or delivering new parts when they were actually needed. This resulted in a leaner and more efficient production process without disrupting the original processes and structures.

Principle 2: Pursue incremental, evolutionary change

Instead of making large and potentially disruptive changes, the 2nd principle propagates a culture of continuous, small improvements. A PDCA cycle (Plan, Do, Check, Act) reduces the risk associated with large-scale change and makes the transition smoother.

  • It reduces resistance to change as employees do not feel that their previous work is being devalued.
  • It enables a smooth transition where best practices can be maintained and gradually optimised.
  • It recognises that existing processes and rules often exist for a reason and contain valuable knowledge.

Example:

A production line realises that delivery times for a particular component are repeatedly causing delays. Instead of changing the entire system, the supply chain is first analysed and gradually optimised to eliminate the bottlenecks.

Principle 3: Respect existing processes, roles and responsibilities

The 3rd principle emphasises the value of existing processes and structures, roles [3] and responsibilities. Instead of throwing everything overboard, the existing system is used to make improvements without questioning existing roles or responsibilities as a first step.

Example:

David J. Anderson introduced Kanban to a software development team at Microsoft that was working on a complex, lengthy product line. Instead of radically redesigning the team or immediately introducing new processes, Anderson began by analysing the existing workflow and making small, incremental improvements.

First, the team visualised the existing process on a board. In doing so, they identified bottlenecks and inefficient ways of working. Instead of making immediate, comprehensive changes, the team gradually introduced so-called work-in-progress limits and gradually adjusted the process rules to improve the workflow.

These small, evolutionary changes led to significant improvements in the efficiency and quality of software development over time, without the team being overwhelmed by radical changes. The continuous adaptation and improvement of the process enabled Microsoft to shorten development cycles and increase product quality.

Principle 4: Encourage people at all levels to take the lead

The 4th principle aims to promote a culture of ownership and engagement within the organisation. [4] It is about breaking down traditional hierarchical leadership models and instead encouraging all team members to take responsibility and show initiative in their respective areas.

Example:

At a software development service provider, team members are encouraged to coordinate with each other and make joint decisions and suggestions to optimise work processes. Tasks such as moderating meetings or coordinating sub-projects are rotated among team members and experienced team members support less experienced colleagues in developing their skills.

Ideally, the implementation of the 4th principle leads to greater motivation of all those involved, better problem solving and more efficient teamwork overall.

Remark:
It is important to emphasise that this is not about abolishing formal management positions, but rather about creating a culture in which every employee feels like an important part of the team and actively contributes to improving work processes.

The practices of Kanban

In addition to the four principles, Kanban also recognises six practices:

Practice 1: Visualise your work

One of the central practices of Kanban is the visualisation of work. This is typically achieved by using a Kanban board on which all pending tasks are displayed as cards. These cards go through different columns, each representing a step in the process, such as

  • ‘To do’,
  • ‘In progress’ and
  • ‘Done’.

A simple real-life example could be a team developing features for a piece of software. Each functionality is represented as a card on the board. The team can see at a glance which tasks are pending, which are in progress and which have been completed.

Practice 2: Limit parallel work (WIP limit)

Another important practice is limiting the amount of parallel work in progress, also known as the work in progress limit (WIP limit). This means that only a certain number of tasks may be processed simultaneously in a certain phase. Let’s assume that a team has determined that it can effectively work on a maximum of three tasks at the same time without compromising quality or creating bottlenecks. The team therefore sets a WIP limit of three for the ‘In progress’ column on the Kanban board. This prevents too many tasks from being started but not completed at the same time.

Working with the WIP limit is reinforced by the pull principle applied, according to which tasks are only started if capacity is available for them. In contrast to a push principle, where tasks are pushed into the process regardless of the current workload, the pull principle pulls tasks into the work process when there is space (i.e. an employee with capacity).

Practice 3: Manage the work flow

Managing the flow of work is about regularity, punctuality and economically good results. It is about ensuring that tasks flow smoothly through the system without unnecessary delays. An example would be a marketing team planning and executing a series of campaigns. By monitoring the progress of each campaign on the Kanban board, the team can ensure that all campaigns are completed on time and that there are no unnecessary bottlenecks.

Practice 4: Formulate explicit process rules

For transparent and objective collaboration, it makes sense to define explicit process rules. They help to implicitly develop a common understanding and thus complement the explicit visualisation of the work. Ideally, the process rules do not fill extensive documents, but rather bring agreements down to a common denominator: tasks in the ‘To do’ column should not cause more than 5 working days of effort, tasks are only considered completed when the Definition of Done has been met, etc.

Practice 5: Implement feedback loops

Feedback loops enable the team to continuously improve the work process. Imagine a software development team working on a large project with two-week sprints and using Kanban to visualise and control the flow of work. At the end of each iteration, the team conducts a retrospective, which is a kind of feedback loop. In these meetings, the team members reflect on the past two weeks and discuss what went well, what challenges they encountered and how they can improve the way they work.

Practice 6: Improve the process continuously and collaboratively

Continuous and collaborative improvement is a central practice in Kanban, also known as Kaizen. The aim is to continuously optimise collaboration and processes. Instead of focussing on large, infrequent changes, constant readjustment promotes the working method and, as a consequence, the work result. For example, a product development team might be working on a new kitchen appliance and realise that a certain component is taking too long to produce and the quality is fluctuating. Instead of reworking the entire design, the team makes a small change to the assembly sequence, reducing production time by 10% without compromising quality. This continuous improvement is immediately integrated into the process, and the team continues the cycle of small adjustments and optimisations to make the entire development process more efficient.

The values of Kanban

In addition to the four principles and six practices, Kanban is based on nine values. They are central to the application as they define the framework for how work is organised, carried out and optimised:

Value 1: Transparency

Transparency means that all work steps and problems that arise are made visible, there is an open exchange of information and clear, unambiguous terminology is used. This enables the team to see the current status of tasks at all times, recognise potential obstacles at an early stage and make joint decisions as a team.

Value 2: Balance

Balance aims to harmonise the demands on the team with its performance. The aim is to organise a workload that is as consistent and balanced as possible without becoming (permanently or repeatedly temporarily) overloaded. This is often achieved by setting work-in-progress limits. Similar to Scrum, the aim is to work together calmly and continuously at a constant speed, integrate feedback at an early stage and thus consistently avoid undesirable developments in order to increase the overall speed of development. The balance is reinforced by the pull principle.

Value 3: Collaboration

The value of collaboration addresses close, cooperative collaboration with the aim of getting work done effectively and achieving continuous improvements. In a product development team, for example, designers, engineers and marketing experts could work together regularly to ensure that the product is both functional and marketable. To do this, they hold weekly meetings to synchronise their work, coordinate progress and solve problems together.

Value 4: Customer focus

Some companies often lose sight of their customers. Customer focus emphasises understanding the customer’s needs and aligning work to deliver maximum value to the customer. For example, if the support team notices that customer enquiries on a particular topic are increasing, it prioritises the solution in the next software update in order to quickly increase customer satisfaction and reduce future enquiries.

Value 5: Workflow

Workflow refers to the smooth movement of tasks through the system. A steady flow without blockages and delays is the goal. For example, if a logistics company uses a Kanban board to visualise the shipping process, it ideally recognises immediately when a delivery is stalled so that the team can take action to restore the flow of work – also known as workflow.

Value 6: Leadership

Leadership in the Kanban context means that everyone in the team can take the initiative when opportunities for improvement are recognised. Leadership is not limited to formal leadership roles. For example, if a software developer discovers an opportunity to speed up the code review, they suggest the change and lead the team through the implementation of the new approach.

Valure 7: Understanding

Understanding means that a team needs or has a common picture of the current situation and the challenges. This shared understanding is necessary to implement change effectively. So before a team introduces new tools or processes, it makes sure that all members understand the reasons for the change and agree on how the new methods should be applied.

Value 8: Agreement

Agreement means that those involved need clear agreements, follow defined processes and make commitments in order to make the system effective. For example, if a team agrees in a retrospective to introduce new WIP limits in order to improve quality, all members commit to respecting these new limits in their daily work.

Value 9: Respect

Respect means recognising the contributions and decisions of all team members and trusting that everyone is doing their best. So if a member of a project team makes a mistake, it is ideally not a question of apportioning blame, but of analysing the error and discussing together in the team what can be done in future to avoid this and similar errors. Every contribution is also taken seriously and respected.

These values form the backbone of the Kanban method and help teams not only to organise their work, but also to develop a culture of continuous improvement, learning and collaboration.

Application of Kanban in production

In production, Kanban is traditionally used to efficiently control the flow of materials and optimise stock levels. A typical scenario would be a production line where different components need to be assembled in a specific order.

Imagine a production line for automotive parts. In this environment, Kanban serves as a visual control system. Every time a component is used up in the production line, a Kanban card is sent to the previous step or to the warehouse to replenish the component. This signal means that the exact quantity that has been consumed should be re-produced, avoiding overproduction and minimising stock levels.

An example of this is the use of physical Kanban cards in boxes or containers. As soon as a box of screws is empty, for example, the Kanban card is forwarded to materials management for reordering. This orders or produces the exact quantity required to refill the crate. This process ensures that production runs continuously and without unnecessary interruptions, while at the same time keeping storage costs low.

This method keeps production lean, flexible and adaptable to actual demand. It allows the company to react quickly to changes in production volumes without the risk of over or under production.

Application of Kanban in project management and software development

Kanban is used in project management and software development to visualise the progress of tasks and optimise the workflow within a team. This is less about the physical flow of materials and more about the management of tasks or the realisation of user stories, for example.

For example, a software development team could use a digital Kanban board that is divided into columns such as ‘Backlog’, ‘In progress’, ‘In review’ and ‘Done’. Each task or user story is represented as a card on the board. The team starts with a large backlog of tasks that need to be completed for the next software version. By limiting the number of tasks that can be worked on simultaneously (WIP limits), the team ensures that developers are not overloaded and focus on completing a task before starting a new one. For example, if a developer is working on a task in the ‘In progress’ column, they cannot accept a new task until the current one has been completed and moved to the next column.

The Kanban board provides a clear overview of the status of all tasks at all times, and potential bottlenecks are immediately visible. The team can discuss progress in regular meetings and make adjustments if necessary to improve the workflow.

The continuous visualisation and management of the workflow increases efficiency and the team can adapt better to changing requirements. Kanban helps to complete projects on time and with high quality, while promoting flexibility and satisfaction among team members.

Questions from the field

Here you will find some questions and answers from practice:

What are the advantages of Kanban?

Kanban offers a whole range of advantages:

  • It provides teams with a structure that allows them to work independently and make decisions based on the current state of work. As tasks are visualised and priorities are clear, team members do not have to constantly wait for instructions from above. This promotes self-organisation and strengthens trust within the team.
  • Thanks to the transparency and clear visualisation of tasks, team members always know what is due next and what priorities have been set. This reduces stress and frustration, which are often caused by unclear requirements and priorities, and enables employees to better manage their workload.
  • It encourages open communication within the team, as all members always have the same overview of progress. There are fewer misunderstandings and problems can be recognised and solved together more quickly. This leads to improved collaboration and stronger team cohesion.
  • As Kanban is based on the continuous visualisation of work, it enables teams to learn from their ongoing process. They can identify patterns and trends that may lead to bottlenecks and continuously optimise their processes. This leads to a culture of learning and continuous improvement, which is highly beneficial in the long term.
  • It also encourages an experimental mindset, as small changes in processes can be visualised immediately and their effects observed. Teams are encouraged to try out new approaches and continuously improve, which can lead to more innovative and efficient ways of working.

Last but not least, Kanban can easily be applied to non-technical areas such as marketing, HR or even the education sector. It is not limited to manufacturing, project management or software development and can be used effectively in any type of work that requires flow and task management. This makes it a universally applicable method.

What is a lead time?

In the context of Kanban, lead time is the total amount of time it takes for a task or element to complete the entire production or development process. It starts from the moment a task is added to the process and ends when it is fully completed and delivered to the customer or stakeholder.

When a software development project develops a new functionality, the lead time begins as soon as the decision is made to develop this function. The time span includes all steps, including planning, development, testing and final delivery. The lead time ends when the function is available to the end user.

The lead time is an important indicator of the efficiency of a process and helps teams to identify bottlenecks and optimise the entire workflow. A shortened lead time indicates that the team is working faster and more efficiently and delivering customer value more quickly.

What is a cycle time?

In Kanban, cycle time refers to the amount of time it takes for a task to flow through the active work process, from the moment work on the task actually begins to the time it is completed. Unlike lead time, which measures the entire process from the start of a task to its completion, cycle time focuses specifically on the time that elapses during the actual processing of the task.

Suppose a software developer is given the task of implementing a new feature. This task is moved to the ‘To do’ column of the Kanban board on Monday of the first week, but the developer only starts working on it on Monday of the second week and finishes on Friday. Accordingly, the task is moved to the ‘Done’ column.

The lead time measures the entire period of time from when the task is first added to the workflow (i.e. when it is moved to the ‘To do’ column) to the point at which it is fully completed. In this example, the lead time would be the time from Monday of the first week (when the task appeared on the board) to Friday of the second week (when the task was completed). This corresponds to ten days.

The cycle time, on the other hand, only measures the period of time in which the task is actually being actively worked on. This means that the cycle time begins when the developer starts work on Monday of the second week and ends when the task is completed on Friday of the same week. In this case, the cycle time is five days.

What is the WIP limit and how can it be determined?

A WIP limit (Work In Progress Limit) is a central component of the Kanban method and describes the maximum number of tasks that may be processed simultaneously in a specific phase of the work process. The aim of a WIP limit is to avoid overloads, optimise the workflow and ensure that tasks are completed efficiently before new ones are started.

  • WIP limits prevent team members from working on too many tasks at the same time, which can lead to inefficient work and a loss of quality.
  • By limiting parallel work, it becomes easier to identify and resolve bottlenecks in the process.
  • Fewer concurrent tasks often leads to faster completion of each task, which reduces overall cycle time.
  • With WIP limits, your team is encouraged to focus on a few tasks and complete them thoroughly.

There are a few tips for determining the WIP limit:

To set the right WIP limit, you should first analyse your current workflow. Check how many tasks are currently being processed at the same time and whether there are any overloads or delays to get an initial indication.

It makes sense to start conservatively with a rather low WIP limit to ensure that your team is not overloaded. A WIP limit is easier to increase than decrease if it proves to be too restrictive. A common approach is to set the WIP limit at 1.5 to 2 times the number of team members. For a team of four people, for example, the limit could be six to eight tasks.

Observe how the work develops with the set WIP limits and adjust them if necessary. The optimum WIP limit is often only found after a few adjustments. It is important to involve the team in the process and consider the opinions of the team members in order to create acceptance and a common understanding of the WIP limits.

Make sure that the WIP limit is neither so low that it unnecessarily slows down throughput, nor so high that quality suffers. Finally, you should also consider the size of the tasks. If the tasks vary greatly, it may make sense to define the WIP limits according to workload (e.g. story points or estimated hours) instead of the number of tasks.

Incidentally, there are also approaches that set the work in progress limit to 1. [5]

What is the difference between Scrum and Kanban?

Although Scrum and Kanban have similar goals – to increase efficiency and flexibility – they differ significantly in their approach and structure. Here are the main differences:

Scrum works with set iterations, known as sprints, which usually last 1 to 4 weeks. At the end of each sprint, a functional product increment should be available. It defines three specific responsibilities or accountabilities (Scrum Master, Product Owner and Developer) with corresponding activities, uses five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective) and declares three artefacts (Product Backlog, Sprint Backlog and Increment)

Kanban, on the other hand, works without fixed iterations. Tasks are continuously pushed through the workflow as soon as capacity becomes available. There are no fixed roles and the process is flexible in terms of meetings, although regular reviews, feedback loops and adjustments to the workflow are still practised. Kanban also uses WIP limits to restrict the number of tasks processed simultaneously and to focus on task completion.

Scrum addresses the delivery of a defined scope within a sprint. It emphasises incremental growth of the product with the aim of having a potentially deliverable product increment at the end of each sprint. Changes during the course of a sprint are possible, but are avoided if they make sense. New tasks are usually prioritised in sprint planning.

Kanban, on the other hand, emphasises the continuous flow of work and the optimisation of the entire process. The aim is to shorten throughput times and identify bottlenecks. The aim is to achieve a consistent, stable workflow in which tasks are completed as quickly and efficiently as possible. Changes can be made at any time as there are no fixed iterations. Tasks are prioritised dynamically, often in real time, based on current demand and availability.

Conclusion:

Scrum is well suited to projects where it is important to work in short, predictable iterations while regularly delivering functional product increments. Kanban, on the other hand, is ideal for teams that need to work continuously and flexibly, especially in environments where priorities change frequently and the focus is on a constant flow of tasks.

What is Scrumban?

Scrumban is a hybrid approach that combines various elements of Scrum and Kanban to enable a flexible yet structured way of working. Scrumban was originally developed to make the transition from Scrum to Kanban easier for teams, but it has since established itself as a method in its own right.

In Scrumban, the fixed iterations from Scrum are retained, which means that sprints play a central role. Scrumban combines the regular sprints of Scrum with the flexible WIP limits and continuous flow of Kanban.

A Scrumban team continues to plan its work in sprints and carries out regular sprint planning, daily stand-ups, sprint reviews and retrospectives. The difference to pure Scrum lies in the fact that Scrumban integrates the limitation of simultaneous work (WIP limits) and the continuous visualisation of the work flow in order to optimise the process. This mix makes the method particularly suitable for teams that work in a dynamic environment and at the same time require a certain degree of stability and planning security.

What is Personal Kanban?

Personal Kanban is an approach that applies individual Kanban principles to individual task management. It was developed by Jim Benson and Tonianne DeMaria Barry to help individuals to better organise their work and possibly also their private lives, to keep an overview and to set priorities. [6]

The approach is based on two central principles: the visualisation of work and the limitation of parallel tasks. Through visualisation, tasks are clearly displayed, often on a simple board with the columns ‘To do’, ‘In progress’ and ‘Done’. This provides a clear overview of the status of all pending tasks and helps to set priorities more effectively.

Another important aspect is the limitation of the number of tasks that can be processed simultaneously. This limit serves to focus on completing individual tasks before starting new ones, which minimises overload and stress. The method is flexible and can be implemented both digitally and physically, depending on individual preferences.

This approach not only increases your own efficiency, Personal Kanban also enables continuous self-reflection and adjustment of the workflow. Ideally, this leads to better prioritisation of tasks and increased productivity, allowing both professional and private projects to be processed in a more structured and targeted manner.

Impulse to discuss:

Should the initiative to use Kanban come from the team itself, or is it more effective if management introduces this method?

Notes:

[1] Logistics Hello of Fame: Taiichi Ohno

[2] David J. Anderson: Kanban – Successful Evolutionary Change for Your Technology Business

[3] Interestingly, the need can be observed in organisations for employees to want to introduce roles and responsibilities without external pressure. See: Clarifying roles in a team.

[4] Traditional leadership styles are based on hierarchical authority and obedience. Modern leadership styles are based on the principles of teamwork, participation and employee development. What is missing from this view: followership. Followership is the other side of the leadership coin. It looks at the behaviour of employees in the course of leadership. See: Strong together: leadership and followership.

[5] The Magic of WIP Limit 1

[6] Jim Benson, Ronianne DeMaria Barry: Personal Kanban

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you can find additional information from the t2informatik Blog:

t2informatik Blog: Lean Kanban, Agile Kanban

Lean Kanban, Agile Kanban

t2informatik Blog: Stumbling blocks in the introduction of Kanban

Stumbling blocks in the introduction of Kanban

t2informatik Blog: Kamishibai and Kanban for (too) interdisciplinary teams

Kamishibai and Kanban for (too) interdisciplinary teams