What is Kanban?

Kanban is a concept that originated from the Japanese manufacturing sector during the late 1940s. The literal meaning of Kanban in Japanese is “signal” or “flag.”  Taiichi Ohno, the “father” of Kanban, developed the concept because he realized a rather simple principle: no company should start producing any product until one or more customers at the end of the supply chain indicated they needed another product.

It enabled the “just-in-time’ manufacturing approach to become the standard it is today almost everywhere and worked so well that it was soon adopted outside of manufacturing specially in IT too.

What is the role of Kanban in Software Development?

Kanban is relatively recent approach to software development, which aims to create a development pipeline that continuously delivers constant value. It is a concept originating from the manufacturing sector but is now widely used in many other sectors and disciplines. It is a system for workflow management that provides visual signals to communicate information. Humans process visual information more than 5,000 times quicker than they process information in text; hence, it contributes to efficient operations and optimized process flows.

Kanban techniques can be successfully used in both IT and IT Service Management to optimize how day-to-day tasks are planned and executed. Kanban can also be applied to other disciplines that are part of the IT lifecycle, including project management and procurement. Using Kanban in all parts of a business is now rapidly becoming the norm, as organizations strive for efficiency to remain economically viable and competitive in their marketplaces. It is an essential part of any implementation of Lean or Agile and helps collaboration between different teams.

Concepts of Kanban:

Kanban can be described using four simple concepts:

• Visualize work

Kanban creates a visual workflow or process model. This visual model can be used to observe the flow of work and products through the Kanban system. This includes highlighting any causes of blocked progress, such as bottlenecks creating a demand greater than capacity, queues of work and teams or individuals failing to move work through the system. Making these visible using Kanban soon drives increased communications and improved collaboration between teams.

• Limit work-in-progress

Using Kanban to limit the amount of work in progress (where work on a product has started but hasn’t yet been completed) can reduce the time it requires to move through the workflow. Having a smaller number of work-in-progress items where Kanban signals trigger production increases the visibility of each item, and their progress can be given enough attention. Re-prioritization delays are thus avoided.

• Focus on flow

Using Kanban to limit work-in-progress and to visualize work helps to maintain a focus on delivering outputs with a constant flow of work through the system. It enables the simple collection of metrics that can be used to analyze the flow and provide an early warning of future problems.

• Continuous improvement

Using Kanban underpins a culture of continuous improvement. Visualizing and measuring flow, quality of outputs, throughput and lead times using Kanban helps teams and individuals to measure and improve their effectiveness.

What are Kanban boards?

A Kanban board is a tool within Kanban, which provides a visual representation of how work in a workflow is progressing to completion. Teams use Kanban boards to manage workflows collectively, providing a visual image of tasks and their status, but individuals can also use Kanban boards. A Kanban board has a number of columns, each representing a stage in the overall workflow or process. In a simple Kanban board, these stages could be “To-do,” “In-progress” and “Completed.” It is good practice to keep Kanban boards as simple as possible, as complex boards are difficult to understand. Kanban boards have the following features:

Visibility of work

A visual card represents each unique work task and the card includes the name of the task. The card is moved from left to right on the Kanban board as a task progresses through the stages. If the Kanban’s board is a physical board, then the normal practice is to use a sticker for each task. Moving a sticker on the Kanban board is a visual signal of progress. Different colored stickers can be used on the Kanban board to differentiate between types of task, which can also be achieved with different rows on the Kanban board. Using these visual signals provides easily understood communications.

Limiting work-in-progress

Many uses of Kanban boards specify a limit of how many cards can be in a column, as a means to limit work-in-progress. Before another card can be moved into the column, the team must work together to move one of the existing cards to the next column. Using the Kanban board in this manner can help increase the flow of work, as tasks are worked and completed to make way for others. A Kanban’s board will also identify bottlenecks where there is a queue of tasks waiting to be moved to the next column. If the limit is often reached, then this is a signal of an excessive amount of committed work. It is not a solution just to create an extra Kanban board.

Commitment point

Once a task has been entered on the Kanban board, it should be moved through the workflow as quickly as possible. If work-in-progress is limited, then there will probably be a backlog of tasks waiting to be added to the Kanban board. The commitment point is the moment in time when the team “commits” to completing the work by entering the task on the Kanban board.

