Welcome to Kanban Overview Jenny Stuart · the introduction of interchangeable parts. A Brief History of Lean: Whitney Artisanal manufacturing—skilled craft-persons individually

Kanban

© 2017 Construx Software Builders, Inc. 1

Welcome to

Kanban Overview

Jenny StuartVice-President of Consulting

Construx Software

Course Objectives

Our first priority is that you really understand what Kanban is and what it isn’t.

Kanban


Course Objectives


You’ll learn that Kanban is more than just a board!

Course Objectives



You’ll discover that Kanban is richer, deeper, and more disciplined than you might think.

Kanban


Course Objectives



You’ll discover that Kanban is richer, deeper, and more disciplined than you might think.

You’ll see how to use metrics to analyze, understand, and continuously improve your Kanban system so that it works both for the individuals using the system and for the business.

Course Organization

The Foundations of Kanban

Kanban


Course Organization


The Fundamentals of Kanban

Course Organization



Setting Up a Kanban System

Kanban


Course Organization




Kanban Metrics

Course Organization




Kanban Metrics

Operating Kanban

Kanban


02 The Roots of Kanban: Lean Manufacturing and the Toyota Production System

Kanban Overview

Jenny Stuart

Kanban’s origins are not in the Agile software development world.

It began instead in the world of “lean” (that is, lean manufacturing or lean production).

Kanban


A Brief History of Lean

Artisanal manufacturing—skilled craft-persons individually making individual items by hand—first began to change with the introduction of interchangeable parts.

A Brief History of Lean: Whitney

Artisanal manufacturing—skilled craft-persons individually making individual items by hand—first began to change with the introduction of interchangeable parts.

This innovation is often credited to Eli Whitney, who first tried the approach in the manufacture of muskets.

Kanban


A Brief History of Lean: Ford

Henry Ford continued this evolution by introducing the moving assembly line (or the manufacturing line).

This innovation drastically decreased the time required to build a Model T.

Ford made sure that the people at each station had the right skills for that station via training.

A Brief History of Lean: The Toyota Production System

Lean came into being with the Toyota Production System (TPS), which began to be developed in 1948.

Kanban



The TPS is grounded in these crucial concepts:

● Build quality in as you go along.

● Continuously improve by optimizing, learning, and evolving.


The TPS is grounded in these crucial concepts:

● Build quality in as you go along.

● Continuously improve by optimizing, learning, and evolving.

● Use a “just-in-time” approach: build the right things at the right time in the right quantity.

Kanban


A Brief History of Lean: Improvement Is a Major Goal

Lean’s most significant contribution was encouraging and enabling people to continuously improve the way in which they work.

A Brief History of Lean: Improvement Is a Major Goal

Lean’s most significant contribution was encouraging and enabling people to continuously improve the way in which they work.

This emphasis allows for greater optimization of the manufacturing system’s flow.

Kanban


Lean in a Nutshell

Lean is a method that seeks to maximize customer value by

continuously improving the ways we do our work, a process known as kaizen

Kaizen (continuous improvement) requires daily improvement and improvement by everyone in the system: from managers to those doing the day-to-day production work.

How do we improve at every point in our system to maximize customer value?

Kanban


Lean in a Nutshell

Lean is a method that seeks to maximize customer value by

continuously improving the ways we do our work, a process known as kaizen, and

eliminating/avoiding/reducing waste.

Types of Waste in Software

An incomplete list includes:

● Partially done work

● Defects

● Task switching

● Extra features

● Extra processes

● Waiting

Kanban


Examples of Waste: Partially Done Work

Lots of progress on lots of features but no features actually done—with the intention of landing everything at the end of the project. This is risky!

Examples of Waste: Partially Done Work

Lots of progress on lots of features but no features actually done—with the intention of landing everything at the end of the project. This is risky!

Certain sprints are done, such as coding, but lots of other work is still unaddressed, such as unit testing, documentation, integration testing, functional testing, etc.

Kanban


Examples of Waste: Defects

Avoid aggregating defects behind you. Putting off defect fixes until later puts you at risk of “infinite defect mode”: for every defect you fix, you inject one or two more into the system.

Examples of Waste: Defects

Avoid aggregating defects behind you. Putting off defect fixes until later puts you at risk of “infinite defect mode”: for every defect you fix, you inject one or two more into the system.

Find and fix injected defects as soon as possible after their injection to make your projects more predictable.

Kanban


Examples of Waste: Task Switching

Working on multiple tasks simultaneously means that you won’t work on any them particularly quickly.

You want people to be able to focus.

Follow this mantra:

Stop starting; start finishing.

Examples of Waste: Extra Features

Releasing something earlier with fewer features to get feedback might show you that you don’t need as many features. (This is the lean startup methodology.)

Kanban


Examples of Waste: Extra Features

Releasing something earlier with fewer features to get feedback might show you that you don’t need as many features. (This is the “lean startup” methodology.)

This allows our customers to send us in a direction that provides them more value.

Examples of Waste: Extra Processes

