What Is Kanban? A Capable First Step Into Agile World

When it comes to Agile methodologies, Kanban is a curious case. Like Lean, Kanban is not a software development or project management methodology but represents a management approach to an efficient process. The Kanban method provides a five-point action outline, which seeks to address some of the pain points of a typical software development scenario.  

What Is Kanban?

The Philosophy derives its origins from Toyota Production System, which sought to eliminate seven wastes or unnecessary steps from the production processes in Toyota. As part of adopting lean manufacturing principles for car production, Toyota applied Kanban as an instrument to enable the Just-In-Time (JIT) approach to reduce one of the wastes, the excess inventory. The literal meaning of the Japanese term Kanban is a signal card. Let us first try to understand what exactly Kanban did for Toyota. Then we will proceed to see how David Anderson adopted Kanban for software development and defined the approach framework as it is known today. 

How Kanban Is Implemented?

Toyota implemented Kanban by using multiple shelves or storages for various parts required to manufacture a Car. A Kanban, or the signal card, was used to tag each part or item. As the shop floor used the items, they sent their Kanban cards to the storage. The replenishment of the stock on shelves happened based on collected Kanban cards. Then, Toyota sent the Kanban cards from the warehouse to the suppliers, who restocked the storage shelves. This way, Toyota eliminated the cost of maintaining excess inventories. 

Kanban cards implemented a PULL system for doing work. Based on these cards, the workers were able to understand what work they needed to do. The earlier practice had managers deciding the work to be done by workers by drawing up complex production schedules, and workers were required to follow that schedule. This approach had three problems associated with it; 

1. The bottlenecks for efficiency were not easily identifiable. 
2. There was no way to manage the variability of the rate of incoming work.  
3. There was no predictability for process completion. 

Though software development is different from manufacturing, software development teams observed the same problems with their projects. The tendency to plan upfront and then try to comply with that plan did not allow process inefficiencies to surface sufficiently early. Since the managerial preferences were to adopt tight controls over the team’s work, many process inefficiencies crept in, increasing the cycle time. 

Quite often, the rate of incoming work is not consistent or predictable. Software development work is notorious for the burn out it causes to professionals due to such uncertainty. Apart from causing burn out, this uncertainty led to decreased quality and a lot of work-in-process or incomplete work. The unfinished work in software development is like excessive inventory. Such a high level of Work-In-Process items and unpredictable rate of incoming work make it difficult to predict precisely when the job is going to complete.  

Kanban Principles 

David Anderson used fundamental principles of Kanban from manufacturing processes and applied them to software development as a means to bring about a change in how software development functioned traditionally. Kanban is not typically used as a standalone method but complements other agile software development methods. David Anderson documented the processes he used in a Book named “Kanban: Successful Evolutionary Change for your technology business”. The book identifies four principles to be used as the basis for Kanban implementation to transform current software development practices to more efficient ones, capable of providing solutions to the three issues we discussed earlier. These five principles are; 

1. Start with what you do now 
2. Agree to pursue incremental, evolutionary changes 
3. Respect the current processes, roles, responsibilities and titles 
4. Leadership at all levels   

Kanban is an evolutionary change approach. It does not recommend a sweeping change, which upsets the settled rhythm of the work in one single go. Instead, it suggests making small changes in an incremental fashion. It does not enforce a new set of roles, processes, or responsibilities like many other agile methods do. Instead, it recommends continuing to do what you do now, modify it slightly to implement pull, and then keep on improving the process using a transparent, collaborative method to review and organize work. To quote David Anderson about the state of affairs after a Kanban implementation, 

“Nothing else in their world should have changed. Job descriptions are the same. Activities are the same. Handoffs are the same. Artifacts are the same. Their process hasn’t changed other than you are asking them to accept a WIP Limit and to pull work rather than receive it in a push fashion.” 

This approach acknowledges the fact that the definition of best practice depends on the context. Furthermore, Kanban gives the flexibility to adapt the principles according to context, thus increasing flexibility and effectiveness.  

Kanban Practices 

Six practices help organizations and software development teams implement Kanban. These six practices are; 

1. Visualize Workflow 
2. Limit WIP 
3. Manage Flow 
4. Make Process Policies Explicit 
5. Implement Feedback Loops 
6. Improve Collaboratively, Evolve Experimentally 

Let us look at each of these practices one by one and see how they are implemented in real life. 

Visualize Workflow 

The visualization for Kanban happens through what has come to be known as Kanban Boards after Tom and Mary Poppendieck coined the term in their book on Lean software development. Though technically this is an incorrect term, we will keep using it for our lessons as it has been adopted widely. The board has various swim lanes, which are vertical columns representing multiple stages of development. Kanban cards are placed in one of the swim lanes, depending upon which stage the work is. Thus, the board allows a visual oversight of all project work and the workflow through which the work progresses.  

The work that comes to the team may have to be classified into types. For example, there may be requests for new features or a defect found that needs to be corrected or a change request, among others. In addition, there may be work with a fixed deadline or which needs to be expedited above other work. Different types of work are represented on the board using different coloured cards, defined to identify the class of service it represents or by annotating the cards using another small card to identify additional characteristic like a fixed date of delivery. 

