Kanban is an approach for managing work based on limiting work-in-progress to balance demand with available capacity. It is appropriate when a process suffers from overburdening or uneven flow due to factors like variability in skills, information delays, or capacity constraints. Kanban uses visualizing workflows, limiting WIP, managing flow, explicit process policies, and continuous improvement to evolve processes incrementally. While initially focused on software development, Kanban can be applied across domains as an overlay to control variability and eliminate overburdening in simple, complicated, and complex work.

1. David J. Anderson
Lean Kanban Benelux
October 2011
When is it not appropriate?
Kanban

2. Understanding Options for
Improvement

3. Goals for using Kanban
Economically balance
capability against demand

4. Available options

5. Risk Management is an
Enabling Capability…

6. Tools For Risk
Management…

7. Most process
geeks & IT
managers are
operating over
here

8. Kanban is
encouraging
collaborative
conversations with
other stakeholders
to open up options
for improvement
over here

9. Foundations of the
Kanban Method

10. Variability in Flow
My motivation for adopting
kanban systems was to
prevent muri, control mura
and encourage an evolutionary
approach to change
Overburdening

11. Appropriateness Question #1
Does your process suffer from
overburdening or
variability in flow?

12. What causes unevenness?
1. Non-instant availability of specialist skills or
collaborators
2. Information fails to arrive before it is
needed
3. Hidden/Implicit classes of service that
cause work to be interrupted to process
other work
4. Variety in work (complexity & size)
5. Changing priorities related to variety in
risks associated with work (e.g. cost of
delay)
6. Capacity constrained specialist skilled
workers or other resources (e.g. test
environments)

13. Are any of these present in your
work environment?

14. Kanban may be appropriate for you!

15. Kanban is unnecessary where demand
never exceeds capability and flow is
smooth and never interrupted!
If conditions of overburdening
or unevenness in flow exist or
are likely to then use of a
kanban system may be an
appropriate choice

16. In developing the
Kanban Method, a change
management approach that uses
kanban systems to provoke change,
we are enabling the
emergence of Lean software
development in organizations

17. The Kanban approach to change is
based on 3 principles
1. Start with what you do now
2. Agree to pursue incremental,
evolutionary change
3. Initially, respect current processes,
roles, responsibilities & job titles

18. Then…
adopt the 5 core practices
that are observed
to be present in successful
Kanban implementations

19. 5 Core Practices for Successful
Kanban Adoption
Shallow
1. Visualize
2. Limit Work-in-Progress
Depth
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively
(using models & scientific method)
Deep

20. Doing Kanban is not a question of
right or wrong …
Shallow
It’s a question of shallow
or deep!
Depth
Shallow implementations
tend to produce fewer,
less dramatic results
Deep

21. When…
all 5 core practices are adopted they
form the seed conditions for Kanban
complex adaptive
as a
system that enables a Lean(er)
way of working to emerge

22. Kanban & the Cynefin Framework

26. Observation shows
mura & muri are
present respond with
a kanban system

27. Process is defined
No feedback loop
required
Implemented in a
single transition

28. Core practices of
Kanban reveal
problems
respond with a kaizen
event

29. Scale may require
multiple dependent
kanban systems
Use of risk profiling
and classes of service

30. Process improves
incrementally
Feedback loop required
Use of existing models
Highly predictable
improvement outcomes

31. Use policies to
create a container
within the kanban
system design to
control complex
emergent behavior

32. Change kanban
system design
(policies) to catalyze
(or probe) for desired
emergent outcomes

33. Use visualization &
metrics to reflect on
outcomes, new
models emerge,
complexity is reduced

34. Complex adaptive
systems -
independent agents
following simple rules
Feedback loops
Simple rules change

35. Kanban -
Simple rules made
visual & explicit
Feedback
Kaizen events –
adapt the rules

36. Systems
(such as software
development systems)
exist in all 3
domains
simultaneously

37. Kanban is designed
to work in all 3
domains
simultaneously

38. Kanban is unlikely
to be useful in the
Chaotic domain or
in presence of
disorder

39. Kanban & Corporate Culture

