AGILE METHODE: 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) [59]. 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 [60]:

Team level
Mapping a project with the Kanban board can help to better understand the workflow. It makes it easier to organise and manage the work and allows teams and project staff to keep an overview of each task.

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

The Kanban project map¶

Principles and practices¶

In Kanban there are four principles and six practices [61].

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.

Achievement of these objectives prevents wastage and eliminates defects. Wastage in this sense refers to work which doesn't enhance the product's value, overwork of personnel and machines and process irregularities. Surplus production is also wastage and should be avoided. It generates waste because the manufactured products which cannot be shipped take up storage space and tie up capital that the company then doesn't have available for other – and possibly more important – projects.

Kanban is essentially a method for the procurement and supply of the necessary materials for each stage of production. Kanban cards contain all information that is needed to obtain the required production items. They move between the supplier and customer processes.

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¶

Kanban was developed for production processes and inventory logistics, which means it isn't suitable in its purest form for IT projects. Instead, it is combined with lean production, lean development and the theory of constraints.

Lean production is an aspect of lean management. It focuses on the cost-effective and time-efficient use of factors of production (people, machines etc.).

Lean development applies the lean production and lean management concepts to software development.

Theory of constraints is a management paradigm that views any system as being prevented from achieving more of its goals by a very small number of constraints. Improvements can only be made by identifying a constraint and restructuring the rest of the organisation around it.

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, nevertheless, a queue arises because problems occur at one station, for example while testing task, then those colleagues from other stations can join in and work together on a solution, given that they themselves cannot draw new tasks due to the limited number of entries in their station. So, for example, the developers could work together with the tester on possible solutions. The advantage of a cross-functional team is that developers get more insight into testing - and vice versa. So 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 [62].

Visualising the workflow¶

The Kanban board¶

The workflow is made visible to everyone involved in it on a Kanban board (e.g. a large whiteboard, or an electronic board) [63].

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). Often a combination of methods is used involving the Kanban board being "monitored" by a camera for changes.

The tasks or requirements can be formulated as user stories, features, use cases etc.

A user story describes what a user does or needs to do with the system in his or her job function.

A feature is a function (e.g. printout) in a software application.

Use cases describe the interaction between a the user and system to achieve a goal.

A use case chart in Unified Modeling Language can also be useful.

Kanban teams use a pull system to optimise workflow from right to left across the Kanban board. The team pulls from the left when they have available capacity.

As a result, the cards/ Post-it notes on the Kanban board move from left to right until each task is completed. There are no specific rules on what the Kanban board has to look like, so it is simply structured according to individual team requirements.

Limiting work in progress (WIP)¶

Dealing with constraints¶

The Kanban board offers transparency for the entire team and allows a quick identification of constraints.

One example of an implementation constraint is when the design features can't all be implemented at the same speed (see Fig. 14). This makes the workflow uneven. Limiting the amount of design work in progress (e.g. limit is four) can remedy the situation. Limiting WIP in the column "design" means that only four cards can be included in that column on the Kanban board (in this example). This ensures that work in progress can be completed before new work is started. After a while, the tasks are processed and the bottleneck resolves itself.

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 which tasks are being completed.

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

• Cycle time (horizontal distance between the lines)
• Work-in-progress (vertical distance between the lines)
• Throughput (slope of the graph)

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.

Differences¶