Getting to pull at enterprise scale

Copyright Lean Kanban Inc.Email: dja@leankanban.com Twitter: @LKI_dja
True Business Agility
Getting to “pull” at enterprise scale
Presenter
David J. Anderson
Lean Kanban Central
Europe
Hamburg, Germany
November 2016

Kanban is Ubiquitous!

Acceptance
11 years later no one is arguing that Kanban isn’t
appropriate in professional services work
Companies everywhere, large and small, are simply
doing it!
So, it’s time to declare victory! We’ve won the
argument that Kanban is a good idea!

China
3 Chinese companies have “very large scale” Kanban
implementations
 Huawei – Telecoms & electronics – 5000+ people
 Ping An – Insurance & banking – 5000+ people
 CMB – Banking – 3000+ people
Meanwhile in Europe…
 Large scale has been seen at Ericsson, Skania, Siemens,
Rolls-Royce, BBVA, Odigeo (eDreams, Opodo) and others

Return on Investment
Implementations at Huawei, Ping An & CMB have
each cost around the equivalent of 3 full time
employees salaries
Huawei are seeing improvements in productivity in
the range of 10-50% with an average of 25% across
more than 10 product units
Improvements at Huawei are the equivalent of 1250
engineers they didn’t need to hire
Return on investment is 300->400:1 or >30,000%

Don’t miss it!
Adam Wu at 17h20
“Ping An China Insurance & Services” Case Study
Kanban across 5000 people
What did it cost?
What has it meant for company performance,
enterprise agility and robustness to disruptive
fintech?
 Particularly release frequency of mobile financial
applications

No Harm!
While there have been failed Kanban
implementations, there are no stories of Kanban
doing harm to organizations
Unlike some Agile methods and other management
fads such as holacracy, there are no stories of Kanban
causing 20%-40% staff turnover or inflicting brutal
and cruel change
There has been tribal, emotional push back in
organizations where Agile is a religion

But wait, it’s not Kanban!
The problem with this ubiquitous and virtuous
adoption of Kanban is that it isn’t really Kanban at
all!

Kanban at Microsoft 2005
Virtual Kanban “pull” system – No visual boards!
230% productivity improvement
91% reduction in average lead time
On-time performance up from 0% to 98%
Time frame – 15 months
Cost – almost nothing, no coaching fees, no training,
no consultants, 2 permanent team members added
mid-transformation taking productivity from 150%
improvement to 230% improvement

Kanban at Hewlett-Packard 2006
Virtual Kanban “pull” system – no visual boards!
700% productivity improvement!
Lead time on new generation of laser printer
firmware dropped from 21 months to 3.5 months
4.5 day working week
Timeframe – less than 1 year
Cost – almost nothing – no coaches, no training, no
consultants

Proto-Kanban represents minor league victory
What is being implemented at large scale all over the
world is visualization and per person, or per team
WIP limits
Enterprises are struggling to implement end-to-end
“pull” at any significant scale!
WHY?

Proto-Kanban

Team Kanban
Backlog
F
E
G
D
Next Done
3
In-progress
3∞ ∞
GY
PB
DE Avatar for each
team memberStill at a single
team level but
maturing to focus
on managing work
and less on
managing workers

O
P
R
N
M
L
J
Per Person WIP Limit
Done
F
E
I
Pending
G
D
GY
PB DE
MN
AB
Dev/Build/
Test/Deploy
Dev
Ready
GY
GY
PB
PB
MN
MN
DE
DE
AB
AB
K
Bench
Specify
∞∞ ∞
Unbounded
Queue
Delayed
WIP
At this level, we are
focused on managing
work and enabling people
to self-organize around it
but we aren’t limiting WIP
in the system as a whole.
Hence, service delivery will
not be predictable
Moving beyond a single
team to a service
delivery workflow

Aggregated Team Kanban
Done
Pool
of
Ideas
F
E
I
Next
Deploy-
ment
Ready
G
D
GY
PB
DE MN
5 ∞
P1
AB
Ongoing
Development Testing
Done Ongoing Done
3 3
Team 1 Kanban
∞ ∞
Team 2 Kanban

