The Kanban system for agile software development explained

An detailed overview of the method for anyone who needs to familiarise themself with the the use of Kanban by software development teams

Agile • UPDATED ON March 24, 2023

John Adam

Author

Kanban is an Agile approach described alternatively as a methodology, system, framework or workflow management method depending on the context in which it is applied. Particularly popular in a software development context, the Kanban system is designed to improve the efficiency of production processes and the end quality of what is produced and is.

The Kanban system for Agile software development is what our focus will be here. You’ll be introduced to what Kanban is, its history from birth on the floor of post-war Toyota’s assembly lines and subsequent adoption as a popular software development process.

And we’ll also break down the main concepts and elements of the Kanban system as well as touching upon its practical implementation within software development projects and teams.

What exactly is the Kanban system?

At its core, Kanban is a Just In Time (JIT) production process designed to optimise the flow of the raw resources and components used in the creation of an end product. In software development, the Kanban system optimises the flow of work in progress (WIP) with the capacity of the development team.

Another key pillar to Kanban is that it is a “pull” not “push” system. That means work is pulled into the system once previously assigned work has been completed as opposed to new tasks pushed into the workflow as they are created. The significance of the inversion from “push” to “pull” is that production becomes a consequence of and correlated to customer demand, reducing the potential for waste.

The core concept of Kanban is that keeping the production process as lean and free of “clutter” as possible:

• Improves organisation.
• Maintains focus.
• Increases productivity by maintaining a consistent ‘flow’ of the tasks that culminate in the end product.
• Improves task prioritisation while leaving space for Agility and the ability to react quickly to change.
• Fosters team collaboration.
• Encourages leadership across all roles and levels of seniority.

Kanban is a highly visual system. The production or development process is broken down into individual tasks which are each represented by a (usually colourful and often colour-coded) card. The system’s name is derived from its visualisation mechanism with “kan” meaning signal and “ban” card in Japanese.

A Kanban team is assigned as many tasks as considered optimal to its capacity. Team members then pick up those tasks one by one and move them through various stages of completion (which can vary depending on the project or organisation) from “To Do” to “Done”, as quickly as possible before starting on the next one.

All task cards are placed on the “To Do” column of a Kanban board, which will be described in more detail later, and then moved across columns representing different stages of completion as they progress. Visualising the workflow in this way means it very quickly becomes clear if bottlenecks are inhibiting the progress of tasks towards completion, so they can be resolved.

Kanban’s visualisation of task backlog and workflow is like a form of gamification, applied to productivity and teamwork.

A brief history of the Kanban system

The Kanban system was born on the post-war factory floors of the Japanese car manufacturing giant Toyota in the late 1940s. Toyota took inspiration from the Just In Time approach already being implemented at the time in Japan by supermarkets which had optimised their inventory management by using the card system between the shop floor and storeroom and storeroom and supplier.

If a product was running low on the supermarket shelves a Kanban card requesting x number to top up supplies was sent to the store. The store would replenish its own supplies by sending a Kanban card to the supplier.

Toyota was impressed by how supermarkets were using the Kanban system to gain efficiencies in inventory management by minimising the excess stock being held in-store and in their storerooms at any given time. And that these efficiencies were gained without compromising the supermarkets’ ability to ensure customer needs were always met.

The same technique was duly implemented in Toyota’s factories as the company looked for a competitive edge on Western competitors as Japan suffered an economic downturn. It worked and inspired other Japanese manufacturers, helping to set the country back on a path of economic growth.

But the Kanban system that helped establish Toyota as one of the biggest car manufacturers in the world and Japan as a hub of efficient innovation in manufacturing only truly caught international attention with the publishing of Toyota Production Manager Taiichi Ohno’s 1978 book on the Toyota Production System (TPS). Much of the global economy now runs on the JIT supply chain principles first implemented by Japanese supermarkets and honed by Toyota in its production system.

Ohno’s documentation of how Toyota used Kanban to drive continuous improvement of processes (neatly encapsulated by the Japanese word “kaizen”) and the avoidance of waste (“muza”) saw the system start to attract a significant following. It also provoked the International Motor Vehicle Program to carry out an extensive study on the system between 1985 and 1991 which resulted in Toyota’s methodology becoming Lean Production.

Kanban and Lean also, of course, subsequently deeply influenced the approach to digital as well as physical production and are today hugely popular in Agile software development.

Kanban’s agendas, values, principles, practices

