Skip to content

Theory "Agile Method Kanban"

Kanban is a scheduling system for just-in-time-production that was developed by Toyota and plays an integral role in the Toyota Production System (TPS). Originally, Kanban was developed for Lean Production, but it was later adapted for the use in (IT) projects. The term "Kanban" is derived from the Japanese language and means signal card. In project management it can help to visualise the work and to get a better understanding of the workflow. For this purpose, tasks are noted on a Kanban card and attached to a Kanban board for visualisation.

A Kanban card contains all necessary information for the employees. These are essentially Kanban type, Kanban ID, number of cards, article number, article text, quantity, supplier, storage location (source), storage location (destination), recipient, barcodes and product image.

The Kanban method can be used at different levels:

Team level
Mapping a project with the Kanban board can lead to a better understanding of the workflow. It makes it easier for you to organise and manage your work and enables your team and project members to keep track of each task.

Portfolio level
If your strategic goals are visualised on a separate Kanban board, you can easily see which ones have been started or completed. At the same time, using it makes it easier for you to keep track of every single project that takes place in the company.

Principles and practices

In Kanban there are four principles and six practices.

The 4 principles:

  • Principle 1: Start with what you are currently doing.
  • Principle 2: Commit to incremental and evolutionary change.
  • Principle 3: Respect existing processes, roles and responsibilities.
  • Principle 4: Encourage leadership at all levels of the organisation.

The 6 practices:

  • Practice 1: Visualise work processes.
  • Practice 2: Limit work in progress.
  • Practice 3: Manage task load.
  • Practice 4: Make process guidelines explicit.
  • Practice 5: Implement feedback loops.
  • Practice 6: Improve collaboratively and develop empirically.

Objectives of the Kanban method

The objectives of Kanban are to improve productivity as well as quality and maximise production flexibility.

These goals are to be achieved by avoiding waste and errors. Waste in this context means work that does not add value to the product, overloading of employees and machines, and irregularities in processes. Overproduction is also waste and should be avoided. Waste here means that the products produced but not currently needed take up storage space and tie up capital that is therefore not available to the company for other - possibly more important - tasks.

Basically, Kanban is a method for procuring and providing the materials that are crucial for each production step. Kanban cards contain all information that is needed to obtain the required production items. They move between the supplier and customer processes.

Material and information flow

  • Material flows are all in a forward direction (from the supplier to the customer).
  • Information flows are all in a backward direction (from the customer to the supplier).

That's why the Kanban method is also described as a pull system. A pull system is a process scheduling system that signals what to produce and which only produces the items that customers need. Pull systems are customer driven or demand oriented, i.e. demand for production orders comes from the end of the logistics chain.

Kanban in IT projects

Application of Lean Production, Lean Development and the Theory of Constraints

The principles of IT-Kanban, as described above, originate from the production process and warehouse management and have been adapted. The principles from Lean Production, Lean Development and the Theory of Constraints can also be found.

Lean Production is part of the Lean Management concept. This means the economical and time-efficient use of production factors (people, machines, etc.).

Lean Development transfers the management concept of Lean Production and Lean Management to the area of software development.

Theory of Constraints assumes that the performance of a system is limited exclusively by one factor, the bottleneck. Performance can only be improved if the entire system is adapted starting from the bottleneck.

If within a project a particular work step causes a bottleneck (= constraint) - e.g. because only one colleague in the department can do a specific task - then a common reflex is to deploy more colleagues from other departments. On one hand, this can be dangerous, since the team size should not be changed, especially in agile teams, amongst others. Furthermore, this can lead to a resulting bottleneck arising somewhere else. For these precise reasons, two adjustments are made:

  • The number of tasks per station is limited to a maximum amount.

  • A pull principle is established. This means that developers "pull" tasks from the task backlog for further processing. This can only happen if they have processed other tasks which have been pulled by the subsequent team member.

If a queue nevertheless arises because problems occur at one station, e.g. when testing tasks, then the colleagues from the other stations can step in and work together on a solution, as they themselves cannot "pull" new tasks due to the limited number of entries in their station. For example, the developers could work together with the testers on possible solutions. The advantage of a cross-functional team is that the developers gain more insight into testing - and vice versa. In other words, you learn from each other!

There are no increments in Kanban. It's a continuous process. The workflow is visualised and work in progress (WIP) is limited.

Visualising the workflow

The Kanban board

The value chain is presented to the participants with the help of a Kanban board (e.g. large whiteboard, Kanban software). The Kanban board can either be "owned" by one team or jointly by several teams.

