Kanban for Software Development

What is Kanban Software Development?

Kanban is a lightweight software development framework with industrial origins. It is a pull system which relies on a strong visualization tool, the Kanban board. The Kanban board displays the workflow and the status of the items in it and helps the discovery of potential bottlenecks.

The history of Kanban as a software development framework started in the early 2000s: a Microsoft development unit reengineered its processes and identified strong similarities with Kanban. Kanban’s strength lies in its simplicity, universal applicability and high flexibility. Since there is no institution behind Kanban to provide elaborate rules, implementing a good Kanban flow largely depends on the capabilities of a team. There are, however, popular techniques worth considering.

The Origins of Kanban

Kanban was one of the key inventions of the post-war Japanese industry, making Japan a developed economy. It was first introduced by Toyota for managing their supply chain. Their main goal was to minimize the stock level yet keep the production process safe. The concept relies on bins (storing parts, materials) and cards (or ‘visual sign’, which is kanban in Japanese) and adopts the stocking model of supermarkets. Supermarkets only put as many goods on their shelves as many they think their customers will need. With all these ingredients, the industrial Kanban process is the following:

• When the level of stock in the bin of the workshop gets critically low, they send a card to the warehouse. The card contains the major information of the bin, what type of parts are in there and in what quantity.
• The warehouse keeps a similar bin prepared for hand-over, so when they receive the card, they can immediately replace the empty bin. Then, they send their own card to the supplier for a new bin.
• The supplier also has a bin prepared ready for dispatch. They send it to the warehouse and initiate the production process.

Kanban is a pull process

The emptiness of the bin, just like vacuum, pulls the supplies through the supply chain. The benefits are the following:

• Every procedural step is backed up, thus the production will always have enough supplies.
• Stock level is low. There is no point in keeping large stocks when supply bins can be replenished by a Kanban card on short notice. Everything arrives just in time.
• There is no production for stock. Production only starts when it is requested.

Translating this to the language of dollars, participants of the process can save a lot of money on financing and storing supplies, while keeping the production process efficient.

On the other hand, the suppliers need to be agile, since demand for supplies vary.

How does Kanban work for Software Development?

Kanban is as an efficient tool for matching the amount of work in progress to a team’s capacity. In the context of software development, Kanban is the same pull process as it is in industrial production, however, this time it is team capacity that ‘pulls’ the process.

Let’s look at it through a typical (though simplified) example, a maintenance team’s work. This time, cards represent reported errors, and instead of warehouses and suppliers, we have statuses and stages in the workflow, e.g.:

• open (error reported),
• development (a developer is working on the item),
• testing (a tester is working on the item),
• done (fixed, not present in production anymore).

Out of these, development and testing are stages of work in progress (abbreviated as WIP). The idea of Kanban is that every team has a certain capacity for a given workflow stage, e.g. a team of 3 developers cannot efficiently work on 15 items. Ideally, they should focus on 3 at a time, so let’s suppose our team chooses to limit the amount of work in progress to 3 error tickets. For development, WIP = 3. Applying the same logic for 2 testers, let’s set a limit for testing WIP = 2.

In the industrial example, we had bins, now we have WIP limits. When the WIP is under the limit, it ‘pulls’ a ticket from a previous stage, making room for pulling another ticket into that stage.

The Kanban Board

Kanban teams perform their work governed by a Kanban board. The team places the Kanban cards on the board which visualizes the workflow. The WIP limits ensure focus and optimize the flow. The simplest Kanban board would have only 3 columns: to do, in progress and done. In practice, Kanban boards can grow fairly complex since they are able to model complex workflows.

The initial column contains all known items, thus when Kanban is used for product development, it represents the product backlog.

Let’s quickly draw the Kanban board for our example, thus, we need 4 statuses (open, development, testing, done) and 2 WIP limits: development is 3, testing is 2. Let’s add some cards, too!

We can instantly see that testing has an empty space. This means that a card can be pulled from development to testing, and as a consequence, a card can be pulled from open to development.

Kanban boards may have physical and digital versions. A digital Kanban board has multiple advantages over the physical one, for instance, it is easy to share with people, use it with distributed teams working at different locations, connect it with other systems and processes. The advantage of the physical board is its strong visual power when placed on the wall of an open space team office.