Delivery point

This is where the work has been completed to the customer’s satisfaction and the task can be removed from the Kanban board.

Digital Kanban boards

Physical Kanban boards should be used where possible, as the act of manually updating the Kanban board is the best method for collaboration among individuals. Where this is not possible, due to remotely located individuals and teams, then a digital Kanban board can be used. These digital boards can be easily shared and updated across time zones and locations, allowing many of the benefits of Kanban to be realized. Tools are available that support multiple-linked Kanban boards, with tracking, audit trails and automatic notifications of changes made on the Kanban board.

What are the benefits of using Kanban?

Using Kanban can provide significant benefits in workflows and processes to produce outputs. Effective use of Kanban for workflow and process management can:

• Reduce waste
• Deliver resolutions to issues faster
• Improve communication between teams
• Facilitate increased output
• Improve product quality
• Improve process efficiencies
• Identify bottlenecks that slow production
• Support closer teamworking
• Reduce stress in all involved in the workflow

The shared visualization of a process using Kanban boards drives collaboration between teams as they can actively see work moving through the system towards final delivery. They can also easily identify tasks that are not being completed as planned, so they can work together to address any issues. Kanban boards also provide managers with an easily understood “birds-eye” view of workload and how work is progressing. The Kanban boards can help managers to understand the impact unplanned work has on their teams, so they can set realistic priorities and manage expectations with senior staff.

How Kanban can improve team performance?

The updating of Kanban boards of the status of tasks is best done as a team activity rather than individuals working alone. This approach enables team members to know each other, and to share openly progress and blockage of progress using the Kanban board. The Kanban board supports collective responsibility for moving tasks through the workflow to completion. Blocked tasks are visible to all, which prevents people from keeping issues to themselves. Effective implementations of Kanban give rise to a supportive culture where people help each other to resolve issues. All of these behavioral and cultural impacts from using Kanban boards will improve the performance of teams as well as individuals.

Scrum or Kanban?

Many software development teams use both Scrum and Kanban are techniques. The Scrum approach uses a technique to complete software developments during sprints of standard time intervals. Each sprint will include the delivery of several different pieces of work. The sprint has defined start and end dates. Any work not completed at the end of a sprint is carried forward into the product backlog. The end date is not delayed to accommodate completing it.

This contrasts with the Kanban software-development approach, where there is no concept of standard time intervals of development cycles or fixed end dates. In this Kanban approach, the development of a piece of work continues until it is completed and delivered.

Software development teams that use Scrum often do use a form of Kanban board to provide visual illustrations of the sprint contents and status; however, this Kanban board is cleared at the end of each sprint. The Kanban board is then populated with the new work agreed for completion during the next sprint. A Kanban board used in the Scrum technique also has fixed dates for completion, whereas a true Kanban board has no dates associated with the columns.

Many software development teams now use a combination of Scrum and Kanban. Scrum is used for planned work to deliver new functionality and non-urgent fixes. Kanban is used to develop any urgent fixes that must be delivered before the planned end date of the sprint.

Software Development Approaches Before Kanban

How software is developed has changed much from the past.  Initially, developers wrote code they thought users wanted and shipped it. This approach delivered small amounts of functionality quickly but wasn’t robust enough for large-scale developments.

The answer was to introduce formal techniques, such as Structured Systems Analysis and Design Method, (SSADM). This involved several different teams: business analysts to capture user requirements; systems analysts to develop specifications, designs and models; programmers to produce code; and testers to check it all worked according to specifications. The time required for all these tasks varied for each delivery and was measured in months and sometimes years!

By the time the new code was deployed, users often wanted new and/or different software. This approach was sometimes known as “waterfall,” as progress flowed in one direction in sequential stages from analysis to deployment. The best practices for IT service management (ITSM) were designed to align this approach with software development.

User frustration with extended delivery times led to the concept of Rapid Application Development (RAD). This allowed code to be developed in parallel but lost much of the controls from SSADM, and soon resulted in a reputation for many companies of delivering bad code quickly! A new approach was needed, which provided the speed of delivery, but with sufficient controls to deliver working software, which led to Scrum.

Scrum concentrates on separating work into small developments that can be completed in short, 2–4 week, fixed-length development cycles, known as “sprints.” The code is released to users in a regular “heartbeat.” Functionality is delivered incrementally during a series of sprints.

