Essential Kanban Condensed Guide V0.9.3
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 27
Preamble
Essential Kanban - Condensed Guide
Copyright © 2015 by Lean Kanban Inc. All Rights Reserved.
This book has been shared with you for the purpose of feedback and review.
Please do not share this le with others, nor print copies of it, without the express
permission of the authors. Access to the electronic format of this book does not
grant the right to produce printed copies of it. Printed copies can be obtained via
edu.leankanban.com.
Edition: Draft 0.9.3 Date: 14th November 2015
About this guide
This guide provides a distillation of the “essence” of Kanban - what it is and how
it can be used - in a condensed form. It is the summary of a fuller guide, Essential
Kanban Guide, which is still to be published (Anderson, 2016a).
About Draft 0.9.3
Some feedback from initial drafts of the Condensed Guide requested more detail
or diagrams to explain the key concepts. For the most part we have prioritized
brevity over completeness in this guide, because the full guide is where the further
explanation will appear. However since this draft is being distributed for review
before the full guide is available, we have included some material here that will in
due course migrate to the full guide. This will eventually enable the Condensed
Guide to be the short summary of concepts in the briefest form.
David J Anderson, Seattle, WA
Andy Carmichael, Southampton, UK
Conventions
The Glossary contains the denitions of a number of commonly used terms that
are used in Kanban. At least the rst time a term in the Glossary appears in the
text of the Guide it is highlighted, e.g. Delivery Rate.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
2
What is Kanban?
Kanban is a method for dening, managing and improving services
delivering knowledge work, such as professional services, creative
industries and the design of physical and software products.
The method is based on the concept of a kanban system - a delivery
ow system that controls the amount of work in progress using visual
signals.
The visual signals are referred to as kanbans1. They prevent too much or
too little work entering the system, thereby improving the ow of value to
customers. The kanbans, and the policies associated with them, create a
pull system, where work is “pulled” into the schedule when other work is
completed, rather than “pushed” when new work is requested.
The focus of Kanban is the delivery of services by an organization - one or
more people collaborating to produce (usually intangible) work products.
A service has a customer, who requests the work or whose needs are
identied, and who accepts or acknowledges delivery of the completed
work. Even where there is a physical product from services, value resides
less in the physical item itself, and more in its informational content (the
software, in the most general sense).
Kanban Values
Kanban is a values-led method. It is motivated by the belief that respecting
all the individuals that contribute to a collaborative enterprise is necessary,
not only for the success of the venture, but for it to be worthwhile at all.
Kanban’s values may be summed up in that single word “respect”. However
it is useful to expand this into the set of nine values2 (including respect)
that encapsulate why the principles and practices of Kanban exist:
1 The plural of kanban in Japanese is kanban, however we use the plural “kan-
bans” in this English text.
2 (Burrows, 2014)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
3
1. Transparency: the belief
that sharing information
openly improves the ow
of value. Using clear and
straightforward vocabulary is
part of this value.
2. Balance: the understanding
that different aspects,
viewpoints and capabilities
must be balanced with each
other for effectiveness. Some
aspects (such as demand and
capacity) will cause breakdown
if they are out of balance for an
extended period.
3. Collaboration: working
together. The Kanban method
was formulated to improve the
way people work together, so
collaboration is at its heart.
4. Customer Focus: knowing
the goal for the system. Every kanban system ows to a point
of realising value - where customers receive a required item or
service. It is the natural point of focus in Kanban.
5. Flow: the realisation of work as a ow of value, whether continuous
or episodic. Seeing ow is an essential starting point in the use of
Kanban.
6. Leadership: the ability to inspire others to action through example,
words and reection. Most organisations have some degree of
hierarchical structure, but leadership is needed in Kanban at all
levels to achieve value delivery and improvement.
7. Understanding: primarily the self-knowledge of oneself and one’s
organisation in order to move forward. Kanban is an improvement
method, and knowledge of one’s starting point is foundational.
8. Agreement: the commitment to move together towards goals,
respecting and where possible accommodating differences of
opinion or approach. This is not management by consensus but a
dynamic co-commitment to improvement.
9. Respect: valuing, understanding and showing consideration for
people. Appropriately at the foot of this list, it is the foundation on
which the other values rest.
These values embody the roots of Kanban in seeking to improve services
delivered by collaborating teams. The method cannot be applied faithfully
without embracing them.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
4
The Foundational Principles of Kanban
There are six foundational principles of Kanban which may be divided into
two groups: the change management principles and the service delivery
principles.
The three change management principles of Kanban are
1. Start with what you do now
○ understanding current processes, as actually practiced
○ respecting existing roles, responsibilities, and job titles
2. Agree to pursue improvement through evolutionary change
3. Encourage acts of leadership at every level, from individual
contributor to senior management
The three service delivery principles of Kanban are
1. Understand and focus on your customers’ needs and expectations
2. Manage the work; let people self-organize around it
3. Your organization is an ecosystem of interdependent services,
steered by its policies; reect regularly on their effectiveness and
improve them.
Describing Flow Systems
Kanban is used to dene, manage and improve systems which deliver
services of value to (internal or external) customers. As Kanban is applied
principally to knowledge work, where the deliveries consist of information
in various forms rather than physical items, the processes can usually be
dened as a series of knowledge discovery steps, and associated policies,
such as shown in a diagram like this, depicting a ow system where work
items ow through various stages of a process, ordered in this case from
left to right.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
5
As well as visual signals to limit work in progress, kanban systems have
identied commitment and delivery points.
The commitment is an explicit or tacit agreement between customer and
service that:
1. the customer wants an item and will take delivery of it, and
2. the service will produce it and deliver it to the customer.
Before the commitment point there may be a set of outstanding requests
(or a pool of ideas) which may or may not be selected, and a process which
has the purpose of selecting items from these options. Kanban applied
to processes prior to the commitment point is sometimes referred to as
Discovery Kanban3. The delivery point is where items are considered
complete.
The time that an item is in process between the commitment and delivery
points is referred to as the Lead Time for the item.
The number of items that are within the system under consideration at any
point in time is known as the Work in Progress or W i P.
The rate at which items are being delivered is known as the Delivery
Rate. This is calculated from the reciprocal of the time between the latest
delivery and the one before or, for an average Delivery Rate over a given
period, by dividing the number of deliveries by the length of the time period.
In a ow system that is not trending4 (and in which all items that are
selected are delivered) there is a simple relationship between the average
3 Or “Upstream Kanban”. See (Steyaert, 2014).
4 Or between two consecutive points of zero WiP.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
6
of these metrics over a specic period. It is known as Little’s Law5:
Delivery Rate =
The overline denotes arithmetic mean.
We may wish to use Little’s Law to examine the ow metrics of other
parts of a kanban system - not just between the commitment and delivery
points - in which case rather than Lead Time, use Time in Process or
TiP6 for the period an item is in the process under consideration. More
specic terms such as Time in Development, Time in Test, Time in System
or Time in Queue may also be used.
The term Throughput is used rather than Delivery Rate if the end of the
process under consideration is not the delivery point7.
An alternative formulation of Little’s Law using these terms is thus:
Throughput =
Little’s Law provides an important insight into kanban systems: in order
to optimize the Lead Time for work items, we must limit the Work in
Progress. This is one of the Core Practices of Kanban.
The Core Practices of Kanban
The Core Practices of Kanban dene essential activities for those
managing kanban systems. There are six of them:
1. Visualize
2. Limit work in progress
3. Manage ow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally
5 (Little, 1961)
6 (Maccherone, 2012). Note some authors use Cycle Time (CT2) for this quan-
tity. See the Glossary for the denitions of CT1 and CT2, and an explanation of
why Cycle Time is not a recommended term in the Kanban method.
7 A further distinction may be drawn between Throughput and Delivery Rate
even if the point at which it is measured is identical. Throughput includes all items
that depart from the system under consideration, whether they were delivered,
aborted/discarded, or moved back to a point prior to the system under consider-
ation.
WiP
Lead Time
WiP
TiP
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
7
These practices all involve:
● seeing the work, and the policies that determine its processing;
then
● improving the process in an evolutionary fashion - keeping and
amplifying useful change; reversing and learning from ineffective
change.
Visualize
A Kanban Board such as in the
diagram above is one, though not the
only way, to visualize work and the
process it goes through. For it to be
a kanban system rather than simply
a ow system, the commitment and
delivery points must be dened, and
visual signals (kanbans) must be
visible to limit the work in progress
at each stage between these points.
The act of making work and policies
visible, whether through a wall board,
electronic displays or other means, is
an important journey of collaboration
to understand the current system and
nd potential areas for improvement.
Policies too are important to visualize,
for example by placing summaries
between columns of the what must be done before items move from one
column to the next.
Board Design varies greatly between kanban systems depending on
their context of use. It is not part of the method to constrain how they
are designed. Software tools designed to support Kanban may introduce
practical constraints, for example the common pattern of a two dimensional
grid, with panels displaying information about each work item. The
columns represent steps in a process, and some of the columns have
horizontal partitions (called swimlanes, if they cross two or more columns)
to distinguish states of items within the steps. However it is interesting
to note that physical boards without such constraints often nd other
creative ways to display information of importance to the team, as well as
connections to the boards of other services.
Design of the card or panel that describes the work item is another
important aspect of visualization. It is also vital to highlight visually when
items are blocked by dependencies on other services or for other reasons.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
8
Limit work in progress
Introducing and respecting limits on WiP changes a “push” system into
a “pull” system, where new items are not started until work is completed,
or on rarer occasions abandoned. Too much partially complete work is
wasteful and expensive, and crucially it lengthens lead times preventing
the organization from being responsive to changing circumstances and
opportunities.
Observing, limiting and then optimizing the amount of work in progress is
essential to success with Kanban, as it results in improved lead time for
services, improved quality and a higher rate of deliveries.
By contrast ineffective management behavior focuses on maximizing
usage of people and resources, by trying to ensure that everyone is “busy”
with a ready supply of work so that no idle time occurs. As a result people
may feel overwhelmed with the amount they have to do, only accept tasks
they have been explicitly instructed to carry out, and lose sight of the
service they provide and how it contributes to the overall goals of the
organization and its customers
Manage ow
The ow of work in a kanban system should maximize the delivery of value,
minimize lead times, and be as smooth (predictable) as possible. These
are sometimes conicting goals and, since the deliverables are usually
complex, empirical control through transparency, inspection and adaption
is required. Bottlenecks, where ow is constrained by one particular sub-
process, and blockers, where there are dependencies on other services,
are particularly important to take note of and manage
The relationship with the consumers of the service, the customers, is a
key aspect of managing ow. Different service levels may be dened for
kanban systems to guide this:
● ServiceLevelExpectation: what the customer expects
● Service Level Capability: what the system can deliver
● Service Level Agreement: what is agreed with a customer
● Service Fitness Threshold: the service level below which the
service delivery is unacceptable to the customer.
Make policies explicit
Explicit policies are a way of articulating and dening a process that
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
9
goes beyond the workow denition. A process expressed as workow
and policies creates constraints on action, is empowering within the
constraints, and results in emergent characteristics that can be tuned by
experiment. The process policies need to be sparse, simple, well-dened,
visible, always applied, and readily changeable by those providing the
service.
The behavior of complex systems, though they may be guided by simple
policies, is not possible to predict with certainty. What may appear as
intuitively obvious policies (e.g. “the sooner you start, the sooner you’ll
nish”), may produce counterintuitive results. For this reason it is a core
practice to make the policies that apply to services explicit, and also for
there to be a visible and straightforward mechanism to question and
change policies when they are considered counter-productive.
WiP Limits are one type of policy. Others include capacity allocation and
balancing, the “Denition of Done” or other policies for work items exiting
stages of a process, and replenishment policies for the selection of new
work when capacity is available. The use of classes of service is another
policy example.
Implement feedback loops
Feedback loops are an essential part of any controlled process and
particularly important for evolutionary change. Improving feedback in all
areas of the process is important.
Kanban denes seven specic feedback opportunities, or cadences.
Cadences are the cyclical reviews that drive evolutionary change
and effective service delivery8. The seven cadences are shown in the
accompanying diagram with suggested frequencies for the reviews in
typical systems:
1. Strategy Review: dening in context the concept of “t for purpose”
and sensing the external environment, in order to provide direction
to services
2. Operations Review: understanding the balance between and
across services, deploying resources to maximise the delivery of
value to customers’ expectations
3. Risk Review: for understanding risks to effective delivery of
services, for example through blocker clustering
4. Service Delivery Review: examining and improving the
effectiveness of a service (this and subsequent cadences apply
8 Cadence may also refer to the period between reviews, for example one
working day or one month.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
10
to a single service)
5. Replenishment Meeting: for moving items over the commitment
point, and overseeing the preparation of options for selection in
the future
6. The Kanban Meeting: the (usually) daily coordination, self-
organization and planning review for those collaborating to deliver
the service. It often uses a “stand-up” format to encourage a short
energetic meeting with the focus on work item completion and
unblocking issues.
7. Delivery Planning Meeting: monitoring and planning deliveries to
customers
Implementing the seven cadences does not imply adding seven new
meetings to an organization’s overhead. Instead the reviews and meetings
should initially be part of existing meetings and adapted in context to fulll
their goals. At smaller scale, a single meeting may cover more that one of
the cadences.
There are ten feedback loops in the cadence network diagram, showing
information ow and requests for change between the reviews. These
facilitate decision-making at each level.
Improve collaboratively, evolve experimentally
Kanban is fundamentally an improvement method. Often transformation
programmes are started with the aim to change processes to a new
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
11
predened approach. In contrast Kanban starts from the organization as
it is now and uses the lean ow paradigm (seeing work as a ow of value)
to pursue continuous and incremental improvement. There is no end point
of such change processes since perfection in an ever-changing tness
landscape is unattainable. Kanban harnesses an evolutionary process to
allow benecial change to occur within an organization, protecting it from
another natural process in evolution, extinction. Organizations cannot opt
out of evolution. It either works for them or happens to them. But they can
choose to encourage the change to occur within, rather than nding it is
unable to respond to existential threats from without. Kanban facilitates
this.
The evolutionary process involves: copying with differences; selecting for
tness; keeping and amplifying useful change while rejecting or reversing
ineffective change.
Sometimes it is useful to use models, and the scientic method to validate
or invalidate the application of the models in context. Sometimes using
empirical and pragmatic approaches is appropriate, to nd the greatest
tness for purpose with the current environment.
Introducing Kanban to Organizations
It is straightforward to start using Kanban: recognize that your work
involves a ow of value from the request for an item to its delivery to your
customer; visualize the work and the process for delivering the work; then
continually improve the process by applying the values, the principles and
the practices9.
All through this process you will be applying Kanban, even while the
characteristics of your systems are barely different from your starting
point. Clearly this means there are organizations applying Kanban that do
not yet even have a kanban system (a system that limits work in progress
with visual signals), or whose kanban systems have not yet matured,
for example to an effective balancing of demand with capability through
feedback loops, or optimal value delivery through classes of service.
Such systems may be referred to as protokanban systems since they
are systems being transformed by Kanban, though not yet compliant
with all of its practices. Protokanban systems can bring great benet to
organizations - for example in making work visible - but they should not be
viewed as end-points in process transformations.
9 (Carmichael, 2013)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
12
For these reasons the Kanban method denes an approach for introducing
Kanban (STATIK) and a test for assessing your progress with Kanban (the
Litmus Test).
Systems Thinking Approach to Introducing Kanban
(STATIK)
Systems Thinking10 is a way of understanding how a system behaves as a
whole rather than through analysis of component parts in isolation. It is a
key inuence in the denition of the steps needed to introduce Kanban in
an organization. The steps in this process are not necessarily sequential,
but iterative, using learning from one step to inform and inuence the
others in a collaborative environment. The steps are
Step 0: Identify Services
For each service…
Step 1: Understand what makes the service t for purpose
for the customer
Step 2: Understand sources of dissatisfaction with the
current system
Step 3: Analyze demand
Step 4: Analyze capability
Step 5: Model workow
Step 6: Discover classes of service
Step 7: Design the kanban system
Step 8: Socialize the design and negotiate implementation
STATIK is applicable to just one service. When more than one service
has been set up, Kanban practices and cadences are applied to balance
demand and ow across the multiple services, and continually improve.
The ordering of the steps may vary in practice and it is normal to revisit
steps in the pursuit of further improvement.
The Kanban Litmus Test
The Kanban Litmus Test is designed to help organizations assess
their progress with Kanban and suggest areas that may yield effective
improvements. It consists of a series of questions in four groups, where
the lower numbered questions are pre-requisites for those that follow.
1. Establishing a kanban system
a. Is the customer interface (the approach to scheduling and
selecting customer requests for service) based on a pull
10 See for example (Meadows, 1972).
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
13
system with limited work in progress?
b. Are the commitment and delivery points clearly dened
and records available of Lead Times and Delivery Rates?
2. Service Delivery
a. Does the relationship with the customer allow commitments
to be made based on a service level agreement or
understood service level expectation?
b. Are these commitments based on probabilistic
forecasting of the kanban system’s observed Lead Times
and Delivery Rates?
3. Value and risk management
a. Does the service delivery business model use classes
of service appropriately, based on an understanding of
business risks (for example the cost of delay) to facilitate
selection decisions and inspire queuing discipline policies
for work items? Are you understanding clusters of customer
expectations and probing for new classes of service?
b. Is there capacity in the system to hedge risks from different
sources of demand and different types of work, for example
by diverting resources to priority tasks in periods of high
demand?
c. Are interdependent services aggregated and coordinated,
to increase system liquidity and enable system leveling in
the light of risks and variability?
4. Management behavior
a. Is management behavior consistent with the deferred
commitment pull system approach of Kanban?
b. Are WiP limits respected by management at system level,
not just at personal level (such as per person WiP limits to
reduce multi-tasking)?
Kanban Roles
Kanban is and remains the “start with what you do now” method, where
initially no one receives new roles, responsibilities or job titles. So there
are no required roles in Kanban and the method does not create new
positions in the organization. However two roles have emerged from
common practice in the eld and are now dened in the method itself. It is
the purposeof the roles that is important, rather than assigning someone
to a job title, so it may be helpful to think of the roles as “hats” people wear
in carrying out these functions.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
14
The two roles are:
● Service Request Manager: responsible for understanding the
needs and expectations of customers, and for selecting and
ordering work items accordingly (alternative names for the role:
Product Manager, Product Owner, Service Manager)
● Service Delivery Manager: responsible for the ow of work in
delivering selecting items to customers (alternative names for the
role: Flow Manager, Delivery Manager or even Flow Master)
Forecasting and Metrics
Forecasting accurately when services will be delivered to customers has
long been a difcult management problem. Two methods of forecasting are
considered: “effort-plus-risk estimating” and probabilistic forecasting.
Effort-plus-risk approaches operate by breaking down a large piece of
work (like a project) into very small items, and then summing the effort
estimates for these small items. Either an acceptable date or the team
size is agreed, and the other variable determined by ensuring the product
of the required lead time and team size is larger than the estimated effort
by a sufciently large factor to account for risks and prot. Often this
involves a “risk factor” of between 2 and 10. This method has often proven
spectacularly unsuccessful on all sizes of project, but particularly large
and critical ones. It is surprising it still is the dominant method of running
projects.
Kanban systems, once established, provide the opportunity for an
alternative approach based on the ow of value (encapsulated in smaller
work items than typical projects), delivered through established teams.
Probabilistic forecasting works by using a simple model of existing,
or similarly structured new teams, where some data has already been
gathered on item size variability, lead times and delivery rates. Using a
Monte Carlo method11, which runs scenarios multiple times, percentage
likelihood of a range of completion dates can be generated. Providing this
to planners encourages a better approach to balancing cost and risk with
schedules and commitments.
Designing appropriate service level agreements with customers is also
enabled by collecting actual data from kanban systems and applying
statistical analysis and probabilistic forecasting.
11 (Magennis, 2011)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
15
Flow systems can provide a wide range of ow metrics which are important
to the managers of these systems12. The minimum starting point is to
collect data on Lead Time, Delivery Rate, WiP and cost (usually primarily
the effort in person-days consumed by the service).
A Run Chart: showing a scatter plot of
the Lead Time for items on their delivery dates
Important types of graphs for monitoring ow systems include: scatter
plots of Lead Times - Run Charts - and charts showing the cumulative
number of arrivals and departures of items from a process, or parts of a
process - Cumulative Flow Diagrams (CFDs).
A Cumulative Flow Diagram: showing the cumulative
number of items committed and delivered by date
12 See for example (Vacanti, 2015)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
16
Expanding the Application of Kanban
How do you scale Kanban? There is a simple answer to this question: by
applying Kanban in a context of greater scale.
Once kanban systems are established for one or more services, consider
three dimensions in which they can grow in your organization.
Width-wise growth: Encompass a wider scope of the lifecycle
of the work items by upstream and downstream expansion of the
end-to-end workow. For example, if the original service modeled
only the development team’s process, exploring what happens
before the items enter development, and after the team consider
that the items are “done”, will result in a wider scope of the process,
and potentially more effective areas for improving the service to
customers.
Height-wise growth: Consider the hierarchy of items that make
up deliveries, each level of the hierarchy potentially having
differing ow characteristics. For example a “user story” is a small
part of the functionality of a software product “feature”. Features
may be considered as part of a software release. Kanban may
be used at each of these levels with differing workows and
policies at each level . This dimension uses the “scale-free” nature
of Kanban - the same principles and practices apply whatever
the size of the work item, even though the nature of work at the
different scales results in very different systems and policies.
Four specic levels are often identied:
1. Personal - use of PersonalKanban13 for an individual or
small team to foster efcient and effective working
2. Team - understanding the team’s work as a service and
applying Kanban practices to optimise predictable ow of
value
3. Product - Product management requires effective
management of options for enhancements, and ow of
customer-valued changes for competitive advantage. The
work items should be considerably larger than at the team
level, but much smaller than typical projects.
4. Portfolio - Kanban can support the investment level
decisions concerning which new and existing projects
need greater or less capability/capacity to deliver change.
Portfolio management is therefore not a variant of project
13 (Benson, 2011)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
17
management with much bigger projects, but a completely
different discipline more aligned with the management of
nancial portfolios.
Depth-wise growth: A deep implementation of Kanban needs
not only greater depth of understanding, but depth of penetration
through the full set of services required by the organization to
deliver value. Depth-wise growth connects multiple services at
the same level through feedback loops (cadences) that balance
the capacity across the services. Services may provide a specic
function (legal, IT, or accounting services for example) or be aligned
around the deliveries that require widely differing skillsets within
them (new product development, or lm and television services)
but the challenge in the extended Kanban ecosystem is to achieve
balance and ow across all the interdependent services.
A note of caution - the values, principles and practices are dened in
summary in a scale-free manner. However examples, explanations and
advice may well be tailored to specic assumptions concerning scale and
context. The complexity is always greater at larger scale so particular
care must be taken not to carry over assumptions from one scale to a
larger one, or indeed between differing contexts of ow systems with very
different characteristics.
An important recent development in the evolution of Kanban and its
application across large organizations is Kanban Enterprise Services
Planning (Kanban ESP). This has a management training syllabus to
provide managers with the knowledge and condence to apply Kanban in
networks of potentially hundreds of interdependent services. While Kanban
ESP is outside the scope of these guides, they do provide foundational
material for Kanban ESP.
Learning More About Kanban
This condensed guide summarizes the principal elements of Kanban
which are dened and explained in more depth in the companion volume
Kanban: The Essential Guide (Anderson, 2016a).
The goal of the guides is to provide the essence of the method in a
compact and accessible form, and to point the way forward for students of
the method to discover more and participate in its ongoing evolution. What
follows is a list of the publications that complete the current denition of
the method, including rationale, examples and case studies.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
18
The seminal publication on the method, Kanban–successfulevolutionary
change for your technology business (Anderson, 2010 and 2016b),
provides the background, examples and rationale for the practices of
the method. It is an essential companion to the guides. Kanban From
the Inside (Burrows, 2014) denes, amplies and explains the values
of Kanban and how its principles and practices ow from them. It also
usefully tracks inuences and sources for many of Kanban’s practices,
and discusses its relation to other approaches such as Lean, Theory
of Constraints and Agile. Kanban Change Leadership (Leopold, 2015)
explains how to establish a culture of continuous improvement in Kanban
implementations. CoachingKanban (Anderson, 2016c) provides feedback
from a number of signicant implementations of Kanban with commentary
from leading coaches of the method. Together these materials provide the
foundational knowledge base for those wishing to understand the method.
In addition to these sources, the full guide (Anderson, 2016a) has a more
extensive bibliography of the many books describing current Kanban
practice and the principal sources and precursors of the Kanban method.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
19
References
Anderson (2010) David J. Anderson, Kanban–SuccessfulEvolutionary
ChangeForYourTechnologyBusiness, Blue Hole
Press.
Anderson (2015) David J. Anderson, Lean Kanban Incorporated.
Kanban Enterprise Services Planning: Scaling the
BenetsofKanban. London Limited WIP Society,
October 2015. http://www.slideshare.net/agilemanager/
enterprise-services-planning-scaling-the-benets-of-
kanban-54207714
Anderson (2016a) David J. Anderson and Andy Carmichael, Essential
Kanban. To be published. Lean Kanban University
Press.
Anderson (2016b) David J. Anderson, Kanban–SuccessfulEvolutionary
ChangeForYour21stCenturyOrganization. 2nd
Edition. To be published. Blue Hole Press.
Anderson (2016c) David J. Anderson, ed. CoachingKanban. To be
published. Blue Hole Press.
Benson (2011) Jim Benson and Tonianne DeMaria Barry. Personal
Kanban:MappingWork,NavigatingLife. Seattle, WA:
CreateSpace Independent Publishing Platform.
Burrows (2014) Mike Burrows. KanbanfromtheInside:understandthe
KanbanMethod,connectittowhatyoualreadyknow,
introduceitwithimpact, Blue Hole Press.
Carmichael (2013) Andy Carmichael, ShortestPossibleGuidetoAdopting
Kanban. Improvingprojects. http://xprocess.blogspot.
co.uk/2013/05/how-to-adopt-kanban.html.
Hopp (2005) W.Hopp and Mark L. Spearman. 2005. FactoryPhysics.
3rd ed. United States: McGraw Hill Higher Education.
Leopold (2015) Klaus Leopold and Siegfried Kaltenecker, Kanban
ChangeLeadership:CreatingaCultureofContinuous
Improvement, Wiley.
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
20
Little (1961) Little, John D. C. AProoffortheQueuingFormula:L=
ΛW. OperationsResearch 9(3): 383–87.
Maccherone (2012) Larry Maccherone. IntroducingtheTimeInStateInSITe
Chart. http://maccherone.com/publications/LSSC2012-
IntroducingtheTimeInStateInSITeChart.pdf. Carnegie
Mellon University, LSSC.
Magennis (2011) Troy Magennis. ForecastingandSimulatingSoftware
DevelopmentProjects. www.focusedobjective.com,
Focused Objective.
Meadows (1972) Donella H. Meadows, Dennis L. Meadows, Jørgen
Randers and William W. Behrens III. The Limits to
Growth. Universe Books.
Reinertsen (2009) Donald G. Reinertsen, ThePrinciplesofProduct
DevelopmentFlow, Celeritas Publishing.
Shook (2014) John Shook and Chet Marchwinski, eds. LeanLexicon:
AGraphicalGlossaryforLeanThinkers. 5th Edition.
United States: Lean Enterprise Institute, Inc.
Steyaert (2014) Patrick Steyaert. DiscoveryKanban. Okaloa.
http://www.discovery-kanban.com
Vacanti (2015) Daniel S. Vacanti. ActionableAgileMetricsfor
Predictability:AnIntroduction. Leanpub.
Wikipedia (2015) MonteCarloMethod. 2015. Wikipedia.
https://en.wikipedia.org/wiki/Monte_Carlo_method
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
21
Glossary
Abort: To discard a work item after the commitment point.
Alternatives: abandon.
Related terms: commitment point, discard
Blocker clustering: A risk analysis technique using records of issues that have
blocked work items, and grouping them by common cause.
Cadence: A review providing feedback from one or more services. Cadence
may also refer to the time period between reviews.
Classes of service: categories of work item that may warrant different policies
for selection and processing based on different relative value, risk or cost of
delay.
Commitment point: the point in a kanban system at which the commitment is
made to deliver a work item. Before this point work done supports the decision
whether or not to deliver the item. After this point it has been conrmed that
the customer wants and will take delivery of the item, and that the service will
deliver it.
Related terms: abort, discard
Cost of delay: a measure of the impact of delaying an item14. May also refer to
cost of delay rate (cost per unit of time).
Measured in: monetary currency, units of effort (e.g. person-days)
Cumulative Flow Diagram (CFD): a chart showing the cumulative number
of arrivals and departures from a process, or parts of a process, over a time
period.
Cycle Time (CT1, CT2): The time taken for a “cycle”. This is an ambiguous term
which should not be used in Kanban without qualication or further denition.
It may be applied to the time between two items emerging from a process15
(CT1), for example the period between releases of new builds of software, or to
the time between starting and completing an item16 (CT2), for example the time
taken to develop a product feature.
Measured in: units of time
Alternatives: For CT1 use its reciprocal - Delivery Rate or Throughput; for CT2
use Lead Time or Time in Process
Deferred commitment: separating the request for work from the commitment to
do work, so that the system operates as a pull system.
14 (Reinertsen, 2009)
15 Lean Lexicon (Shook, 2014)
16 FactoryPhysics (Hopp, 2005)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
22
Delivery point: the point at which an item is considered to be delivered or
complete.
Related terms: commitment point
Delivery Rate: The number of work items emerging complete from the system
per unit of time.
Measured in: work items per unit of time
Alternatives: Completion Rate
Related terms: Throughput
Discard: To stop work on an item and remove it from the process. Note that
an item is “discarded” in this sense even if it might be worked on in the future,
for example if the work item is moved back to a queue prior to the process
under consideration. The term is not specic about when in the process the
item is discarded, however in a kanban system it applies particularly to items
discarded prior to the commitment point, since after this point the term abort
is applicable.
Related terms: abort, commitment point
Discovery Kanban: the application of Kanban to nding the most
advantageous work to do in the context of innovation and change17.
Alternative: Upstream Kanban
Fitness landscape: a term borrowed from evolutionary biology to visualize, as
a multi-dimensional landscape, the tness of an entity with different traits to the
prevailing environment.
Flow system: a system characterised by the entry and departure of items. It is
a way of viewing knowledge work and the ow of items from the request or idea
through to delivered value.
Kanban (1): a method for the denition, management and improvement of
services that deliver knowledge work.
Alternative: The Kanban Method
Kanban (2): a kanban is a visual signal that is used in kanban systems to limit
work in progress.
Kanban ESP: Kanban Enterprise Services Planning18 an approach to the
management of large networks of services, applying Kanban at each level of
management and within each service.
Kanban system: a kanban system is a ow system with dened commitment
and delivery points, and with kanbans that limit work in progress.
Knowledge work: work that is primarily using and developing knowledge.
17 DiscoveryKanban (Steyaert, 2014)
18 Anderson (2015)
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
23
Lead Time: the elapsed time it takes for a work item to move from the
commitment point to the delivery point.
Measured in: units of time
Related terms: Time in Process (TiP)
Little’s Law: a simple relationship between the attributes of queues and ow
systems. For kanban systems it may be expressed as:
Delivery Rate = or as
Throughput =
where the overline indicates the arithmetic mean over a period. The system
must be statistically “stationary” for the period, or between two consecutive
points of zero WiP.
Monte Carlo methods: a broad class of computational algorithms that rely on
repeated random sampling to obtain numerical results. (Wikipedia, 2015)
Options: options represent the right - though not the obligation - to carry out
an action or use a resource. Like nancial options they have value and an
expiration period during which their value reduces to zero. They are important
in Kanban since work items before the commitment point represent options of
this type.
Alternatives: Real options
Probabilistic Forecasting: An approach to forecasting outcomes from a ow
system, using data of previous delivery rates and lead times combined with a
Monte Carlo or similar method.
Protokanban: refers to a ow system or process where the Kanban method
is being applied, but which does not yet show characteristics of a mature
system, for example where work in progress is not controlled between the
commitment and delivery points.
Pull system: a method of scheduling work only when capacity exists to
complete it, in contrast to scheduling it as soon as work is requested.
Run Chart: a scatter plot of Lead Times with data points representing the Lead
Time of items on their delivery date.
Alternatives: Control Chart
Service: one or more people collaborating to produce (usually intangible)
work products for a customer, who requests the work, and who accepts or
acknowledges delivery of the completed work.
Throughput: the number of work items exiting from the system per unit of time,
whether completed or discarded.
WiP
Lead Time
WiP
TiP
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
24
Measured in: work items per unit of time (e.g. items per working day)
Alternatives: Throughput Rate, Departure Rate, Processing Rate
Related terms: Delivery Rate
Time in Process (TiP): the time that a work item remains in the system or sub-
process under consideration prior to being either completed or discarded. More
specic terms may be derived by replacing “Process” with the particular part of
the process of interest, for example TimeinDevelopment, Time in Test, Time in
Queue.
Measured in: units of time
Alternatives: Lead Time (when referring to the time in process from the
commitment to delivery point), Time in System
Related terms: Cycle Time (CT2), Lead Time
Work in Progress (WiP): the number of work items which have entered the
system but which are not yet either completed or discarded.
Measured in: count of work items
Related terms: Throughput, Delivery Rate, TiP
Uncorrected Proof. For review purposes only. Do not excerpt or distribute without written consent. v0.9.3
25
About The Authors
David J Anderson
@lki_dja
dja@leankanban.com
David J Anderson is an innovator in management
thinking for 21st Century businesses. He leads a
training, consulting, events and publishing business
making new ideas accessible to managers across the globe. He has 30+
years experience in the high technology industry starting with games in
the early 1980s. He worked at IBM, Sprint, Motorola & Microsoft as well
as a number of startup businesses. He is the pioneer of both the Kanban
Method and Enterprise Services Planning.
David is the author of three books: Kanban – Successful Evolutionary
ChangeforyourTechnologyBusiness; LessonsinAgileManagement:On
theRoadtoKanban, and AgileManagementforSoftwareEngineering–
ApplyingtheTheoryofConstraintsforBusinessResults.
Andy Carmichael
@andycarmich
andycarmichaeluk@gmail.com
Andy Carmichael is a coach, consultant and
business builder who has been at the forefront of
process change in software development teams
for many years. His clients include major players in nance, software
engineering, utilities and telecoms - as well as a number of startups and
SMEs - all of whom share the goals of gaining competitive advantage
through increased business agility. He is active in the Kanban and Agile
communities and is a Kanban Coaching Professional.
Andy has edited and co-authored three books: Object Development
Methods, DevelopingBusinessObjects and BetterSoftwareFaster. When
not engrossed in technical work, he enjoys singing, golf and entertaining,
particularly when his large grown-up family comes home to visit.
Copyright © 2015 by Lean Kanban Inc. All Rights Reserved.
edu.leankanban.com