Done
Pool
of
Ideas
F
E
I
Next
Deploy-
ment
Ready
G
D
GY
PB
DE MN
5 ∞
P1
AB
Ongoing
Development Testing
Done Ongoing Done
3 3∞ ∞
Also
known
as
“infinite
done
queues”

Done
Pool
of
Ideas
F
E
I
Next
Deploy-
ment
Ready
G
D
GY
PB
DE MN
5 ∞
P1
AB
Ongoing
Development Testing
Done Ongoing Done
3 3
Infinite limits on Done columns means that there really
isn’t a kanban pull system present.
This style of proto-kanban controls multi-tasking but
doesn’t limit workflow WIP
∞ ∞

Benefits of proto-Kanban implementations
Benefits
Transparency
Relief from overburdening
Reduced multitasking
Improved quality
People engaged emotionally
More collaboration
Greater empathy

Benefits of proto-Kanban implementations
Benefits
10-50% greater productivity
Up to 50% reduction
in lead times
Average 25% headcount
saving
Return on investment
300->400 : 1

Are we there yet?

Kanban Litmus Test
1. Have managers changed their behavior?
2. Has the customer interface changed?
3. Has the customer contract changed?
4. Has the service delivery business model changed?
If you can’t answer yes to at least 2 of these questions
it is unlikely you’ve switched to Kanban yet! You may
have the intent to adopt it through a series of
evolutionary steps initially adopting proto-Kanban

Have Managers Changed their Behavior?
Are managers managing people, assigning work,
focused on utilization levels, building brittle,
deterministic plans, making early customer
commitments and often making promises without
regard to capability or respect for risk & uncertainty?
Or have they switched to managing work, focusing
on flow, forecasting probabilistically, deferring
commitment, making promises based on probability,
embracing risk and uncertainty, and focusing on due
date performance against SLAs?

Has the Customer Interface Changed?
Are you still attending the same old planning
meetings on the same old schedule?
Or, have you adopted kanban system replenishment
meetings?
Are customers present at replenishment meetings?
Does commitment happen at the replenishment
meeting when an item is “pulled” onto the board?
Has the frequency of the meeting changed? Is it
much more frequent than before?

Has the Customer Contract Changed?
Are you still making commitments the same way?
Has the promise you make and the way you make it
changed?
Are you still making deterministic plans, promising
precise scope and schedule, and hedging with
contingency by “overestimating” size, complexity, or
duration of work?
Or are you working probabilistically, studying historical
data, aggregating risk and using service level agreements
as a new style of contract with the customer?

Has the Service Delivery Business Model Changed?
Are you carrying all the risk? Fixed delivery date, fixed
scope, fixed cost? Precise promises based on
deterministic planning?
Is all work treated homogenously from a risk
perspective? Do you process all requests the same way?
Or, have you introduced classes of service based on risk
profiling and assessment of cost of delay? Do you offer
multiple classes of service by allocating capacity and
hedging risk? Is class of service tied to risk and urgency?
Do you have explicit policy assigning class of service to
different risk profiles?

Triage
“pull” creates a pressure to triage:
 What should we do immediately?
 What can wait until later?
• And if so, when? (a scheduling problem)
 What shouldn’t we do at all? (discard)
If you haven’t developed a strong triage discipline
then you almost certainly haven’t achieved end-to-
end “pull”

Pull

F
F
O
M
N
K
J
I
Using movable tokens as kanban is more flexible
Ideas
D
I
Dev
Ready
G
Development Testing
Test
Ready
F B
C
UAT
Release
Ready
In-progress
Legend
Done
Blocked - issue
Blocked - defect
Override on kanban
limit introduces
additional “blocked –
issue” kanban
People working on
blocked item “A”
have been
redirected to
work on item “I”

F
F
O
M
N
K
J
I
Using movable tokens as kanban is more flexible
Ideas
D
I
Dev
Ready
G
Development Testing
Test
Ready
F B
C
UAT
Release
Ready
In-progress
Legend
Done
Blocked - issue
Blocked - defect
Using physical slots in the previous
example has been shown to create
inertia to modification & improvement
Using movable tokens allows for
WIP limits to be easily modified
and provides a natural signal
token mechanism