44. Is your new CTO a
revolutionary?

45. Not every senior leader is a
revolutionary

46. But many feel the need to shake things
up and leave their mark
Carly Fiorina

47. Your boss may
lack the
patience to
wait for an
incremental
approach to
improvement
to take effect

48. Kanban & the Spectrum of Work

49. Kanban’s Roots

50. Kanban’s Roots
Some say Kanban’s
decoupled cadences (no
time-boxed iterations)
and single-piece flow
should make it a natural
fit for this space!

51. Kanban’s Roots
As decoupled cadences
and single-piece flow
have little benefit in this
space, it stands to reason
Kanban is not useful
here!

52. Kanban’s Roots
To think this way is to look
As decoupled cadences Some say Kanban’s
and single-piece flow at decoupled cadences (no
simplistically Kanban as a
process implementation for
have little benefit in this time-boxed iterations)
space, it stands to reason single-piece
transactional and single-piece flow
Kanban work.useful
is not To treat shoulda point a natural
it as make it
solution to a specific for this space!
here! fit problem
(within the Simple domain)

53. Kanban’s Roots
It misses the point that
As decoupled cadences Some say Kanban’s
kanban systems do not
and single-piece flow decoupled cadences (no
have little benefit in this as processiterations)
stand alone time-boxed
solutions. A kanban system
space, it stands to reason and single-piece flow
Kanban issomething that is overlaid natural
is not useful should make it a
here! an existing process space!
on fit for this

54. The metric most useful
changes at different ends of
this spectrum

55. Ideally move more
work this way
Make batch size
smaller

59. A nice mix of work
from which we’ve
been able to learn
a lot about kanban
system design

60. Leading to emergent designs with classes
of service and capacity allocation
5 4 3 4 2 2 = 20 total
Allocation Input Analysis Dev Development Build Release ...
Total = 20 Queue In Prog Done Ready In Prog Done Ready Test Ready
Change Req
[12]
Sev 1 Defect (Expedite)
[2]
Sev 2 – 5 Defect
[6]

63. Simple &
complicated
domain
application of
kanban systems.
Some doubts as
to the value of
WIP limits & pull
systems

64. Application of
Kanban Method
across Simple,
Complicated and
Complex
domains

65. Lots of
enthusiasm!
Mechanics of
decoupled
Natural territory cadences &
for Kanban single-piece flow
are seductive
But maybe not
ideal territory
for Kanban

66. Conclusion

67. Kanban
For broad application as a process overlay to
control “mura” and eliminate “muri” in the
simple/complicated domain
For broad application as a process overlay
and catalyst of process improvement in the
simple, complicated & complex domains
Most useful where demand can be treated as
a pool of options and can be shaped using
risk management, marketing strategy and
strategic planning

68. Kanban
Domain need for single-piece flow or
decoupling of planning, lead time, and
delivery;
Or, application to short-order transactional
work with small batch size and high frequency
delivery
are
Red Herrings!
Kanban works for Major Projects!

69. Kanban is for evolutionaries
Kanban maybe just
what I need!
I don’t have time for
this! Kick ass, take
names & get it done!
Carly Fiorina

70. Thank you!
dja@djandersonassociates.com
http://www.kanbaninaction.com/

71. About…
David Anderson is a thought leader in
managing effective software teams. He leads
a consulting firm dedicated to improving
economic performance of knowledge worker
businesses – improving agility, reducing
cycle times, improving productivity and
efficiency in technology development.
He has 25+ years experience in the software
industry starting with computer games in the
early 1980’s. He has led software teams
delivering superior productivity and quality using
innovative agile methods. He developed MSF
for CMMI Process Improvement for Microsoft.
He is a co-author of the SEI Technical Note,
CMMI and Agile: Why not embrace both!
David is the author of 2 books, Agile
Management for Software Engineering –
Applying the Theory of Constraints for Business
Results, and Kanban – Successful Evolutionary
Change for your Technology Business.
David is a founder of the Lean Software &
Systems Consortium, a not for profit dedicated
to promoting greater professionalism and better
economic outcomes in our industry. Email…
dja@djandersonassociates.com