Kanban was formalised as an Agile software development system by David J. Anderson’s 2007 book Kanban: Successful Evolutionary Change for Your Technology Business. The system quickly gained traction within the IT sector to the extent Anderson established the Lean Kanban University (LKU) in 2011.

Anderson’s formalisation of “The Kanban Method” of software development sets out agendas, values and principles as a philosophical framework for its prescribed practices.

Kanban has 3 agendas, which Anderson says allow Kanban coaches to embrace and be transparent about the method’s biases. They are:

• Sustainability
• Service-orientation
• Survivability

Kanban has nine values founded on and including the underlying value of mutual respect between team members and project stakeholders. The values are designed as a summary of why the principles and practices of Kanban exist and are:

• Transparency
• Balance
• Collaboration
• Customer Focus
• Flow
• Leadership
• Understanding
• Agreement
• Respect

Kanban’s six principles are split into two sub-groups:

1. The Change Management Principles
2. The Service Delivery Principles

Each sub-group contains 3 principles:

The Change Management Principles

• Start with what you do now.
• Agree to pursue improvement through evolutionary change.
• Encourage acts of leadership at every level.

The Service Delivery Principles

• Understand and focus on your customers’ needs and expectations.
• Manage the work; let people self-organize around it.
• Evolve policies to improve customer and business outcomes.

And the six Kanban practices anyone managing a project that uses the method should implement are:

1. Visualisation of workflow
2. Limiting work in progress (WIP)
3. Managing flow
4. Making process policies explicit
5. Implementing feedback loops
6. Improving collaboratively, evolving experimentally

Kanban team roles

While specifically titled development team roles and their responsibilities, eg., Scrum Master and Product Owner, are core to other Agile frameworks and systems, that’s not the case with Kanban. However, while they are far less integral to Kanban, two ‘roles’ within a team have been defined:

• Service Delivery Manager (SDM)/Flow Manager
• Service Request Manager (SRM)

Service Delivery Manager (SDM)/Flow Manager

The two titles SDM and Flow Manager are used interchangeably and represent responsibilities taken on by a member of the Kanban team rather than a stand-alone job title. The SDM role has some similarities to that of a Scrum Master in that, if it is assigned with a Kanban team, the individual fulfilling it is responsible for maintaining the flow of tasks and that team members are diligent in maintaining team cadences (like regular meetings etc.).

SDM responsibilities would be expected to include:

• Supervising the Kanban board and making sure tasks are flowing and not getting stuck in bottlenecks.
• If any task is not moving towards completion at the expected pace, bring it up with its owner to check if there’s a bottleneck of some sort and offer help.
• Make sure agreed team policies and practices are followed by the team members. Especially important if members are new to working to a Kanban system.
• Responsible for the scheduling and attendance of all daily and delivery planning Kanban meetings.

The Service Delivery Manager role additionally involves the responsibility to drive the Kanban team’s quest of continuous improvement, or kaizen strategy. Scaled Kanban SaaS platform Kanbanise addresses the reality that the concept of ‘continuous improvement’ requires a solid framework if it is to avoid being too abstract to practically mean anything. Kanbanize suggests SDM responsibilities in the pursuit of continuous improvement could include:

• Collecting data about the work items on the Kanban board and discussing it with the team
• Asking questions until the team has identified a true root cause for a given problem
• Making sure that errors are not repeated more than once
• If the person has enough experience to do so, coach the team members on Lean & Kanban

Service Request Manager (SRM)

If the Service Delivery Manager role in Kanban has echoes of the Scrum Master role in a Scrum team, there are similar shades of the Product Owner role to Kanban’s Service Request Manager (SRM). These similarities rest on the parallel responsibility to understand the needs and expectations of the client and end-users.

SDM is also almost always a role that a Kanban team member takes responsibility for on top of their core job rather than a stand-alone position. In a 2016 blog entitled Emerging roles in Kanban, Anderson carefully distinguished the SRM role from that of a Product Owner in Scrum with:

“The goal is to reposition the role of the product owner as a risk manager and facilitator: someone who owns the policies for the system which frame decisions together with facilitating the decision-making mechanism. This role is of higher value, is transparent and open to scrutiny and relieves us of the risk of the ‘hero product owner’ who magically understand where the best business value is to be found. This elevated risk management and policy owning position improves corporate governance, improves the consistency of process, and reduces personnel risk associated with a single individual.”

If the SRM role exists, the individual fulfilling it should be above the workflow and responsible for “the Replenishment Meeting and will play a role in the Strategy Review and Risk Review”.

How does the Kanban system fit within the Agile approach to software development?