Single Service, Multiple Classes of Service
Allocate capacity with kanban limit per color
5 4 4 5 2 = 20 total
Allocation
10 = 50%
...
+1 = +5%
4 = 20%
6 = 30%
Input
Buffer In Prog DoneDoneIn Prog
DevelopmentAnalysis Build
Ready Test
Release
Ready

3 Services Aggregated Together
5 4 4 5 2 = 20 total
Change Req
12
Maintenance
2
Production Defect
6
Allocation
Total = 20
Input
Buffer In Prog Done
Build
Ready Test
Release
ReadyDoneIn Prog
DevelopmentAnalysis
Released

Change
Requests
3
1
Prod.
Defects
Maintenance
Usability
Improvement
2
1
Improving Liquidity through Labor Pool Flexibility
Teams
F
E
Engin-
eering
Ready
G
D
GY
PB
DE
MN
2
P1
AB
Ongoing
Analysis Testing
Done Verification Acceptance
3 3
Ongoing
Development
Done
3
Joe
Peter
Steven
Joann
David
Rhonda
Brian
Ashok
Team
Lead
Junior who will be rotated
through all 4 teams
Generalist or T-shaped
people who can move
flexibly across rows on
the board to keep work
flowing
It’s typical to see splits of
fixed team workers versus
flexible system workers of
between 40-60%
Roughly half the labor pool
are flexible workers
Promotions from junior
team member to flexible
worker with an avatar
clearly visualize why a pay
rise is justified. Flexible
workers help manage
liquidity risk better!

Irrefutable Demand

Don’t miss it!
Andy Carmichael at 15h20
“IRREFUTABLE DEMAND: When you can’t say “NO””
 UNDERSTAND YOUR OPTIONS - YOU MAY HAVE MORE
THAN YOU THINK!”

Pressure for “push” is partially internal
Why does it feel like “push” is inevitable and unavoidable?
Because so much demand is actually internally spawned from
existing commitments!
So many Kanban implementations are proto-Kanban semi-
push systems because they service internally generated
demand which is irrefutable
If you are to get to “pull”, you generally have to start with
externally facing customer services
Or insert a strong “definition of ready” at the customer facing
point, which states that we will only commit to externally
demand when internal dependency capacity is confirmed (this
has a tendency to lead to undesirable behaviors – big
team/org unit sizes, big batch sizes)

What causes irrefutable demand?
“we’ve already committed to it”
 Potentially bad behavior on the part of executives or sales
people
 “the boss wants it”
It’s a legal or regulatory requirement
It’s table stakes for this customer or market niche
It’s mission critical
 High severity production defects

Getting to “pull”
Pull requires that demand is refutable or at least
delayable
Demand must be balanced against capability to
supply
Demand can be shaped
Kanban systems have a notion of capacity and hence
a strong definition of ready may include whether
capacity has been booked in advance using a
dynamic reservation system

Is all irrefutable demand as irrefutable as it seems?
Can we use policy to shape demand?
 For example, sacrifice fidelity or quality on items of a given risk
category or risk profile to bifurcate demand to a shared sevice?
Can we smooth demand through better understanding of
when to schedule it or its cost of delay?
 Schedule highest cost of delay items at optimal start time, and
offset others to less optimal start times while recognizing their
comparative cost of delay is lower?
 i.e. anticipate overburdening and trade off lost opportunity for
smoother flow, rather than…
 reacting to overburdening by delaying items, lengthening lead
times, increasing the tail on the distribution and negatively
affecting predictability

You have more management options than you think!
Ensure…
 Use the feedback loops of risk review, operations review &
strategy review to adjust demand to capability
 Use a holistic approach to managing the network of
interdependent services
• Operations review
• Dynamic reservation systems
 Decision making is informed & effective
• Risk profiling
• Demand shaping thresholds and other policies are explicit
 Management of uncommitted options is returned to the