The board lists the individual process steps (e.g. requirement, design, implementation, test etc.) in columns. The individual tasks are written on cards or post-it notes and stuck onto the board in lines (or above the relevant symbols in the electronic Kanban application). Combinations are also often used, in which the Kanban board is observed with a camera for changes.

The tasks or requirements can be formulated as a user story, feature, use case, etc.

  • A user story describes the activity of a user systematically. The focus is on the question of who does what to achieve which goal.
  • A feature describes a performance characteristic, a function (e.g. print output) of a software application.
  • A feature describes a performance characteristic, a function (e.g. print output) of a software application. Graphical modelling of the use case with the help of the "Unified Modelling Language" can be used as a supplement and can be helpful.

According to the pull principle of Lean Production, the worker picks up the completed task of the previous work step for the following work step.

Through this type of processing, cards or post-its move from left to right on the Kanban board until the individual tasks are completed. There are no rules for the design of the Kanban board, i.e. it can be freely adapted to the individual team needs.

Title: Fig. 14.1:  The Kanban board, divided into Backlog, Requirements, Design, Implementation and Done.

Limiting work in progress (WIP)

Dealing with constraints

The Kanban board creates transparency and enables the quick identification of bottlenecks.

In the example, the bottleneck is the implementation, as the topics completed by the design cannot be implemented at the same speed. This means that an even flow of work is no longer possible. A remedy can be found by limiting the work-in-progress of the "Design" column. Limiting the WIP in the design area to four would mean that only four cards in total may be attached in the "Design" column. This is to ensure that no more results are produced in one processing step than can be processed further. After some time, the tasks are then processed and the bottleneck is solved.

Metrics

Lead and cycle time

Below, the metrics that are used in the Kanban method are outlined.

Lead Time:
The so-called lead time is the time needed to complete a task since it became known. This can be, for example, the period in which a customer communicates his order until the delivery date of the finished product.

Cycle Time:
The cycle time is the time needed from starting to finishing a task. In other words, the complete time it takes to complete a task. For example, in the case of a call centre, this would be the time required starting when the team has actively started working on the task until it's completion. It also includes any interruptions, pauses or waiting times between the individual process steps.

Cumulative flow diagram (CFD)

A cumulative flow diagram can be used to check the progress of the project.

Cumulative-Flow-Diagram:
This diagram visualises how many tasks or tickets are in which processing status on a given day. By observing the lead or cycle time, it is then possible to determine exactly how the tasks are completed.

The following metrics can be read from the cumulative flow diagram:

  • Backlog (open points)
  • Cycle Time (time spent on design)
  • Lead Time (horizontal distance between requirements and implementation)
  • Work in Progress (vertical distance between requirements and implementation)
  • Done (tasks completed)
  • Throughput (incline in the diagram)

Scrum vs. Kanban

Similarities

Scrum and Kanban both emphasise:

  • transparency and visualisation
  • agile processes
  • frequent and early delivery of ready-for-release components
  • use of a pull principle
  • limiting the simultaneous processing of issues (work in progress)
  • breaking down requirements into detailed individual steps
  • few rules

ATTENTION: Kanban has less rules than Scrum.

Scrum Kanban
Scrum has three roles (Product Owner, Scrum Master, Developer). Kanban does not define roles. If necessary, roles can be defined individually for each project by those involved.
Relies on a self-managing cross-functional Scrum Team. Relies on self-organising teams, interdisciplinarity is optional.
The WIP is limited indirectly (per Sprint). WIP is directly limited (in each process step).
Estimating is mandatory. Estimating is optional.
The Sprint Backlog (Scrum task board) is cleared after each Sprint. The Kanban board is continuously updated.
The backlogs are prioritised. Prioritisation of requirements is optional.
The Sprint Backlog belongs to a specific team of Developers. The Kanban board can be used by several teams / individuals.
No new tasks / items can be added to a Sprint. New tasks can be taken on if the team has available capacity.
Product Backlog Items have to be broken down so that they can be completed in a Sprint. There is no prescribed size for Product Backlog Items.
The Developers commit to a defined volume of work at the Sprint Planning meeting. Commitment is optional.
Time boxed iterations are mandatory. Time boxed iterations are optional. An event-driven approach is also possible. Different metrics can be used for planning, release and improvement process (combinations of time boxed and event-driven).
In Scrum, Velocity is a parameter in planning and improvement of processes. In Kanban, lead time is a parameter for planning and improvement of processes.