The Kanban board became a very popular tool for visualizing processes. Scrum teams often manage their sprint backlog on a Kanban board and essentially any workflow can be visualized on it, even if the process behind is not Kanban. The board suits well both pull and push processes, which is very advantageous since most delivery processes follow the push model.

More about the Kanban board >>>

Managing the Kanban Workflow

As a pull system, Kanban is almost self-managing. However, teams need to consider certain factors.

1. Setting up the WIP limits is not as simple as 1 person = 1 item in progress. When working as developers, sometimes we have to wait for the result of an operation or another person’s action while an item is genuinely in progress. For instance, a background process is running for long hours, or we need help from a system administrator. In contrast, some items may require the contribution of multiple specialists in parallel. As with most processes in agile, experience (inspection and adaptation) helps to find the optimal setup.
2. Choosing which cards are the best candidates for the pull is not determined by Kanban. It is resulting from common sense human decisions, thus someone must take responsibility for it.
3. Teams should not have idle people in a process. So, what happens when there is no pull and the stage is full of items which could be pulled? The solution is swarming: team members help cleaning the bottlenecks. Once they manage to clear the obstacles, they can return to ‘business as usual’.

These factors lead us to consider roles in Kanban.

Roles in Kanban

Kanban has no explicitly defined roles. However, there are some typical responsibilities and related naming conventions.

As mentioned above, someone has to maintain and order the list the team is pulling the cards from, and elicit the items, just like a product owner. This person is the Service Request Manager.

The team has to identify its WIP limits, decide when to do swarming and in general, organize its own work. The Service Delivery Manager is responsible for facilitating the work of the team.

Since Kanban is an agile framework, it is nice to have an agile coach who can help the team to improve its practices.

Metrics in Kanban

As in other workflows, throughput is a key measurement of efficiency. The throughput defines the amount of value delivered over a period of time. While measuring time is straightforward, measuring the amount of value delivered raises questions. The simplest way is to count the number of cards, a more elaborate approach is to estimate the cards based on complexity, anticipated days, etc.

The most important metric which is peculiar to Kanban is cycle time. Cycle time tells the average work in progress time between taking an item into the process and delivering it at the end. Kanban teams are working on increasing their throughput and decreasing their cycle time.

A digital Kanban tool can provide further interesting metrics, such as variance, average waiting time in a stage, longest and shortest waiting times, etc. These can help in identifying the strengths and the weaknesses of the process in place.

Events in Kanban

Even though there are no formal events required, most of the typical agile meetings make sense:

• Daily meeting is highly beneficial if team members work together;
• Backlog refinement is a good idea if the team works on delivering a product;
• Though there are no iterations, a regular retrospective is the ideal way to improve team practices;
• Though there is no iteration planning, it is good to have an overview of the anticipated deliverables;
• A review is a great way to share our knowledge and experience when we work on product development.

Depending on the context of the work, further events may address strategy, evaluating SLAs, etc.

The Benefits of Kanban

As demonstrated above, Kanban is very simple, easy to understand, yet has enormous power in organizing a team’s work, optimizing its flow, improving its transparency. Kanban not only encourages but enforces the ‘stop starting, start finishing‘ principle. The transition to Kanban typically results in significant increase of the team’s throughput.

Since Kanban is not managed in iterations, feedback from the customer is immediate. This makes continuous improvement really continuous.

Kanban and Scrum

The two most popular agile frameworks are Kanban and Scrum. Even though Scrum is far more popular than any other agile frameworks, Kanban and its mutations (e.g. Scrumban) are used by roughly 10-15% of agile teams. The reason of Kanban’s popularity is in its simplicity and universality. The comparison of Scrum and Kanban reveals which are the situations when Kanban outperforms Scrum.

• Scrum delivers increments in sprints lasting up to a month. This way Scrum couples otherwise potentially independent backlog items into a single increment. Items should not change during the sprint and can only be released when the sprint ends.
• Kanban delivers its cards independently form each other. Change to one card does not impact others. The service request manager can decide to release “done” items anytime.

This comparison clarifies that Kanban for software development is the right choice when backlog items are independent and their quick delivery matters. With Kanban, continuous delivery becomes truly continuous, every new piece of the solution can go live independently from the rest. When a Scrum team needs to move to continuous delivery, a merged version of Scrum and Kanban is a great choice.