What is Kanban and how is it different to Scrum?
Introduction to Kanban
Kanban is a Japanese term meaning “Visual Cards” or sign (Kan means “visual” and ban means “card”). It is a technique that emerged in the late 1940’s from Toyota’s assembly line for vehicles. Toyota drew inspiration for the idea by observing how supermarkets stocked their shelves. Supermarkets stock just enough product to meet consumer demand. This practice optimises the flow between storage areas at the back of the supermarket and the consumer. This helps match inventory levels with consumer demand pattern thereby creating significant efficiencies in inventory management and yet ensure there is always sufficient stock when the consumer needs it.
Kanban is a lean tool intended to reduce the idle time in a production process. The main idea behind Kanban systems is to deliver what is needed in the process at the right time when it is needed (neither early nor late and Just in Time). This is achieved through the visual cards system. Despite software development being a creative activity rather than a mechanical one, the underlying philosophy of reducing idle time is relevant and applicable. It has subsequently been increasingly adopted in Software Development where work items and their states are represented visually on a Kanban board and displayed to the whole team.
Software development teams can leverage the same JIT (Just in time) principles by matching the amount of work in progress (WIP) to the team’s capacity. This delivers the benefits of flexible planning options, faster output, clearer focus and transparency throughout the development cycle.
It is useful to imagine the software development process as a pipeline (see figure below). Requests for software features (requirements) enter the pipeline at one end and working software comes out at the other end. Inside the pipeline, various activities such as analysis, development and testing are carried out to transform requirements to working software.
Software development pipeline
If the activities inside the pipeline are carried out well then, the flow (working software) will be smooth and continuous. However, if there is a bottleneck inside the pipeline then flow will be turbulent and discontinuous. The throughput of the pipeline as a whole will be restricted to the throughput of the bottleneck.
The Kanban Board
Let us peek inside the pipeline to understand what happens and represent the process visually on a Kanban board. Let us assume that the main activities or stages within the overall process (represented by the pipeline) are Analysis, Design, Development and Testing. We can then set up six channels or swim lanes to show the backlog or requirements, process stages and completed software features as shown in the Kanban board picture below.
The Kanban Board
The Kanban board makes the status of work items, visible to the entire team, in an easy to interpret, visual manner
There are 20 requirements or backlog items, numbered 1 to 20 as shown on the board. Items 1 and 2 have been completed and are in the “Done” stage. Work on Items 16,17,18, 19 and 20 has not yet been started. Other items are at various stages of work in progress (WIP). New feature requests may be added to the backlog column at any time
All items need to go through the stages of analysis, design, development and testing to the “done” or completed software feature
It is possible for an item to be demoted to any previous stage if it doesn’t meet the “done criteria” for that stage
The numbers (3), (3), (5) etc. under each of the WIP stages of Analysis, Design, etc. designate the total capacity available at any time for that stage. For example, while Development stage has a capacity to work on five items at any given time, the Testing stage has a capacity to process only two items.
Work items move from stage to stage through a “Pull action”. Work is never pushed from stage to stage. This is fundamental to the principles of Kanban.
It is possible to create sub-lanes within each of the main swim lane to regulate smoother flow. As an example, it may benefit to create 3 stages called Pending, WIP and Completed within each of the Analysis, Design, Development and Testing stages. This will show the status of work items on finer detail. In the example of the board above, work item 3 is in the pending stage of testing, implying a Tester may work on it soon.
Policies are designed and must be complied with by everyone in the team to regulate workflow and maximize throughput. For example, a policy might state that no more than 3 items can be in the WIP for any stage. This means that Designers may not pull item #15 from the Analysis stage and start work on it.
Kanban boards may be set up manually or electronically through several online tools.
Advantages of using Kanban
The many advantages of using Kanban as a lean system to managing work include;
Flexibility (No prescribed phase durations and constant reassessment of priorities is possible)
Continuous delivery (Delivers small features / items to customers and users continuously, allows teams to synchronize future iterations and deliver exactly what the customer needs)
Reduction of wasted effort and time
Increased productivity and efficiency
Increased focus
Disadvantages of Kanban
Some disadvantages of Kanban are listed below;
Not well suited to large lot sizes (requirements)
Not well suited to product variations
Not well suited to projects that are stop / start in nature
Differences between Kanban and Scrum
Both Kanban and Scrum are agile approaches for software development (iterative and continuous delivery) and both conform to the Agile values and principles. The three key differences between them are;
Scheduling and Iteration
Scrum places a heavy emphasis on scheduling of work in a time-boxed interval called Sprint (usually 2-4 weeks in duration). Work needs to be estimated (in size or effort) by the team and the amount of work taken into the sprint depends on the team’s capacity and the estimated size of user stories.
Work is not scheduled in a time perspective in Kanban. The emphasis is more on continuous improvement in an evolutionary manner, good flow of work between stages, reduction of WIP and increasing throughput. Because work is not scheduled it is not necessary to estimate the size of work items other than to match maximum capacity.
Team roles and responsibilities
In Scrum teams, there are three roles: Product Owner, Scrum Master and Developer. Teams are expected to be cross-functional and self-organizing.
In Kanban, there are no set or prescribed roles. Large and complex projects using Kanban may have a Project Manager or Lead who may act in a supervisory responsibility to enforce policies. A Kanban team is usually not cross-functional and consists of specialists and generalists working on different aspects of the same project on the Kanban board.
Visual representation of work (Scum Board and Kanban Board)
The Scrum board and Kanban boards are quite different. In a Scrum board work is illustrated to reflect time periods in the workflow beginning with the Sprint backlog and ending with the teams’ definition of done over the duration of the sprint. After the conclusion of the Sprint the board is cleared and prepared for the next sprint with a new set of sprint backlog and any backlog items not done from the previous sprint.
In Kanban boards, columns are set up to show work states with maximum capacity available for each state. There is no timeline in a Kanban board. As such, there is no reason to reset the Kanban board. The Kanban board continues to function until the project exists and new user stories / features are added in the first column (Backlog).
Summary
Kanban is a pull-based system that relies on managing work items in a visual manner across work states. The main emphasis of Kanban is to reduce waste, deliver continuously and achieve high productivity. Constraints often impair these objectives and the system must focus on removing these constraints and bottlenecks. They are usually done by designing and implementing proper policies to achieve smooth flow of work. While both Scrum and Kanban share many similarities the key differences between the two approaches are in scheduling, team roles and the board. It is not possible to isolate different software project types suited for Scrum and Kanban. Teams can only try one or the other, learn and adapt. Both are powerful approaches compared to the traditional or waterfall approach.