Unfortunately, unnecessary processes are more common than you think: detailed requirements documents, heavy stage-gate processes, etc.

Watch out for processes that require a lot of effort in return for not a lot of value.

Kanban


Examples of Waste: Waiting

An example is the annual budget cycle, which requires teams to wait for approval to start work even though they’re ready to begin now.

Try to understand the forms of waste existing in your organization—most organizations include multiple forms—and then introduce changes that help you reduce or eliminate that waste.

Using Kanban is a great way to approach this crucial work.

Kanban


Muda Non-value-added tasks.

Example: A build and deployment process to move an item from a developer’s workstation to the QA environment for testing that takes 0.75 to 1.5 days.

TPS’s Waste Classifications



Muri Unevenness or variability in flow.

Example: A Product Owner who sometimes has enough information for sprint planning and at other times doesn’t and simply can’t proceed.


Kanban




Muri Unevenness or variability in flow.

Example: A Product Owner who sometimes has enough information for sprint planning and at other times doesn’t and simply can’t proceed.

Mura Overburdening of the individual.

Example: Mandatory 60-hour work-weeks to meet an arbitrary deadline.


So What About Kanban?

Kanban was a key method developed at Toyota to help enable TPS’s just-in-time delivery process.

Kanban



Its goals—and its benefits—include:

● Matching inventory with demand.




● Optimizing quality.

Kanban





● Optimizing quality.

● Optimizing throughput by○ matching incoming work with the

capabilities of people to create the best kind of system flow, and

○ reducing waste by encouraging improvement activities.

03 Terminology and History

Kanban Overview

Jenny Stuart

Kanban


What Does “Kanban” Mean?

kan Visual.

ban Card or board.

kanban Sign, signboard, signal card, token.


kan Visual.

ban Card or board.


Kanban system A system that uses tokens as a mechanism for managing the flow of a process. (Began in supermarket inventories.)

Kanban



kan Visual.

ban Card or board.


Kanban system A system that uses tokens as a mechanism for managing the flow of a process. (Began in supermarket inventories.)

Kanban Method An approach for driving evolutionary change inside of organizations using Kanban systems.

The Kanban Method’s roots are in Theory of Constraints, queueing theory, and kaizen.

History of the “Kanban Method”

Kanban



David Anderson and Dragos Dumitriu designed a pull-based system for Microsoft XIT Sustained Engineering in 2004.



Microsoft’s implementation was presented as a kanban system at a conference in 2005, following a discussion between David Anderson and Don Reinertsen.

Kanban




Microsoft’s implementation was presented as a kanban system at a conference in 2005, following a discussion between Anderson and Don Reinertsen.

Anderson’s Kanban: Successful Evolutionary Change for Your Technology Business was published in 2010.

04 The Kanban Method

Kanban Overview

Jenny Stuart

Kanban


This section describes the Kanban Method’s fundamental methods specifically as they relate to software development.

The Kanban Method Is Not…

A specific software development lifecycle (SDLC), or

a specific workflow or process, or

a project management methodology, or

just a board!

As you’ll learn, Kanban is much more than the use of a particular information radiator.

Kanban


The Kanban Method…

Advocates using Kanban boards and kanbans (signs or tokens) to visualize both work items and workflow.



Creates a pull-based system to limit work in process. Work items are pulled into a stage only when that stage is ready for that work.

Kanban




Creates a pull-based system to limit work in process. Work items are pulled into a stage only when that stage is ready for that work.

Drives incremental change to the software development process. Kanban metrics help us understand and improve our system.

Foundational Principles of Kanban

Start with what you do now.

Kanban




Respect current job titles and roles, and leave them unchanged.




Agree as a whole team to incrementally evolve your system. (The “Kanban Metrics”section describes multiple ways to do this.)

Kanban





Agree as a whole team to incrementally evolve your system. (The “Kanban Metrics”section describes multiple ways to do this.)

Encourage acts of leadership at all levels—from individual contributors to senior management. Anyone can be the source of positive change.

Core Practices of Kanban

Visualize (and it’s best to do so physically).

Kanban




Limit work in process. Do not forget this!




Manage flow.

Kanban





Manage flow.

Make policies explicit.




Manage flow.


Implement feedback mechanisms by using metrics. Encourage a culture of feedback, reflection, and improvement.

Kanban





Manage flow.


Implement feedback mechanisms by using metrics. Encourage a culture of feedback, reflection, and improvement.

Improve experimentally by using models, your data, and the scientific method. “If we do x, we should see y.”

Each of these practices individually adds value that moves you to a deeper, richer, and more valuable use of Kanban.

If you’re following only a few of these practices, your Kanban implementation is more shallow than it could be.

Kanban


05 When to Use Kanban

Kanban Overview

Jenny Stuart

Definitely Use Kanban...

When the work in question is emergent or dynamic, with priorities changing quickly.

Example: A production support team.

Kanban is very effective when you need to repeatedly determine the next important thing to do.

Kanban


Definitely Use Kanban…