Kanban can be used as a system or framework under the broad umbrella of Agile software development. There is natural compatibility as both Agile and Kanban are designed to help teams find an optimal balance between discipline and adaptability in their pursuit of most effectively meeting market demands.

There is a conceptual debate around whether Kanban is ‘Agile’ or not. It’s not a debate we’re going to get into here, or have much interest in. Kanban is generally accepted as one of the multiple Agile methods or systems which all follow the core value of aiming to become more adaptive and responsive to change in the pursuit of greater team efficiency and higher quality output.

Despite David Anderson popularising Kanban as a software development system, he rejects the interpretation of it as a software development process. He prefers to define Kanban more broadly as a method for managing, designing and improving flow systems for knowledge work to better create value for customers.

Kanban and DevOps

The Kanban method is also seen as compatible and complementary with DevOps. That is possible because DevOps is, like Agile, a culture, or mindset, while Kanban is a method, framework or system. Again, there is conjecture and debate on the topic, but the easiest way to describe DevOps is as simply extending the Agile approach to ‘a new audience’ – IT operations.

DevOps unifies development and operations teams as a single Agile software development team with a common goal – better software that adds more value for users. And joint responsibility for realising that goal.

Kanban is one of the systems that can be implemented that helps a software development team visualise and improve the efficiency of how that value is delivered. As a system/method, Kanban collaborates with the Agile and DevOps culture/mindset.

Kanban and Lean development – and the relation to Agile

Kanban is, of course, closely historically connected to the Lean management approach to creating value because they both trace their roots to the Toyota Production System. Lean organisations, or software development teams, attempt to identify and eliminate activity that is not valued by the customer or end-user.

Kanban evolved as a method used first by Toyota, then other Lean organisations to reduce waste, variability, and inflexibility. This is why it shares the Lean prescription of a mindset of continuous improvement and flexible working processes that encourages the contribution of new ideas and suggestions by all team members with the goal the organisation becomes better over time. Freed from non-value-generating tasks, people focus more on what matters to customers.

Agile and Lean share many of the same underlying values and principles and the Agile Manifesto was heavily influenced by Lean. Agile aims to deliver working software as quickly as possible and does so by insisting on the iterative development of value added increments to working software. In Lean, teams increase speed by managing flow, usually by limiting work-in-process.

As a system or method, Kanban is informed by both Lean and Agile.

Scrum vs Kanban

Scrum and Kanban are alternative Agile methods or systems that simply prescribe different routes that have their own routines and rituals but the same destination. Put concisely, a Scrum team works in a series of sprints with a clearly defined beginning and end. By contrast, Kanban is a continuous process, so there’s no sprint backlog.

Source: Atlassian

Both methods are popular in contemporary software development and have their respective strengths and weaknesses. A hybrid method that combines elements from both Scrum and Kanban, Scrumban, is actually more often used by software development teams than Kanban is as a standalone system.

Implementing the Kanban system

Implementing Kanban involves setting steps and practises that support the method’s six practices:

1. Visualisation of workflow
2. Limiting work in progress (WIP)
3. Managing flow
4. Making process policies explicit
5. Implementing feedback loops
6. Improving collaboratively, evolving experimentally

Source: OpenSource.com

The Kanban board and cards

The Kanban board is central to most of the system’s practices, most notably visualising work, limiting work in progress (WIP) and managing flow. A Kanban board can be physical but is most often digital for software development teams, especially if team members work remotely all or part of the time.

Work in the form of tasks (often defined as user stories for Agile development teams) is pulled onto the Kanban board and visually represented by a coloured card. The number of tasks pulled onto the Kanban board should correspond to the development team’s capacity and limit WIP accordingly.

Boards are broken down into columns that represent different stages of a task’s completion. The simplest Kanban board structure has just three columns:

1. To do
2. In progress
3. Complete

But often have several more that take into account the qualities and complexity of the particular project. An more complex, and typical, example of a Kanban board might look like this Microsoft example:

A Kanban board might also introduce swimlanes, which are horizontal lines dividing the vertical columns. Swimlanes are used to group task cards more systematically when there is a practical need to differentiate. They could be used to show cross-team dependencies or split out tasks expected to take more or less time so it is easier to differentiate between a possible bottleneck and naturally longer cycle at a glance.

Why the definition of ‘done’ in Kanban is key to creating value

One of the most important elements to a successful implementation of the Kanban method, defined as creating value for the end customer/user, is the ‘definition of done’.

