Kanban: Definition and Concrete Application

Kanban is a widely used method, particularly for facilitating the development of an agile approach in project management. It is based on a real-time workflow control system, visually represented on a board, to which team members have access at all times.

What are its advantages and limitations? How can we concretely apply Kanban and what are the pitfalls to be avoided? We take stock with Alexandre, Scrum Master at Wemanity.

1. What is the Kanban method?

A little history…

The Kanban Method first saw the light of day in the late 1950s in Japan, in Toyota factories. The goal of Taiichi Ōno, the engineer who designed the method, was to come up with a planning system that would help teams optimise production capacity. The stakes were high since it was necessary to succeed in moving from a mass production system to just-in-time production, based on customer demand, which minimises the waste of time, resources and energy, without degrading productivity (Lean approach).

Fun fact: the word ‘kanban’, of Japanese origin, means ‘label’, or ‘signal card’.

Who uses the Kanban Method?

Although the Kanban method was initially confined to large industries, it has gradually become democratised as its applications are numerous. Its initial application, which was used to optimise assembly lines, has evolved to work on improving the volume and management of tasks within a team.

The Kanban method is used by a large number of companies concerned with applying lean thinking, especially in the management of IT projects.

The main principles of Kanban

The very concept of Kanban is to allow rapid visual control of the workflow to facilitate on-demand production. Real-time communication and collaboration are simplified because the information around the tasks to be performed is accessible to everyone.

The Kanban Method is based on 4 key principles:

• Start with what you are doing: Kanban is a very versatile tool, which does not require painful implementation. It adapts perfectly to the system in place, makes it possible to identify its limits and to plan for gradual improvements.
• Accept the gradual application of changes: the Kanban philosophy is poles apart from radical change. It is the small changes that bed in over time that will be effective in the long run, and will make it possible to obtain the support of the greatest number of people.
• Respect the processes, roles, responsibilities and titles in place: this is one of the keys to not rushing anyone and gradually eliminating resistance to the changes to come.
• Encourage leadership at all levels: whatever the position and the hierarchical level, any actor in the production chain can have his or her role to play, and bring value thanks to his or her knowledge of the field. Any continuous improvement initiative must therefore be supported.

2. How to use the Kanban Method: 5 good practices

Concretely, Kanban takes the form of a table where each task to be carried out, represented by a post-it, or label, is positioned in a column according to its state of progress. As the task progresses through the workflow, the corresponding label changes column.

To promote a successful implementation of the Kanban Method, it is advisable to rely on a certain number of good practices.

Visualisation 

In the Kanban board, each column represents a step in the workflow (to do, open, in progress, in test phase, finished, etc.). Labels must be changed from column to column in real time as soon as a task progresses to ensure an accurate view of the workflow, which everyone can understand at a glance. This makes it really simple to track the project’s overall progress.

Limiting the tasks being processed 

For each column of the Kanban board, it is possible to set a minimum and maximum number of tasks, so that everyone has something to do, but not to the point of being overwhelmed. By opting for this limit, the team must first complete tasks for more to be added to the table.

For Alexandre, this limitation is a precious tool: ‘The advantage is that the teams are less overloaded, there may be bandwidth left to have time to do test runs, to collaborate on blocking points with others, or to move faster on a specific ticket. It is important to consult your teams to set limits that are acceptable to everyone, and to readjust these limits as constraints change’.

Note: some teams work very well without limits. This option can be of benefit to activate if the teams feel the need to make their work more fluid. 

Flow management 

The pace and fluidity of the progress of tasks in Kanban should be tracked, measured and analysed. Feedback loops should also be organised at regular intervals to encourage the continuous optimisation of the workflow. These retrospectives, coupled with monitoring, make it possible to effectively assess the impact of adjustments and changes made continuously to the workflow.

Alexandre notes two essential tools to manage the workflow with Kanban:

• The cumulative flow: this graph is used to monitor and calculate the average cycle time of a task. This cycle time corresponds to the time taken for a label to go from one end of the process to the other (from ‘to do’ until ‘finished’). Capital to quantify the productivity of a team and make projections on possible delivery dates to the customer.
• Lead time: this corresponds to the time spent at each stage of the workflow. It must be followed up in order to identify bottlenecks, says Alexandre.