When the work environment encourages independence rather than mandates.

Example: An org in which the team always gets to decide what it does.

Scrum doesn’t work as well as Kanban, which describes clear ways of working rather than dictates the content of work.


When an evolutionary approach will be better received than a revolutionary one.

Example: An org worried about all the changes that Scrum adoption would bring.

Kanban is well-suited to starting with the system in place today and driving slow, incremental change to it.

Kanban



When the team is really small.

Applying the entire Scrum process would be overkill, but Kanban’s emphasis on visualization and improvement adds value.

Can Scrum and Kanban Coexist?

Absolutely!

Many organizations use selection criteria to make it clear when teams should use Scrum and when they should use Kanban.

Kanban



Large product development teams often use a mix of Kanban and Scrum.

Example: Feature development teams might use Scrum. The DevOps, Test Automation, and System Test teams might use Kanban.


Often, Scrum is used by the development team and Kanban is used from a portfolio perspective to manage the features and products in the pipeline.

Kanban


You can take a mature, highly functioning Scrum team and “Kanban it” to take things to the next level by

visualizing workflow,

bringing in new metrics, and

seeking to optimize.

In many organizations, not only can Kanban and Scrum coexist, but also

it makes great sense for them to coexist.

Kanban


06 Kanban Is a Pull-Based System

Kanban Overview

Jenny Stuart

Kanban is a pull-based system, which is a new approach for a lot of teams.

Kanban


Kanban Is a Pull-Based System

Ideas Engineering Ready Development Testing UAT Deployment

Ready

Doing Done Doing Done

We can “pull” items into open slots only.

Kanban


Kanban Is a Pull-Based System

Ideas Engineering Ready Development Testing UAT Deployment

Ready

Doing Done Doing Done

“In Progress”/”Doing” and “Done” columns are important in pull-based systems like Kanban.

Kanban


The “Done” column shows a stage’s completed items that are available to be pulled into the next stage.

This movement happens only when the next stage has the capacity to work on another item—when, on the board, there is an open slot in that next stage.

Why Does Kanban Use Pull?

By minimizing work in process (WIP), we optimize the amount of work getting done in the system. We avoid bottlenecks, thrashing, multitasking, etc.

Kanban


Why Does Kanban Use Pull?

By minimizing WIP, we optimize the amount of work getting done in the system. We avoid bottlenecks, thrashing, multitasking, etc.

So we limit the WIP.

Again, “Stop starting; start finishing” is an important concept in Kanban.

Limiting the WIP results in work being done faster because

nobody is overloaded,

work items are queued, and

the current work items can be completed without distraction.

Kanban


How Do We Establish Pull?

1. Establish WIP limits for each workflow stage. Count both “In Progress” and “Done” items (items not yet pulled to the next stage) in the WIP limit.

2. Enforce a policy of pulling Done items from an upstream stage only when you have WIP capacity in the next stage.

You cannot create a true pull system without using WIP limits.

07 The Goal Is to Create Flow

Kanban Overview

Jenny Stuart

Kanban


Work in Each Stage Is Limited

Change Requests Analysis (4) Development (6) Testing (3) Deployment (2) Released

IP Done IP DoneIP Done

The Goal Is to Create Flow

Flow is “the continuous movement of work items through the system.”

Items sitting in stages for weeks or months is waterfall progression, not Kanban flow.

Kanban


We Create Flow Like This

Use the pull system (already described).

Continually reduce batch size. Size work items for hours/days, not weeks/months.

Again, progress measured in weeks or months is not the continuous flow Kanban strives to create.

First Misconception About Flow

Conventional wisdom Batching work increases efficiency.

Kanban


First Misconception About Flow

Conventional wisdom Batching work increases efficiency.

The truth Batch size inversely correlates with throughput.

We want to move smaller batches through the system

to actually be able to complete pieces of work, andto give us chances to discover, analyze, and correct defects in our system.

Second Misconception About Flow

Conventional wisdom Optimizing efficiency at each workflow stage optimizes the workflow.

Kanban


Second Misconception About Flow

Conventional wisdom Optimizing efficiency at each workflow stage optimizes the overall workflow.

The truth Local optimization decreases global optimization because it leads to bottlenecks.

We’ll show you various metrics you can use to optimize your overall system in the “Kanban Metrics” section.

Third Misconception About Flow

Conventional wisdom The higher the utilization, the higher the productivity.

Kanban


Third Misconception About Flow

Conventional wisdom The higher the utilization, the higher the productivity.

The truth Utilization is not productivity; high utilization decreases throughput.

Concentrate on system throughputto find the optimal way to move items through the system, andto give workers time to think about how they work to find improvements.

Not giving people time to step back to think about how they do the work is a common and costly mistake.

The “tyranny of the now”—too much work needing to be done right now—prevents workers from discovering ways to be more productive and to optimize the system.

Kanban


Kanban is effective in adding a concern for how work is done to merely doing the work.

Deep Kanban includes a practice called “scientific experiment,” which

drives changes to how we work, and