Kanban’s value is in helping to create the conditions for and manage an efficient flow of high quality work. Effectively tracking the progress of tasks is central to keeping work flowing. And measuring the progress of a task effectively inherently requires a clear understanding of when it ends – what the “definition of done” is.

Knowledge work projects, especially Agile knowledge work projects, rarely come with a clear picture of what the project’s final status looks like. Team members start working on tasks, or user stories, the final details of which are still ambiguous.

But individual tasks need a definition of ‘done’ to classify their end to avoid the risk they remain indefinitely ‘in progress’, which leads to waste and destroys value. Avoiding that means setting acceptance criteria, like “definition of done” checklists for both individual tasks and processes.

For example, creating explicit policies for what it means for a user story to fully specified and tested before being released into production, decreasing the likelihood of bugs or the failure to add value. Creating explicit policies for work processes is, of course, on of the six Kanban practices.

Definition of done can be visualised on a Kanban board by the addition of “exit criteria” added to columns representing work stages. When a Kanban card enters a stage with defined exit criteria, they can be visualised as checklists on the work item. The card can then only pass through to the next work stage when the exit, or acceptance, criteria for the current one have been checked off.

Limiting Work in Progress (WIP) – Planning & estimation in Kanban

While Kanban does not go into detail on how exactly planning and estimation should be done, leaving this for teams to define themselves, the question “how long will this take?” is still important. Accurate delivery forecasts maintain customer trust and satisfaction.

Estimation can be a friction point for Agile software development as the approach inherently rejects detailed upfront planning of user stories and working products. Project sponsors, however, often still have a budget and deadline. By definition, Agile estimates are not exact but still need to be made in Kanban if Work in Progress is to be effectively limited.

A Kanban roadmap can be used for high-level planning and estimation. It should be based on goals, themes and strategies towards a mid-term vision rather than a detailed plan of new features. Before user stories or other work items are added to the Kanban board, the Kanban method recommends they are estimated using data-driven, probability-based future predictions based on historical performance records.

Cumulative flow diagram

Cumulative flow diagrams (CMDs), also referred to as burn-up charts, are an important Kanban tool for data-driven, probability-based workflow management and ongoing estimation of work items. They are a visual metric that not only helps teams to analyse the stability of workflow but also to measure and visualise cycle and lead times, throughput and work in progress.

They are also considered the best way to predict and estimate project completion by collecting and visualising data throughout a project. Historical CMDs from previous projects also provide the performance records that can be used during initial estimations.

CMDs also support the Kanban practice of continuous, collaborative improvement by highlighting what is working well and what requires attention.

Kanban meetings and cadences

From quick daily team meetings to big-picture strategy reviews with external stakeholders, Kanban meetings keep interconnected Kanban systems operating efficiently. The role of the seven core meetings identified by the Kanban method is to help maintain quality through collaboration and personal accountability, keep workflow moving smoothly, identify problem areas and assess customer satisfaction.

There are seven recommended Kanban meetings which are split into two ‘cadences’ – with the term meaning a ‘network’ of meetings. They are central to the Kanban practice of feedback loops and designed to foster the necessary bi-directional communication between stakeholders and within the core software development team.

The two Kanban cadences are:

1. Team level cadences
2. Service oriented cadences

Team level cadence Kanban meetings

Source: Kanbanize

The team level cadence consists of three meetings:

1. Team Kanban Meeting – Daily Meeting
2. Team Replenishment Meeting
3. Team Retrospective

Team Kanban Meeting

A quick daily meeting that is recommended to be kept to a duration of 15 minutes for efficiency, the Team Kanban Meeting is the opportunity for the team to synchronise and focus on the day ahead. A favoured format of the daily meeting is for all team members to ask and answer three questions:

• What’s impeding us?
• How is work flowing?
• What can we improve?

Bottlenecks are identified at the daily meeting so solutions can be pursued and this meeting is also the time to assess if WIP limits are being respected.

Team Replenishment Meeting

A weekly or bi-weekly meeting with a recommended duration of 30 minutes, the Team Replenishment Meeting is used to make sure the team has the right number of work items in progress and can commit to delivering these tasks.

Team Retrospective Meeting

Team Retrospective Meetings, which can also be referred to as Replenishment Reviews, should last for around 30 minutes and take place every 2 weeks to a month, depending on project cycle lengths, and focus on how the team is managing its work and identifying what can be improved such as process policies.

Source: Nave – dashboards for Kanban teams

Service oriented cadence meetings

The service oriented cadence consists of four meetings:

1. Workflow Replenishment Meeting
2. Service Delivery Review/Workflow Meeting
3. Flow Review
4. Risk Review/Blocker Clustering

Source: Kanbanize

Replenishment Meeting

Also taking place every 2 weeks to a month and with a recommended duration of 30 minutes, his is where new work items are added to the Kanban board. This means product owners and anyone else involved in the project’s management, but not with the development team day-today, should be involved in the meeting.

When deciding on new work items, considered should include their Class of Service, delivery date deadlines, strategic objectives and team member skills needed for them to be completed.

Service Delivery Review/Workflow Meeting

A customer-focused review, the Service Delivery Review is another 30 minute, bi-weekly or monthly meeting and is used to analyse the value being provided to the client by the software development team’s output. The meeting should involve both the customer, service delivery manager and any other relevant stakeholders not part of the development team.

The meeting is used to assess data-driven metrics established at the project’s outset such as desired cycle times, lead time consistency and delivery rates. The transparency and opportunity to engage with customer concerns this meeting provides should help build trust with the customer.

Flow Review

A sub-cadence to the Workflow Meeting, the Flow Review focuses on internal team capabilities and capacity. Its goal is to understand and so keep on top of the process flow and identify problems such as upcoming bottlenecks and ways to unblock them.

Risk Review/Blocker Clustering

Usually held bi-weekly or monthly, this 1-2 hour meeting is dedicated to examining bottlenecks and blockers that could pose a risk to delivery. Historical failures should be analysed and their causes mitigated against and the meeting should involve all team members and stakeholders familiar with current and recent blockers. Attention should be drawn to blocker clusters on a team or a department level.

Big Picture Kanban Meetings

There are two further meetings recommended by the Kanban system that are bigger picture and sit above the two cadences:

1. Operations Review
2. Strategy Review

Operations Review

This roughly two-hour meeting, usually monthly, is like a macro version of the Service Delivery Review, and brings together interconnecting internal teams and systems. It could cover a department or even an entire small company. The reasoning is efficient teams can be held back by inefficiencies elsewhere in an organisation such as in resources planning or dependencies with a less efficient team.

Managers from different divisions, departments, or systems work together to find efficiencies that will benefit the whole such as areas of underused capacity throughout the organisation that can be used to improve lead times.

Strategy Review

The, usually quarterly and lasting up to half a day, Strategy Review is the highest level Kanban meeting. It is used to adjust strategy based on customer feedback and any changes to external factors such as markets and consumer/user behaviour.

The crux of the Strategy Review is that it makes little difference how fast and efficiently a vehicle is moving if it is in the wrong direction. Setting and adjustments to broad strategic goals and direction should feed into the Kanban roadmap and be translated into the daily, weekly and monthly goals addressed during the Delivery Planning and Workflow Replenishment Meetings.

Participants should come from a wider circle of stakeholders and can include senior management, product owners, senior development team members and relevant representatives from customer-facing departments like sales and marketing.

Kanban Pros and Cons

Like any given methodology, framework or system used in software development, the Kanban Method has its pros and cons. These can be briefly summarised as:

Kanban Pros

Ease of use/low barriers to entry: one of Kanban’s key strengths is the fact its simplicity and use of visualisation mean even team members with no prior experience of working to the system can very quickly pick it up.

Flexibility: central to Kanban as an Agile method is the inherent flexibility it represents, allowing teams to quickly adapt to change and adjust processes in the pursuit of continuous improvement and the creation of value.

 Collaboration: Kanban is highly collaborative and promotes teamwork and collective responsibility for overall efficiency and the creation of value.

Establishing of a process: Kanban’s focus on continuous delivery drives productivity, especially during longer project cycles.

Kanban Cons

 Can lack focus: Kanban’s avoidance of setting strict responsibilities can mean teams and individuals get distracted.

 Kanban board complexity: it may sound like a contradiction to Kanban’s listed strength in simplicity but on the Kanban board level if care is not taken things can quickly get very complex, confusing team members.

Lack of time-boxing: some customers and project managers are put off by Kanban’s lack of strict time-boxing which stands in contrast to other Agile approaches like Scrum.

Tension with iterative software development: iterative development is a pillar of most Agile software development systems but is not integral to Kanban at a ticket level. This is one of the main reasons elements of Kanban are often combined with other approaches like Scrum.

Conclusion

We hope this blog has provided you with a strong overview of the Kanban Method. You should now understand why, either as a stand-alone system or through cherry-picking elements like the Kanban board in combination with other approaches, it is such a popular part of the software development project management ecosystem.