Clarifying process standards

Kanban rules must be made explicit to all team members so that they all have the same level of mastery of the system, understand how to deal with the tasks in the board, and are able to suggest areas for improvement.

Identifying opportunities for improvement 

Once the tasks are being processed, the dialogue within the team must remain open so that any blockages or problems can be analysed collectively, and that continuous improvement actions are put in place.

3. Kanban: advantages and disadvantages

Working with the Kanban approach has many advantages:

• The information is accessible to all the actors of the project in real time: the work progresses in full transparency, the communication is fluid, and the risk of duplication decreases.
• The task management is very visual and therefore makes it possible to quickly identify possible bottlenecks in production: the most crowded columns are those that create traffic jams in the workflow.
• The Kanban method makes it possible to be reactive: the very concept is to adapt to the customer’s request, which has to change over time. The adjustment of priorities, reassignment or reorganisation of tasks is therefore facilitated.
• Collaboration within teams is encouraged: with Kanban, in order to move forward, current tasks (TEC) must be completed. In the event of a problem with a TEC, mutual assistance is required to resolve the blocking point as quickly as possible.
• Kanban is flexible: it is easily applicable in most companies and projects (even outside IT projects). From the moment a workflow exists and a team is working on it, the Kanban Method can be put into play. The philosophy of the method is the gradual improvement of wat you already have, rather than a complete revolution.

The Kanban Method is not, however, free of flaws, which must be borne in mind before implementing it:

• It adapts well to projects and productions where deliveries are repetitive, regular and relatively simple (support or maintenance projects for example). On the other hand, it will not be ideal on a more complex project, where requests are irregular, and too frequently go beyond the identified production framework.
• Kanban lacks a strategic vision: the logic of Kanban is to deal with priority tasks first, without the logic of committing to a particular deadline. It is difficult to comment on the availability of a feature on such and such a date, or to easily read the interdependence of several tasks on the board, especially when they do not have the same degree of priority. Even if it is possible to make some projections with the cycle time, they will remain less precise than those of the Scrum method.

4. Key differences from Scrum

Scrum and Kanban overlap on a number of points: both are product-centric approaches to project management, which rely on a compelling visual workflow, and encourage continuous improvement.

The main variations between these two methods concern:

• The roles of each individual: Kanban is based on the existing team organisation, with no predefined roles to introduce. With Scrum, on the other hand, Product Owner and Scrum Master hats must be distributed, which will accompany the development team on the orientation of the work and the management of deadlines. These roles provide an extremely useful structure to guide development and gain an overview of the project.
• The pace of work: the Kanban method does not impose a cadence, everything is done in continuous flow, while in Scrum work cycles are based on sprints. As soon as one cycle is completed, another begins again, which will fulfil new goals.
• Flexibility during the cycle: with Scrum, teams commit at the start of the sprint to complete a set of tasks and achieve a common sprint goal. However, since Kanban operates on a continuous flow system, changes can be made at any time. As soon as a high priority task arrives, it can be processed immediately.
• Rituals: with Scrum, there are a lot of ceremonies (sprint planning, daily, sprint review, retro) while with Kanban, there is nothing mandatory. 

Each method has its advantages as well as its limits, the trick is to choose the one that will be most suited to the specificities of the project and the team working on it. Alexandre therefore advises to ‘switch from one methodology to another according to the needs. The key is that everyone has in mind the defined work plan and the objectives set’. He himself tested this alternation with one of his teams, which had to meet a very ambitious deadline to release a new feature: ‘We decided to stop doing sprints, and switch to the Kanban Method to start working on the highest priority tasks and be able to go much faster. Once the 3 months had passed and the functionality had been implemented, we went back to a classic Scrum methodology.’

If necessary, do not hesitate to mix the strengths of the two methods to derive all the benefits: zoom in on Scrumban, its advantages and its concrete organisation in our article!