uses metrics and data to help us see whether the changes are having the impacts we expected.

08 Two Key Metrics

Kanban Overview

Jenny Stuart

Kanban


Understanding two metrics in particular is important for understanding Kanban’s fundamental nature.

Cycle time The elapsed time spent working on an item.

How long does it take from when we begin the work to when it is completed?

Kanban


Lead time The elapsed time from when an item is scheduled for work until it is delivered.

How long does it take from when the work is requested—put into the product backlog, input queue, or requests list—until that work is completed?

Is your team doing a ton of work but the throughput of your system is quite low? This is common.

Kanban


Concern that using WIP limits will decreasethroughput is also common.

AverageWIP

AverageWIP

Relationship of WIP and Cycle Time

AverageCycle Time

Kanban


This is a key principle of Kanban systems:

Decreasing WIP limits increases system throughput by decreasing cycle time and improving flow.

Put another way, reducing WIP optimizes cycle time.

You’ll learn much more about using these and other metrics in the “Kanban Metrics” section, which follows the “Setting Up a Kanban System” section.

Kanban


09 Key Elements of a Kanban System

Kanban Overview

Jenny Stuart

Let’s begin with some key elements to understand.

Kanban


Work item types What do you as a team deliver? What are the actual items that are your output?

Workflow What are the steps that your work items go through? After they enter the input queue, what activities happen? What are the stages of your workflow?

Kanban


Work state policies What are the explicitly stated and understood policies that describe when a particular work item type in a particular stage is considered done?

Set these for every workflow stage when building the Kanban board.

WIP limits How many work items are allowed at each stage? What limit for each stage makes sense for your team?

These limits range from proto-Kanban to true Kanban. Using true Kanban WIP limits doesn’t make sense in all scenarios.

Kanban


Classes of service Which work is the most important work? How will we approach the different classes of work?

Should we include an “Expedite” class of service so that certain work items always get quick attention? Many organizations have at least two classes of service.

You’ll learn more about these in “Using Classes of Service.”

10 Modeling the Work

Kanban Overview

Jenny Stuart

Kanban


Identifying Work Item Types

DeliverablesUser / Customer

Needs

Identifying Work Item Types

Deliverables

Deliverables,Capability, orInformation

User / Customer Needs

Internal Work/ Needs

Kanban


Think about what input comes in, what output you deliver, and to whom you deliver that output to determine your work item types.

Teams usually have between one and three work item types.

Using more work item types than this creates an extremely complex Kanban system. Not recommended!

Kanban


Combining items into a single work item type is OK.

Example: A team might deliver defect fixes, new functionality, and technical debt and consider those as one work item type: PBIs.

Example Work Item Types

Functionality New capabilities, items meaningful to the customer.

Defect Customer-reported bugs.

Infrastructure Internal work important to the org but not adding user value: spinning up a dev environment, building automation infrastructure, work on the build system, etc.

Support Item Operations- or Support-reported change requests, features, or defects.

Deployment Work to release new functionality to end users.

Kanban


It’s crucial to think through who makes requests from your team.

Then check whether it makes sense to consolidate any of those requests into single work item types.

Determine your team’s work item types with about 10–30 minutes of dialogue.

Kanban


After determining your work item types, the next step is to model your workflow.

Model the Workflow

Activity #1 Activity #2 Activity #3 Activity #4 EndStart

Kanban


Modeling your workflow is achieved by repeatedly asking a simple question:

“And then what happens?”

Your workflow model should include maybe 3–7 stages that the work moves through.

Kanban


Example: Offshore Maintenance Team

Implement Change Request

Review the Change Request

Code Review Change

Deploy Change UAT Change

After determining your work item types and modeling your workflow, you’re able to build your Kanban board.

Kanban


Example: Offshore Maintenance Team

ChangeRequests

Analysis Implementation Code Review Deployment

IP Done IP Done

In UAT Done

IP Done IP Done

Make sure to include “In Progress (IP)” and “Done” columns in each stage.

Without these columns, you aren’t using a pull-based system, which means you’re not really using a Kanban system.

Kanban


Example: Software Development Team

Design and Implement

Analyze Requirement Test Document Deploy


Input Queue Analysis Development Testing Documentation

IP Done IP DoneIP Done IP Done

ReleasedDeployment

Kanban



Input Queue Analysis Development Testing Documentation

IP Done IP DoneIP Done IP Done

ReleasedDeployment

Feature Requests

Production Support

When a team has more than one work item type, it’s common to

include multiple work item swim lanes on the board, and

make sure that the workflow stage names make sense across all of the swim lanes.

Kanban


Example: Scrum Team

Commit to Sprint

Refine Backlog Item

Develop Backlog Item

Test Backlog Item

Product Owner Review

Example: Scrum Team

Product Backlog Items Refinement Committed Development Testing

IP DoneIP Done IP Done

DonePO Review

Kanban


Never just take somebody’s else’s Kanban board and use it.

Analyze your work item types and your workflow to build the most appropriate board for your team.