The developers are organized into small teams of 3–9 multi-skilled members, and perform the design, coding and testing themselves. Each team also has a Scrum Master who manages it and a Product Owner who gathers requirements and prioritizes the work. Each team has a daily 15-minute “standing” meeting with everyone present, known as a “Scrum,” where progress is tracked, and plans are updated.

At the end of each sprint, the entire team reviews what has been finished or “done,” and releases it for deployment. The Scrum approach results in much happier users who receive new and working items delivered much faster than with waterfall.

The Problem Kanban Fixes

Scrum is a great improvement on waterfall, but there are problems. How do you address issues that can’t wait until the next sprint cycle, such as urgent fixes or urgently required new functionality? Scrum provides only one option: to interrupt the sprint and work on urgent matters. This often requires a technique called “swarming.”

Some members of the team are pulled from their current work to focus on the urgent item. It might be completed sooner than waiting for the next sprint, but, meanwhile, their previous project/task is now at risk of not being finished by the end of the current sprint.

Hence, using Scrum and swarming can be a headache if urgent fixes must be regularly developed because of the deployment of flaky code, or, as is increasingly the case in today’s digital age, the business regularly demands urgent changes to remain competitive. Now, however, Kanban is a new concept for software development.

How Is Kanban Applied to Software Development?

The principal distinguishing feature of Kanban’s application for software development is the development of each item is started as soon as a team member is available, and deployed as soon as it’s completed. Unlike Scrum, the development cycles are not fixed.

With Kanban, multi-skilled developers can still design, code and test. Usually, just one person works on each individual development, but small teams can still work on it together. Who will work on delivering each requirement is decided at the daily (or more frequent) standing meetings, when new work items are allocated?

The use of Kanban limits the size of each individual development so it can be delivered quickly, ideally hours or days rather than weeks. Large segments of work are condensed into smaller components with incremental delivery of functionality.

Each team or individual works on just the assigned item until it’s completed and deployed. Waiting until other items are finished is not necessary. The concept may seem similar to swarming, but Kanban eliminates the urgency, and team members don’t have to be pulled from their current work.

Making Work Visual

Kanban software development uses a visual management technique known as a Kanban Board. It uses cards to show the status of each individual development and its progress.

A Kanban board has several columns, each representing a stage in the development workflow, such as work waiting to be started, work in progress and work completed. A visual card or sticker represents each unique development.

The card or sticker includes the name of the development and who has been assigned to work on it. The card is moved from left to right on the Kanban board as each unique development progresses through the stages. All members of the development unit use the same board and gather around it at their daily standing meetings.

Advantages of Using Kanban for Software Development

New functionality and fixes are delivered with a much shorter lead-time. Kanban is a fundamental component of the technique known as continuous delivery. Instead of releasing a group of small changes at regular, fixed intervals, each change is released as soon as it’s done. This can be as often as every minute if that’s what your business requires. It seems counterintuitive, but the risks to the business actually decrease if many small changes are regularly and individually deployed instead of grouping them.

Using Kanban eliminates the need to estimate how much time each development will require for completion. Using Scrum can result in large overhead costs, and If Scrum is used incorrectly, then users will become annoyed they didn’t receive what was promised or developers will have nothing to do.

Kanban essentially eliminates those two possibilities. If each requirement is kept small, then it should be provided relatively quickly. Development cycle times of single minutes can be achieved with Kanban.

Using a Kanban board stops developers from accepting multiple items, which results in work overload – a phenomenon known as “over promised, under delivered.” The number of development items in progress can never exceed the number of developers available.

Hence, no work is started unless there is the capacity for it. Users won’t be disappointed, and by keeping developers focused on one small item at a time, the risk of delivering bad code is reduced. Separating work into very small items increases the flexibility of your development team, as its members aren’t spending weeks working on the same item.

Conclusion

Using both Kanban and Scrum in the same development team is unlikely to succeed. Scrum relies on the fixed development cycle; Kanban has no such concept. Scrum can use Kanban boards to visualize the workflow, but that’s not the correct approach for using Kanban software development.

If the development team says it is using Kanban, then it is doing more than just using a Kanban board to manage the sprints and backlog. If usage of Kanban for software development is intended to start, then it’s best to introduce it to one team at a time.