The Kanban system for agile software development

The Kanban system was invented in the Japanese automobile industry in the 1940s. It was inspired by the way supermarkets restock shelves according to demand, and Toyota's aim was to reduce stock and improve flow throughout the production system.

In his book "Kanban: Successful Evolutionary Change for Your Technology Business", David Anderson described how to apply Kanban principles to software development. These principles are:

• Start with what is being done now.
• Agree on incremental and evolutionary changes.
• Respect the current process, roles, responsibilities and titles.

Whereas in our previous article 'Kanban vs Scrum: 6 reasons why Kanban might be more suitable' we talked about the advantages of Kanban over Scrum, today we devote our attention entirely to Kanban by going into a little more detail about this system.

 

What is the Kanban system

Kanban is a Just-in-Time (JIT) production process that is based on the philosophy of producing or delivering materials, components or services exactly when they are needed, without stockpiling and minimising waste. In software development, the Kanban system optimises the flow of work in progress ('WiP') according to the capacity of the development team.

Another fundamental pillar of Kanban is that it is a 'pull' system, and not a 'push' system. It eliminates waste by providing what is needed only when it is required and, as a result, creates greater flexibility for the team because no one is doing unnecessary or assumption-based work, while also allowing them to adapt to changes that may occur during the development process.

The core principle of Kanban is to keep the production process as lean and clutter-free as possible. It:

• improves organisation.
• maintains focus.
• increases productivity by maintaining a coherent 'flow' of activities leading to the final product.
• improves prioritisation of tasks, leaving room for agility and the ability to respond quickly to changes.
• promotes collaboration between teams.
• promotes leadership in all roles and at all levels of management.

Kanban is a very visual system because it relies on the use of cards or visual markers to represent activities, tasks or work units. The term 'Kanban' is in fact derived from two Japanese words: 'kan', meaning 'visible' or 'card', and 'ban', meaning 'sign' or 'card'.

A kanban team is assigned the best number of tasks for its capacity. Team members take the tasks one by one and move them as quickly as possible through the various stages of completion (which may vary depending on the project or organisation), from 'to-do' to 'done', before moving on to the next task.

All task cards are placed on the 'to do' column of a Kanban board and then moved through the columns representing the different stages of completion. By visualising the workflow in this way, it becomes clear very quickly if bottlenecks hinder the progress of tasks as they are completed, so that they can be addressed.

The Kanban visualisation of the task backlog and workflow is a form of gamification applied to productivity and teamwork.

 

What does Kanban mean for Agile development?

Source: Opensource

Kanban can be used as a system or framework within the broad umbrella of Agile software development. There is a natural compatibility, as both Agile and Kanban aim to help teams find the optimal balance between discipline and adaptability to meet market demands as effectively as possible.

The implementation of Kanban involves the definition of steps and practices that support the six practices of the method:

1. Visualisation of the workflow
2. Limiting work in progress (WiP)
3. Checking the status of the flow
4. Explicit definition of process guidelines
5. Implementing feedback loops
6. Improve together, develop experimentally

The Kanban board is crucial for most system practices, in particular for work visualisation, work in progress (WIP) restriction and workflow control. The Kanban board can be physical, but is mostly used digitally in software development teams, especially when team members work temporarily or entirely elsewhere.

Work in the form of tasks (user stories in agile development teams) is dragged onto the Kanban board and visually represented by coloured cards. The number of tasks dragged onto the Kanban board must correspond to the capacity of the development team and limit the WIP accordingly.

The boards are divided into columns representing the different stages of task completion. The simplest structure of the Kanban board has only three columns:

• To do
• In progress
• Completed

However, there is often more depending on the nature and complexity of the project at hand.

One of the most important elements for a successful implementation of the Kanban method, defined as the creation of value for the customer/end user, is the understanding of the term "Completed" because it represents the desired end result for activities or tasks in the system.

Kanban's value lies in creating and managing the conditions for an efficient flow of high-quality work. Effectively tracking the progress of tasks is key to maintaining workflow. And to effectively measure the progress of a task, you need to know when it is completed.

Work projects often lack a clear picture of the final status of the project because team members start working on tasks or user stories whose final details are not yet clear.

Still, it is necessary to define what 'completed' means for individual tasks so that their end can be classified in order to avoid the risk of remaining 'in progress' indefinitely. To avoid this, it is necessary to establish criteria for the definition of 'completed' for both individual tasks and processes.

 

Limiting unfinished work and queues

Limiting work-in-process (WiP) means setting an upper limit for the number of elements being worked on. This limit is called the work-in-process limit or WiP limit. 

Source: Kanbanize

In this image, developers have a maximum of 4 elements they can work on at a time. Maximum. If their column reaches 4 elements, they can no longer drag and drop them. This has two consequences.

Firstly, it encourages people to complete their work rather than start more work. Work started that is not completed carries risks. How happy will your customers be if you fail to deliver the software as planned? Why did you start working on all those great ideas but not complete them?

The second consequence of work-in-process limitation is that bottlenecks become visible. If a process step starts work that cannot be completed, people perceive this immediately. This is because the next process step will not be able to extract elements.

 

Monitoring and improving the flow

Noticing bottlenecks can be unpleasant. But at least you know where the main problems are in the process. And Kanban encourages you to improve the flow by eliminating the bottleneck. A consistent flow enables you to deliver more reliably, which is good for everyone involved, including the developers.

To monitor the flow, record the time when a card enters a stage in the process. And the time when the process step is completed. In this way, you know how much time the card spends in each phase and in each queue between phases.

Based on data, metrics can be created to improve the flow. Common metrics include:

1. Cycle time: the time it takes for a paper to go from when a team starts working on it (i.e. development) to when it is delivered (i.e. release). Improving this metric can help reduce time-to-market.
2. Throughput: the number of cards that pass through the system in a given time period. Improving this metric can help improve the performance of the development organisation.

A common way to get an overview of how many cards are in a given process step over time is to use a cumulative flow chart. Ideally, the number of cards in each phase remains roughly the same over time, with the exception of the last card. The number of delivered cards should increase. If the graph deviates from this value, a bottleneck may have occurred.

 

Working together efficiently

Kanban metrics are a powerful tool for analysing and improving work. But they are useless without the people doing the work. All people involved in the process steps must be open to the transparency that Kanban creates.

Individuals should collaborate constructively to eliminate bottlenecks, rather than blaming individuals. Regularly review the current state. Are there bottlenecks? Is there too much or too little work available for a particular process step? Is productivity sufficient? Are there other sources of dissatisfaction? What needs to be improved?

Arrange experiments to try out small changes to the system. Make the changes. Check afterwards whether the experiments worked as planned. In order to be able to implement changes, management support is often essential.

 

Conclusion

The implementation of the Kanban system in Agile software development has proven to offer numerous advantages. The combination of visualisation, limitation of unfinished work and pull approach has led to an overall improvement in efficiency, productivity and quality of work done. Teams adopting the Kanban system enjoy greater agility, adaptability and success in the realisation of software projects.

 

You might be interested in:

"The DevInterface development process"

"The importance of testing in Agile development"

"Scrum sprinting: execution, revision and retrospective"

"Scrum: planning a sprint"

"Team augmentation: what it is and why it is used"

"Outsourcing vs offshoring"