Kanban is seeking to visualize your work, not somebody’s else’s.

The point is to visually represent what your team specifically does. This accuracy will help drive improvements to your system.

Kanban


Setting Stage Policies

Input Queue Analysis Development Testing


ReleasedDeployment

● BDD test cases complete

● No blocking dependencies

● UI guidance provided

● Code review complete

● TDD tests written & passing

● 80% coverage● Etc.

● Test cases automated & passing

● Selected regression tests completed

● Etc.

● Customer notification complete

● Ticket marked as Resolved

Exit criteria give you specific policies for moving a work item from the “In Progress” column to the “Done” column.

Set these policies for each stage.

Kanban




ReleasedDeployment









● Etc.



Team agreement on what it means for a work item to be done at each workflow stage is important.

Kanban


Setting Stage Policies



ReleasedDeployment









● Etc.



Setting clear, high-quality, and agreed-upon stage policies is very important.

Stage policies are somewhat like Scrum’s Definition of “Done” but scattered across the various workflow stages.

Kanban


Exit criteria determine when an item can enter the “Done” column. Then the item is free to be pulled into the next stage when that stage is available to do more work.

Whether you call these policies “exit criteria” or “entry criteria” isn’t important.

Agreeing upon and using the stage policies is what’s important.

11 Work-in-Process Limits

Kanban Overview

Jenny Stuart

Kanban


WIP limits are commonly overlooked when people set up Kanban systems, but they are what get you to Full Kanban.

Types of Work-in-Process Limits

“Proto-Kanban” “Kanban”

Individual CONWIPTeam Aggregated

Full

Kanban


Kanban with Individual WIP limits is sometimes appropriate, so let’s start there.

Individual WIP Limits

Input Queue Development Testing UAT Done

Kanban


Individual WIP limits are simple: each person on the team is given a WIP limit.

Often, that WIP limit is 2.

3 is not recommended because that dissipates focus.

A WIP limit of 1 is optimal.

Use Individual WIP limits only when each team member’s work is so specialized that sharing the work is impossible.

Example: A team supporting internal development tools, and each person specializes in only one or two unique tools.

Kanban


Agree that the team will do enough cross-training and pairing to move to a more robust WIP-limit approach.

Doing WIP limits individually comes with risks, is only Proto-Kanban, and doesn’t bring you the benefits of Full Kanban.

CONWIP (Constant WIP) limits restrict the total number of work items that the team can address at one time.

Example: Attendance at an event being regulated by tokens. If all the tokens are in use, no more people are allowed to enter.

Kanban


Constant WIP Limits

Backlog Development Testing PO Review Done

CONWIP (5)

Scrum is similar to CONWIP but different because the number of things you commit to in a sprint can vary.

CONWIP is rare in practice and doesn’t bring the benefits of Full Kanban.

Kanban


Team Aggregated WIP limits don’t include the Done column in the WIP limit for each stage. The IP column is WIP-limited, but the Done column isn’t.

This leads to local optimization only, which creates bottlenecks.

This is a really bad practice.

Do not use Team Aggregated WIP limits.

Kanban


Team Aggregated WIP Limits

Next (5) Development Testing Done

IP (2) DoneIP (3) Done

Team One Kanban Team Two Kanban

Again, don’t use Team Aggregated WIP limits.

They’re very close to Full WIP limits, which actually prevent the local optimization that leads to bottlenecks.

Kanban


Use Full WIP limits.

Every stage gets a WIP limit that includes both IP and Done.

Full WIP Limits for a Robust Pull System

Selected Requests (5) Analysis (3) Development (4) Testing (2) Deployment (2)

IP Done IP Done In UAT DoneIP Done IP Done

Released

Kanban


By limiting WIP for each stage, using Full WIP limits successfully prevents

the insertion of bottlenecks,

the reduction of throughput, and

the deoptimization of flow.

When working with clients to set up their Kanban systems, I establish Full WIP limits 99% of the time.

This is the WIP limit approach that delivers real throughput benefits.

Kanban


Setting WIP Limits

Ideal WIP limit: 1x the stage resources available to do the work.

Example: If you have five developers for a particular stage, use a WIP limit of 5.

Setting WIP Limits

Recommended starting point: 1.5x–2x the stage resources available to do the work.

Example: A team with five developers and two testers might have a Dev WIP of 8 and a Test WIP of 3.

Kanban


Setting WIP Limits

Begin by counting how many work items are in each stage today. You might find that you’re at 4x–6x your stage resources!

Then ask yourself: What’s a reasonable goal to first work toward? 2.5x? 2x?

Lowering WIP limits is an important goal.

In the “Kanban Metrics” section, you’ll learn about metrics that show that lowering WIP limits is optimizing your system.

Get as close as you can to 1x your stage resources.

Kanban


Getting to 1x stage resources quickly is very rare.

Far more common is getting to 1.5x–2x, and it can take a few weeks to reduce the WIP limits to this range.

Steady movement downward is the goal.

Once the system is under control with the lower WIP limits, make sure to maintain those limits going forward.