customer

Strategies for irrefutable demand
Deferred commitment negotiated and agreed with customer
Classes of Service
 maximize flow of value
 build flexibility to handle variation
Operations Review cadence to balance demand
Staff liquidity
 allocate high skilled, multi-skilled staff before less flexible staff
Examine the constraint/bottleneck in multiple workflows
 Use policies to subordinate other parts of the system to the bottleneck
(shape/bifurcate demand)
 elevate the constraint/bottleneck
Limit capacity / utilisation (e.g. to 50% for planned work)
Reduce work in progress
Manage flow!

Shaping Demand : Triage

Demand Shaping Threshold
Dimension 1
Dimension 2
Dimension 3
Dimension 5
Dimension 4
Definitely
Do
This
Demand shaping
threshold
Talk about
this one
Definitely
Don’t
This
Each risk dimension
represents a taxonomy of
categories describing a
known risk.
Policy describes the
category in each
dimension at or
above which we wish
to accept demand

Demand Shaping Threshold
Dimension 1
Dimension 2
Dimension 3
Dimension 5
Dimension 4
Don’t
Do
This
Exclusion
Zone
Talk about
this one
Definitely
Do
This
Thresholds can be used to as
upper or lower bounds Exclusion zone can be
to the outside or
inside of the graph

Get a Demo of Swift ESP!

SwiftKanban ESP implements Risk Profiling &
Demand Shaping to Manage Large “Backlogs”

Don’t miss it!
Maria Torrijos Lopez at 12h30
“DEALING WITH A MASSIVE BACKLOG AT THE
WORLD'S NO.2 ONLINE TRAVEL COMPANY”
 Large scale Enterprise Services Planning implementation
 Risk profiling in action

Organizational Maturity

Personal Kanban
Aggregated
Personal Kanban
Team Kanban
Emergent/Undefined
Workflow
Per Person WIP Limit
CONWIP
Physical space
kanban
Physical token
kanban
Virtual Kanban
Classes of service
Capacity allocation
Liquidity optimization
Aggregated teams
Patterns of Kanban Board Designs

Risk Hedging
Risk Management
Benefits of improving maturity

What’s Preventing Getting to “pull”?

6 Forces Preventing Getting to “Pull”
1. Not starting with a customer facing service
2. “We are just order takers”
3. Lack of understanding of business risks
4. Lack of mathematical literacy
5. Lack of skills in negotiation or forming business
agreements
6. Lack of confidence planning & scheduling at scale

1. Not Starting with a Customer Facing Service
Team Kanban isn’t enough unless the team offers a
bespoke service that is directly customer facing
Initiatives start where there is enthusiasm and don’t
follow the coaching guidance on “where to start in
large corporations”
Internal services suffer from irrefutable demand but
lack the guidance or political influence to cope with
irrefutable demand

Affecting a Paradigm Shift to “pull”
Kanban coaching guidance on “where to start”
within large organizations…
1. Must be Customer Facing
2. Must Not be Mission Critical
3. Must be Highly visible
4. Staff are enthusiastic
 indeed may volunteer to pilot the changes

2. We are Just Order Takers
Organizational structure or corporate governance
that puts product & service delivery functions in a
silos without influence or stewardship over what is
selected, when it is scheduled, and how it is
sequenced, is destructive and economically
damaging
Build trust with transparency, visibility, excellence in
delivery, metrics
Encourage greater collaboration – replenishment
meetings with both sides present - requesters and
delivery

3. Lack of Understanding of Business Risks
Without a framework for analyzing risks and scrutinizing
the analysis, we rely on “the hero product manager”. It’s
low maturity upstream!
A shared language for discussing business, technical and
delivery risks, fosters collaboration and consensus
Elevate the product owner from “the single ringable
neck” to the owner of the risk assessment framework
Enterprise Services Planning features a rich risk
assessment framework which is now implemented in
SwiftKanban ESP edition – get a demo!

Blizzard Sport & Why Risk Assessment Matters
Blizzard
Factory