The card will usually have an identifier written over it. Additional information, like the size in story points, estimated time required and the actual time required, can also be accommodated. There are no prescribed requirements for the design of cards. Instead, each team can customize it based on context and needs. 

In addition, the board also allows a visual understanding of WIP limits, blocking issues, and explicit policies. 

Limit WIP 

If the team tries to do more than it can, it will take longer to do it. Such an approach delays the delivery value to the customer. Therefore, we must limit the amount of work that we take on at one time and finish that work better before starting to work on another item. This focus helps in two things: maintaining a sustainable pace and delivering continuous value for a more extended period. And two, increase productivity by cutting down the time required for context switching when we alternate between multiple tasks at a single point in time. The team following Kanban establishes the capacity to work based on a fair and reasonable expectation for the team’s workload.  

Another benefit of limiting the WIP is that it enables the team to be better prepared to respond to the change. For example, suppose there are many items that the team is working on, and something new comes up. In that case, it will add to the partially completed work without achieving anything, thus delaying value delivery to the customer.   

Manage Flow 

Managing flow refers to ensuring that the system keeps on delivering maximum value at a constant rhythm. Kanban emphasizes “Single Piece Flow”. Only one piece of work is moved between stages at a time, as opposed to batches of work. This work might represent a user story or a Minimum Marketable Feature, which might be larger than the user story. However, it still should be as minimal as possible. The minimal size of work items enables progressive delivery to realize product sooner, reduces feature bloat, and focuses on higher priority features for the customer. 

The predictability about how much the team can deliver establishes the cadence. In other agile methodologies, the concept of timebox determines the cadence (rhythm). With Kanban, there are no timeboxes. The timeboxes consider planning, review and release together. Kanban decouples all of them so that they can have their cadences. Velocity is the measure to establish how much work the team can accomplish in the iteration timebox. Kanban uses the concept of throughput and cycle time. 

Kanban flow operates like this; the customer requests a feature placed in the product backlog. Then, based on prioritization, the work item is moved to the iteration backlog. The time taken to deliver the component from the time customer requested it is known as the lead time. The time taken to complete the feature from the time the team placed it in the iteration backlog is known as the cycle time. Once the work item is placed in the iteration backlog, when the capacity of the next stage is available, that work item is pulled in the next stage. From this point onwards, until the time it is completed, the work item is WIP.  

The throughput of the team is measured by dividing the WIP by Cycle time. Throughput establishes the future capability for delivery. The Cycle time becomes the SLA with business teams for delivery. By selecting a cadence of the delivery based on throughput and cycle time, commitment and reliability are achieved through actual measurements instead of planning. 

Make Process Policies Explicit 

Kanban recommends a small, incremental but continuous improvement approach. You start with what you have, inspect it for improvement through value stream mapping and make minor improvements accordingly. Unless all the policies, procedures and rules governing the current process are not made clear explicitly to all stakeholders, correct assessment for weaknesses is impossible. These policies may be related to pulling criteria, i.e. how and when the work will be pulled or related to queue replenishment, or how the team will deal with different services. Generally, rules governing each stage of the card wall are written down at the bottom of the column representing the stage. Such placement allows anyone to look at the wall or board and understand the process’s policies. 

Implement Feedback Loop 

Smaller feedback loops facilitate continuous improvement. Kanban advocates daily team meetings, similar to Daily Scrum, to review the progress of the work. However, Scrum emphasizes the individual, whereas Kanban places emphasis on the actual work. For this reason, these daily meetings happen in front of the card wall or board.  

Apart from daily meetings, Kanban also advocates Mentor-mentee relationships. Through coaching and feedback, such a relationship facilitates continuous improvement. 

However, for organizations or business units as a whole, they must implement Operations Review. Operations reviews include a qualitative and quantitative assessment of data from multiple kanban systems to provide inter-workflow feedback. Without this second-level review, organizations might not realize process improvements beyond localized team levels. 

Improve Collaboratively, Evolve Experimentally (Using Models and Scientific Methods) 

For improvements to be permanent and practical, they must come from a shared understanding of work, workflow, process and risk. In addition, the shared experience helps build consensus about the improvement actions. The shared understanding is made possible by using Models and Scientific Methods. David Anderson suggested three primary methods or models; Theory of Constraints, which helps team study bottlenecks; theory of Profound Knowledge, which facilitates the study of workload variations, their impact on processes; and Lean Economic Model concept of waste. Other models can also be adopted, provided they are based on scientific methods. 

The use of models allows teams to make better predictions about possible effects of change. In addition, the use of scientific methods allow observing the impact of change and then comparing it to the projections. This approach helps create a learning environment in an organization, which will result in continuous improvement. 

Adopting Kanban can encourage better collaboration between various parts of the organizations, both upstream and downstream. E.g. Marketing and Development. It also promotes a culture of Continuous Improvement (Kaizen), thereby delivering valuable product regularly. 

ALSO READ

Fundamentals of Agile: A Simple Yet Comprehensive Guide for Beginners

What Is Scrum? A Deep Dive Into The Framework And Its Successful Adoption (Part I)

Featured Image: Photo by airfocus on Unsplash