Everybody needs to agree that the WIP limits make sense.

Kanban


What about individuals working across stages? Use proportions.

Example: Developers work 85% in the Development stage and 15% in Test.

Adjust your WIP limits in response. 1.5x for five developers who are 85% Dev means a WIP limit of 6 or 7 rather than 8.

Don’t set your WIP limits high, nor at 1x. Lower your limits steadily but gradually.

Then you’ll use metrics to further optimize the WIP limits and the system.

Kanban


12 Using Classes of Service

Kanban Overview

Jenny Stuart

It’s a good idea to use classes of serviceunless all of your work happens to be equally important (which is unlikely).

Kanban


A classic approach to using classes of service is to use Normal/Standard Deliveryand Expedite.

The Expedite class of service is usually defined as so important that

the expedited work item is allowed to exceed the system’s WIP limits and

work is stopped on normal (non-expedited) items to allow work on the expedited item.

Kanban


Creating a policy for when an item can be expedited is a best practice.

Example: The work item must be related to a particular kind of customer feedback, plus the group’s two managers approve.

Class of Service Example Policy

Standard Delivery FIFO.On or before the SLA duration limits.

Fixed Date On or before a specific date.Fixed Date takes preference over Standard Delivery. Promoted to Expedite if the date is at risk.

Expediteaka Silver Bullet

ASAP. Jumps the queue & suspends other WIP.WIP limits can be exceeded to accommodate. Limited to 1.

Intangible or Low Priority

Done as time permits.Either no guaranteed delivery, or long timeframes.Suspend for higher classes of service, as needed.

Typical Classes of Service

Kanban


The Fixed Date class of service is for items that must be done by a certain date to avoid negative impact to the business.

Example: Moving from an app by date to avoid financial penalties.

Example: Releasing in time for a fixed marketing schedule to not lose revenue.









Kanban


Use the Fixed Date class of service to plan when work items need to enter the system.

Example: A Fixed Date work item that takes 21 days should be started at least 30 days before the date.









Kanban


Do you really need an Expedite?

Perhaps you need a High Priority class—these items receive preferential treatment over Standard Delivery items.

Choose High Priority items (if any) first when picking items from a Done column.

Limit classes of service to a maximum of four. (Use only one, if appropriate.)

If using four, make sure one of them isLow Priority/Intangible for work without a delivery date that can be put aside.

This gives the system breathing room, so other items can be more easily handled.

Kanban


Use the smallest number of classes of service possible. Again, use one if you can.

But recognize that usually some work items are more important than others, so classes of service is the correct approach.

How are classes of service visualized?

A common approach is to use an Expedite lane and/or unique card colors.

Kanban


The Expedite Lane

ChangeRequests

Analysis (3) Development (4) Testing (2) Deployment (2)


Expedite (1)

Released

Agree and document how you’re using classes of service.

Post a policy statement or a color legend by your board so that people understand your classes of service, your policy for each class, and how you handle each class.

Kanban


Also, consider allocating a number of work items (tickets) to each class of service.

What percentage of the system’s total WIP is allowed in each class of service?

Capacity Allocation by Class of Service

ChangeRequests (5)

Analysis (5) Development (10)

Testing (5) Deployment (2)


ReleasedAllocation

1 = ~5%

5 = ~20%

7 = ~30%

10 = ~45%

Kanban


Think about how you classify the types of work your organization does:

● Feature enhancement requests

● Defects found in new functionality

● Internal tools development

● Updating the build server

● Customer support issues

● Customer-reported defects

● End-of-year payroll processing

Use as few classes of service as possible.

Run the system to see whether you need to introduce more.

Think about the types of work you do over a long period. Think about seasonal work, because your current work items might not accurately represent all the work you do.

Kanban


13 Common Kanban Metrics

Kanban Overview

Jenny Stuart

Common Kanban Metrics

Cumulative flow diagram (CFD) Good for seeing how well your system is flowing and the relationship between lead time, cycle time, and WIP.

Kanban


Common Kanban Metrics

Cumulative flow diagram (CFD) Good for seeing how well your system is flowing and the relationship between lead time, cycle time, and WIP.

Cycle time Often used to set service-level agreements (SLAs).

Lead time Cycle time plus the time spent in a queue before the work began.

14 Cumulative Flow Diagrams

Kanban Overview

Jenny Stuart

Kanban


A report on how well work is flowing.

Shows WIP, lead time, cycle time, flow variances, etc.

Simple Cumulative Flow Diagram

Number of Work

Items

Time

Done

Started

Queued

Lead time

Backlog

WIP

Cycle time

Long flat stretches in a CFD indicate that work in the system is not flowing well.

You want your CFD lines to be smooth and consistent, not a series of plateaus.

Kanban


You can also use the CFD to check that reducing your work in process—by setting lower WIP limits—is reducing cycle time.

You should be able to see that in the CFD.

The CFD is a great tool for spontaneous kaizen (continuous improvement) efforts and for more structured activities that happen on a regular cadence.