Blizzard Sport - Reducing Risk Actual Situation
Production
Volume
100%
Make-to-forecast
World
Sales Volume
Reporting to HQ
I II III IV V VI VII VIII IX X XI
0%
Risk
Launch
Volume
100% of total –> 90% risk = 90% risk
Cycle Time

Blizzard Sport – Kanban etc speeds up production
Production
Volume
100%
Make-to-forecast
World
Sales Volume
Reporting to HQ
0%
Risk
Adapt production to make-to-
order
Launch
Volume

Blizzard Sport – Risk assessment & sequencing
produce a larger payoff in risk reduction
Production Volume
100%
Make-to-forecast
USA / CAN / JP
Make-to-order
World
Sales Volume
0%
Risk

4. A Lack of Mathematical Literacy
The mathematics of probability in lead time distributions
and forecasting service delivery is not difficult, but it isn’t
taught in schools or universities except to statisticians!
Knowing when and where Gaussian distributions, Central
Limit Theorem & functions of averages such as Little’s
Law apply and when they don’t is vitally important
You can’t have rational conversation about when to start
things, or commitments on when or how much will be
delivered without basically mathematical literacy on
probability distribution functions

5. Lack of Skill in Negotiation
Geeks on the delivery side generally haven’t been to business
school.
Business owners & product managers on the requesting side
have been to business school and received formal training in
the art of negotiation
Geeks tend to lose out in negotiations
Business people refuse to play the transparent, collaborative
game and emotionally resist real data & evidence
How to deal with this challenge is a skill we teach in Kanban
Coaching Professional classes
 Create “skin in the game” with collaborative workshops – STATIK
 Or, design kanban systems with layers of classes of service and
capacity allocation that can be revealed in response to customer
objections

6. Lack of Confidence Planning & Scheduling
Kanban has lacked a comprehensive dependency
management and scheduling system
This is now available in Enterprise Services Planning
Case studies with scheduling & planning boards
appeared as early as 2009 (Posit Science), others
include…
 Sami Honkonen “Scheduling Work in Kanban” 2011
 Visotech, Klaus Leopold & Lean Kanban University Press
2014
 Odigeo, Maria Torrijos Lopez, LKCE Hamburg 2016

Reminder - Don’t miss it!
Maria Torrijos Lopez at 12h30
“DEALING WITH A MASSIVE BACKLOG AT THE
WORLD'S NO.2 ONLINE TRAVEL COMPANY”
 Large scale Enterprise Services Planning implementation
 Risk profiling in action
 Dynamic reservation system for scheduling demand

Declare Victory & Fight On!
11 years later no one is arguing that Kanban isn’t
appropriate in professional services work
Companies everywhere, large and small, are simply
doing it!
Kanban is broadly accepted a good thing!
Now it is time to actually start doing Kanban properly!

Thank you!

About
David Anderson is an innovator in
management of 21st Century
businesses that employ creative
people who “think for a living” . He
leads a training, consulting,
publishing and event planning
business dedicated to developing,
promoting and implementing new
management thinking & methods…
He has 30+ years experience in the high technology industry
starting with computer games in the early 1980’s. He has
led software organizations delivering superior productivity
and quality using innovative methods at large companies such
as Sprint and Motorola.
David defined Enterprise Services Planning and originated
the Kanban Method an adaptive approach to improved
service delivery. His latest book, published in June 2012, is,
Lessons in Agile Management – On the Road to Kanban.
David is Chairman of Lean Kanban Inc., a business operating
globally, dedicated to providing quality training & events to
bring Kanban and Enterprise Services Planning to businesses
who employ those who must “think for a living.”

Screenshots of SwiftKanban ESP risk assessment framework courtesy of Digite
Blizzard Sport inventory at risk assessment slides courtesy of Erix-Jan Kaak and
Tecnica Group
Acknowledgements

Appendices

Getting to pull at enterprise scale

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Getting to pull at enterprise scale

Ähnlich wie Getting to pull at enterprise scale (20)

Mehr von David Anderson

Mehr von David Anderson (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Getting to pull at enterprise scale

Hinweis der Redaktion