It also works well in non-Kanban scenarios.

Kanban


Bottlenecks and work backups show up as long flat spots followed by a big jump.

Maybe there’s too much WIP or the WIP is too big (more decomposition is needed).

Use these flat spots to find optimization opportunities.

Typical Cumulative Flow Diagram

Number of Work

Items

TimeReady to Start In Analysis & Dev In Testing Ready for Approval Ready to Deploy Deployed

Lead Time

NewTasks

Cycle Time

Backlog Size

Workin

Process

Remainingto Be Done

Kanban


How Do You Collect Data for the CFD?

Using a regular cadence, count the items in each stage of your board (e.g., backlog, analysis, dev, testing, deployment, done), keeping a spreadsheet up to date.

Doing this daily is best unless your system is moving very slowly.

Steady and continuously increasing lines indicate steady flow.

Use the CFD to see how far away you are from these smooth, almost straight lines and to zero in on problems.

Kanban


Analyze your cycle time too. Even with a steady flow, cycle time can be too long.

Use the CFD to make sure your WIP limits are decreasing your cycle time and optimizing your overall flow.

15 Cycle Time Performance

Kanban Overview

Jenny Stuart

Kanban


Displays the average amount of time a work item takes to go through the workflow.

Gathering more data allows for more metrics: lead time, per-stage cycle time.

Average Cycle Time Diagram

Average Cycle Time

Days

12

10

8

6

4

2

1-5 1-9 1-13 1-17 1-21 1-25 1-29 2-2 2-6 2-10

How to Determine Average Cycle Time

1. When a work item moves from the backlog/queue into the system’s first stage, stamp it with date or date+time.

2. Stamp it again when it exits the last stage and enters the Complete column. The time elapsed is the cycle time for that item.

3. Collect all cycle times daily (or weekly), and calculate the average.

Kanban


You can also determine cycle time for each stage by marking entry/exit times by stage.

Average cycle time is only so useful.

As an average, it doesn’t say much about your system’s stability or predictability.

Kanban


Cycle time (or lead time) distribution is much more useful.

How often is cycle time or lead time a certain number of days?

60

Cycle Time or Lead Time Distribution

Change Requests

10 20 30 40 50 70 80 90 100 110 120 130 140 150

Days

Mode

Median: 45 days

98%: 150 Days

Mean: 50 days

85%: 60 days

60

Project Management with Kanban (Part 3) – Forecasting, Blog Post by David J. Anderson

Kanban


Distribution and SLAs

Use your cycle time or lead time distribution to set appropriate SLAs.

Share the data with managers and other stakeholders to determine SLAs that make sense, based on both

their need for predictable outcomes from your system, and

your detailed understanding of what’s possible in your system.

A Few Notes on Cycle Time

High variation in work size impacts cycle time data and distribution.

Looking at the cycle time distribution is more helpful than looking at the average.

If distribution is all over the place, the system is unpredictable and optimization is both possible and recommended.

Kanban


A bimodal distribution graph show two bumps, one for small work items and another for large work items.

It’s difficult to set an SLA in this case, so changing the Kanban system makes sense.

Size-Based Lanes

Analysis Development Testing Deployment


Released

Large

Medium

Small

Kanban




● Code in Prod● Etc.

Policies by Stage

Ideas Input Queue (5) Analysis (4) Development (6)

IP Done IP Done

Deployment (2)Testing (3)

● <M T-Shirt ● Acceptance criteria approved by PO and team

● <5 story points


● Unit test suite updated, passing and 80% coverage

● Test cases written, reviewed, and passing

● Automated tests passing

Released

IP Done

Not recommended: Using average cycle time to determine an SLA.

Instead, use the cycle time distribution to

understand your system’s variation,

make sure the variation is reasonable,

help identify changes that will make your system more predictable, and

set good and informed SLAs.

Kanban


16 Additional Metrics

Kanban Overview

Jenny Stuart

If your organization is already collecting other metrics, you can continue collecting them in your Kanban system.

Kanban


Due Date Performance Performance against the SLA, which can be tracked by class of service.

This will tell you whether your system is meeting performance expectations.

Muda As a percentage or number, how many started work items weren’t delivered but were abandoned or cancelled?

If your muda count is high, consider adjusting your policy that says when a work item is ready to be worked on.

Kanban


Quality metrics Always important!

How many defects make it through and are reported to you by your customers?

How many defects do find in each stage that should have been caught earlier?

Use multiple characterizations: by priority, injected/existing, by phase, etc.

Start simply, not with lots of metrics.

Use two or three to begin with. For example: cycle time data, the cumulative flow diagram, and a quality metric.

Run the system, and determine what other data would help improve the system.

Kanban


Document and share what metrics you’re gathering, including their cadence.

Post the metrics and policies so that people can ask questions about your system.

Don’t run your system without metrics.

You’re missing a lot of opportunities for improvement if you do that.

Kanban


17 The Daily Standup in Kanban

Kanban Overview

Jenny Stuart

Operating Kanban

The Daily Standup in Kanban

Queue Replenishment

Process Improvement

We’ve covered the fundamentals of Kanban, setting up a Kanban system, and Kanban metrics. This section covers details of the daily running of your Kanban system.

Kanban



Start at the end of the board and work backward toward the first stage.

During the standup, focus on

blocked items,

items at risk of or already violating the SLA, and

other issues not captured on the board.

The point of the daily standup is to focus on how the work is flowing.

Kanban



Timeframe: Should last 10–15 minutes, no more than 20.

Large teams can do this because the standup focuses on how work is flowing, not on individuals giving reports.

18 Queue Replenishment

Kanban Overview

Jenny Stuart

Kanban


How do you replenish the input queue or backlog that feeds your system?

Kanban doesn’t prescribe an approach.

Queue Replenishment Approaches

Queue replenishment meeting A regular and structured meeting where items are identified to join the queue.

Kanban




Round-robin selection Everybody gets a turn. When a slot is available, the next person in the order picks an item to add.



Round-robin selection Everybody gets a turn. When a slot is available, the next person in the order picks an item to add.

Queue Manager This role sorts and orders the queue, perhaps working with another manager, based on input from the different stakeholders.

Kanban


Identify or create an approach that works for your environment and team.

The point is that you have an approach and that your queue remains full.

Queue Replenishment Meeting

Purpose: To select from the possible options the next most important work items for the team to start on.

Timeframe: 20–30 minutes every week, but your system might require something else.

Kanban



Participants: The set of people who need to agree on what enters the system next.

Service Delivery Manager, Product Owner, Queue Manager, or other person who facilitates the discussion.

Customer or customer reps who represent the needs of the business.

Technical staff who can assess technical risks and identify dependencies.

You know your cycle time and your SLA, so you should be asking yourself this:

“What are the items that need to be complete x days from now?”

Kanban



Common topics:

● New information about the project, release, or business

● New submissions to the option pool or a review of the “ready for engineering” buffer

● Review of available slots in the board

● Review of candidate items for class of service and necessary information

● Selection of next items to complete by some method: consensus, dot voting, etc.

Generally, the queue replenishment meeting is considered the commitment point. Selection at the meeting means the work item is committed for delivery based on the system’s SLA.

Kanban


19 Process Improvement

Kanban Overview

Jenny Stuart

Optimize your Kanban system to make it work better for your business and for the people using it.

Kanban


Plan

Understand the problem deeply.

Develop solutions.

Do

Implement solutions experimentally.

Check (Study)

Validate understanding based upon outcome of experiments.

Act

Modify processes to incorporate solutions.

Inspect and Adapt: The Deming Cycle

Kanban: From Shallow to Deep

Visualize Limit WIPImplement Feedback Loops

Evolve Incrementally Using the Scientific Method

Make Policies Explicit

Kanban


Either spontaneously (if your Kanban system is deep and mature) or in a structured way, analyze your system and do scientific experiments to make sure it is improving over time.

Two common structured feedback loops used are

the retrospective (as in Scrum) and

the more purist Kanban approach, the Monthly Operations Review.

Kanban


The Retrospective

Purpose: Reflect on how things are working and identify improvement ideas.

Timing: Monthly or biweekly—relatively frequently to achieve kaizen.

The Retrospective

Purpose: Reflect on how things are working and identify improvement ideas.

Timing: Monthly or biweekly—relatively frequently to achieve kaizen.

Timeframe: 45 minutes to 1.5 hours.

Kanban


Retrospectives

Participants: Whole team or selected team members.

Use your rich data to focus on

what is supporting and blocking flow,

a change to make to improve flow, and

what specific impact you expect to observe when you make the change.

The Monthly Operations Review

Purpose: Objective, data-driven review of organizational performance.

Timeframe: 2–2.5 hours.

Participants:

● The entire team or all teams involved in the workflow and operational context

● Senior managers from upstream and downstream teams

● Someone to show financial information on each project in progress

Kanban


Ops Review Agenda

1. Senior management presents business financials and business reality.

Ops Review Agenda


2. Management and leads share demand, capacity, and metrics: quality, CFD(s), WIP, cycle/lead time, due date perf, etc.

Kanban


Ops Review Agenda



3. Discussion, typically with a focus on workflow variation. Variability is a serious issue in software development.

Ops Review Agenda



3. Discussion, typically with a focus on workflow variation. Variability is a serious issue in software development.

4. End by choosing a small set of improvement actions assigned to managers. Review these next time.

Kanban


These approaches are structured ways of making sure that we’re thinking about how we do the work.

All organizations have many opportunities for doing the work better so that it’s more productive and less frustrating.

Make sure you have some way of doing continuous process improvement built into your Kanban system.

Kanban


20 Closing Remarks

Kanban Overview

Jenny Stuart

Welcome to Kanban Overview Jenny Stuart · the introduction of interchangeable parts. A Brief History of Lean: Whitney Artisanal manufacturing—skilled craft-persons individually

Documents