Just say #no____ the altenative path to enterprise agility

Copyright Lean Kanban Inc.Email: dja@leankanban.com Twitter: @LKI_dja
Just Say #no_____
The Alternative Path to Enterprise Agility
Presenter
David J. Anderson
Lean Kanban North America
Washington D.C.
May 2017

UK Wastes Billions Every Year On Failed Agile Projects
http://www.itpro.co.uk/strategy/28581/uk-wastes-billions-every-year-on-failed-agile-projects
“more than half of CIOs think the agile
methodology is now discredited, while
three quarters aren't prepared to defend it
as a way of completing projects anymore.
Additionally, half of CIOS think agile
processes are just an IT fad”

Kanban – the alternative path to agility

Kanban
It works for all professional services!
It’s not just for software development or your IT department

Kanban
The least disruptive approach to enterprise agility,
the most radical alternative to Agile

Kanban
#noRevolutionaryChange
#noEstimates
#noIterations
#noPlanning
#noPrioritization
#noBacklogGrooming
#noDependencyManagement
#noCrossFunctionalTeams

Kanban
“This is going to scare the living daylights
out of the Agile community”, Rachel Davies (March 2008)

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

China
3 Chinese companies have “very large scale” Kanban implementations
 Huawei – Telecoms & electronics – 5000+ people (in 2017 scaling to 98,000)
 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%

Kanban is much cheaper to implement
At one of the Chinese companies mentioned earlier, Kanban is costing
just 1/150th of the cost of Scrum on a per employee basis
Scrum is requiring 1 coach for every 12-14 employees and is struggling
to institutionalize
Kanban cost just 200 training & coaching days to completely
institutionalize across several thousand people in 5 cities across China

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

Is Agile too tribal?
Is the tribal nature of the Agile community holding back adoption of
better, simpler and more effective means of improving agility?
Is it about “being Agile” rather than delivering business agility?
And why would Kanban be so scary for Agilists? Does it obviate the need
for many of their tribal rituals and superstitious practices?

Just how radical is Kanban?

#noRevolutionaryChange

Traditional Change is an A to B process
A is where you are now. B is a destination.
 B is either defined (from a methodology definition)
 or designed (by tailoring a framework or using a model based
approach such as VSM* or TOC TP**)
To get from A to B, a change agency*** will guide a
transition initiative to install B into the organization
***either an internal process group or external consultants
Current
Process
Future
Process
Defined
Designed
transition
* Value stream mapping, ** Theory of Constraints Thinking Processes

What change really feels like:
The J Curve

The J Curve
Safety!

The J Curve
Patience!

The Kanban Method
Change Management Principles
1. Start with what you do now
 Understanding current processes, as actually practiced
 Respecting existing roles, responsibilities & job titles
2. Gain agreement to pursue improvement through
evolutionary change
3. Encourage acts of leadership at all levels

Evolutionary change has no defined end point
Evolving
Process
Roll
forward
Roll
back
Initial
Process
Future process is
emergent
Evaluate
Fitness
Evaluate
Fitness
Evaluate
Fitness
Evaluate
Fitness
Evaluate
Fitness
We don’t know the
end-point but we do
know our emergent
process is fitter!

Strategy
Review
Risk
Review
Monthly
Service
Delivery
Review
Bi-WeeklyQuarterly
Kanban
Meeting
Daily
Operations
Review
Monthly
Replenishment/
Commitment
Meeting
Weekly
Delivery
Planning
Meeting
Per delivery cadence
change change
change
change
change
change
change change
change
info
info
info
info
info
info
info
info
info
change info
Kanban Cadences

Fitness
Time
Evolutionary change with many small J’s

Punctuated Equilibrium
Punctuation Points
• Financial crisis, regulatory changes,
political changes, merger, acquisition,
divestiture, split, IPO, outsourcing, CEO
change, key man exit, reorganization,
arrival of a disruptive
innovation/insurgents in your market
• Easy to insert change
• First 100 days
• Honeymoon period, blame predecessor
Periods of Equilibrium
• Need emotional motivation for change
• Immersive experiential learning
• New species competes for fitness in
existing environment
• Grey squirrel, red squirrel
• Galapagos Island Effect
• Isolation strategy
• Innovator’s Solution

#noEstimates

Don’t speculate about the future, study historical trends
Do you manage your business on speculation, superstition and socially
engineered heroics?
Or do you use facts, objectivity and science to make decisions?

Lead Time & Weibull Distributions
Lead time histograms
observed to be Weibull
distributions typically
with shape parameter
1.0 < k < 2.0
The details of the mathematics are
not particularly important. What
is important is to recognize that
the risk is always in the tail and
the length of the tail varies from
2x – 10x from the mode in the
data

ChangeRequests
SLA (customer expectation or fitness criteria)
60 days
Use Lead Time Distribution to Evaluate Service Delivery Effectiveness
22-150 day
spread of variation
85%
on-time
15% late
Due Date
Performance
(DDP)
Predictability

Delivery Rate
Lead Time
WIP
=
Avg. Lead Time
Avg. Delivery RateWIP
Backlog Ready
To
Deploy
Little’s Law

Forecasting methods
ESP relies on two types of forecasting approaches
 Reference class forecasting
 Monte Carlo simulation
Reference class forecasting requires an assumption of an equilibrium –
the near future will reflect the continuing conditions of the recent past
 We sample data from a period in the recent past and use it to forecast future
behavior
 The sample period is determined by evaluating the volatility in kanban system
liquidity

Digite
Prod Dev
(5 months)
CME Nynex
Dept “A”
(2 months)
CME Nynex
Dept “B”
(2 months)
Daily transaction volume
(“pulls”)
Volatility
(in pull transactions)
Turbulence
(or volatility(volatility))
Measuring Liquidity (of service delivery)

Auto-detecting changes in volatility
Liquidity daily pull tx volume & volatility are
leading indicators of process health
Periods of similar volatility used to select reference
class forecasting data for Monte Carlo simulation
(of project durations etc)
Changes in volatility suggest changes with
processes and risk with forecast dates
Different volatility regimes can be detected using
GARCH modeling

Monte Carlo Simulation for Scope Forecasting

#noIterations

Don’t artificially constrain work in timeboxes
Most business domains do not naturally lend themselves to starting
work, and completing it within synchronized time boxes
Iterations (or Sprints) are a low capability crutch for software
development teams with poor ability at configuration management and
version control, and poor capability at coordination and decision making
Most professional services work shouldn’t be organized in time boxed
batches. It should be allowed to flow!
The Tyranny of the Ever Decreasing Timebox is real
 http://www.djaa.com/tyranny-ever-decreasing-timebox

Test
Ready
F
F
FF
F
F F
Replenishment Frequency
EG
D
Replenishment
Discarded
I
Pull
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Release
Ready
∞ ∞
The frequency of system replenishment
should reflect arrival rate of new
information and the transaction &
coordination costs of holding a meeting
Frequent replenishment
provides more agility
On-demand replenishment
gives most agility!

Test
Ready
F
F
FF
F
F F
Delivery Frequency
EG
D
Delivery
Discarded
I
Pull
The frequency of delivery should
reflect the transaction & coordination
costs of deployment plus costs &
tolerance of customer to take delivery
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Release
Ready
∞ ∞
Frequent delivery
gives more agility
On-demand delivery
gives most agility!

I
Test
Ready
F
N
K
M
L J
F
Specific delivery commitment may be deferred even later until
delivery planning
E
G
D
2nd
Commitment
point*
Discarded
I
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Delivery
Ready
∞ ∞
We are now committing to a
specific release date
*This may happen earlier if
circumstances demand it

Test
Ready
F
N
K
M
L J
F
Forecast tickets completed for delivery
E
I
G
D
Discarded
I
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Delivery
Ready
∞ ∞
100% confidence
70+% confidence

Test
Ready
F
N
K
M
L J
F
Boost class of service on marginal tickets to ensure delivery
E
G
D
Discarded
I
Ideas
Dev
Ready
5
Ongoing
Development Testing
Done
3 35
UAT
Delivery
Ready
∞ ∞
100% confidence
Fixed date CoS
provides 100%
confidence
I

#noPlanning

Don’t plan the work, plan the ecosystem!
Enterprise Services Planning involves designing a system of (kanban)
systems
Design and evolve your systems to deliver the outcomes you want, need
or expect
Plan the services! Plan the risk assessment framework! Plan the
selection policies! Plan the classes of service! Plan how decisions are
made and how things will be treated! Plan your policies!
Don’t plan individual work orders

Seeing Services
Learn to view what you do now as a set of services
(that can be improved):
 Service-orientation Paradigm…
• Creative & knowledge work is service-oriented
• Services have a requestor who both requests a product
or service and accepts or acknowledges delivery of the
finished item or condition
• Service delivery may involve workflow
• Workflow involves a series of knowledge discovery
activities
• The way in which a request is treated defines its class of
service

Defining Enterprise Services
Learn to make existing service delivery workflows explicit:
 Defining a service
• Identify the requestor & the service delivery
person/team/workflow
• Does someone play the role of service delivery manager?
• Is the service “shared” across several requestors?
• Does someone play the role of service request manager?
• What is it that is requested?
• Understand the volume and pattern for arrival of requests
• Map the knowledge discovery workflow for each type of
request
• Understand the way requests are treated with respect to
queuing, selection, capacity allocation, and quality

Treat each service separately
Demand
Observed
Capability
Demand
Demand
Observed
Capability
Observed
Capability

STATIK
(Systems Thinking Approach to Introducing Kanban)
1. Understand what makes the service “fit for
purpose”
2. Understand sources of dissatisfaction
regarding current delivery
3. Analyze sources of and nature of demand
4. Analyze current delivery capability
5. Model the service delivery workflow
6. Identify & define classes of service
7. Design the kanban system
8. Socialize design & negotiate implementation
This process
tends to be
iterative
Identify Services. For each service…

The Kanban Method
Scaling Principles
1. Scale out in a service-oriented fashion one service
at a time
2. Design each kanban system from first principles
using STATIK. Do not attempt to design a grand
solution at enterprise scale
3. Use the Kanban Cadences as the management
system that enable balance, leading to better
enterprise services delivery

Organizational Improvements Emerge

Reserved Capacity & Dynamic Reservation Systems
Calling Service
Called Service
Scheduling
Reservation
“Defn of Ready”
may require
confirmed
booking on
called service

#noPrioritization

What does “priority” even mean?
Prioritization is an activity to set priorities for work items
What does “priority” mean?
 A position in a queue or sequence?
 A class of service guiding selection from a set of options?
 An indication of when to schedule an item?

Don’t Prioritize, Select Dynamically
Understand when to schedule an item based on its cost of delay
Set its class of service based on cost of delay
Select dynamically from a set of options based on cost of delay
When you understand how to assess cost of delay you no longer need to
prioritize (and re-prioritize)
Make the cost of delay transparent, visualize the risks, enable dynamic
selection

Visualize Risks to provide Scheduling Information
TS
Market Risk
CR
Spoil
Diff
Lifecycle
Cost of Delay
Tech Risk
Delay Impact
New
Mid
Cow
Expedite
FD
Std
Intangible
ELE
Maj. Cap.
Disc
Unknown Soln
Known but not us
Done it before
Commodity
Risk profile for
a work item or
project
Outside:
Commit Early
Inside:
Commit Late

Scheduling & Sequencing
TS
Market Risk
CR
Spoil
Diff
Lifecycle
Cost of Delay
Tech Risk
Delay Impact
New
Mid
Cow
Expedite
FD
Std
Intangible
ELE
Maj. Cap.
Disc
Unknown Soln
Known but not us
Done it before
Commodity
Sequence:
1st
Sequence:
3rd
Sequence:
2nd
If only real life was so simple!

Custom Profile Contains Narrative
Our CEO has
requested we
do the blue
project. Which
one do we
postpone?
The purple
project is
important but
can be delayed
with little
penalty.

Scheduling using Cost of Delay

#noBacklogGrooming

Leave your backlogs ungroomed! Make selections by filtering!

Demand Shaping – picking the right things
Dimension 1
Dimension 2
Dimension 3
Dimension 5
Dimension 4
Definitely
Do
This
Demand shaping
threshold
Talk about
this one
Definitely
Don’t
This

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

#noDependencyManagement

Cost of Delay informs Dependency Management
When the cost of delay is small or there is sufficient time to start early
then there is no need to manage dependencies explicitly. Let them
emerge and manage them dynamically
Where the cost of delay is greater introduce a dynamic reservation
system using different classes of service to reserve capacity on
dependent services

Reservation systems
First reported by Sami Honkonen, “Scheduling Work in a Kanban” November 2011
http://www.samihonkonen.com/wp-content/uploads/2011/11/scheduling-work-in-kanban.pdf

Class 1 No Dependency Management
Calling Service
Called Service
We Don’t Care!
No WIP limits
Dependency
impact is built into
customer lead
time distribution.
We start early
enough & cost of
delay is low
enough that we
don’t need to
explicitly manage
the dependency

Class 2 Tail Risk Mitigation. Reserved Capacity
Calling Service
Called Service
WIP limits
[5]
[2]
We wish to mitigate
the tail risk in the
customer facing lead
time by insuring
dependency delivery
is predictable &
reliable as a
consequence of
reserved capacity on
the called service

Class 3 Known Dependency. Informed Scheduling
Calling Service
Called Service
Reservation system
[5]
[2]
Filtered lead time
“Reserved” Class
Booking
Dependency
Analysis
Determine the
dependency
exists, make a
reservation for it
to insure
capacity on the
called service
when we need it!

Class 4 Known dependency. Specific Scheduling
Calling Service
Called Service
Reservation system
“Reserved”
“Guaranteed” Class
Booking
“Defn of Ready”
requires
confirmed
booking on
called service
We want a high
confidence in the
start time for
customer lead
time. We take no
risk on dependent
capacity becoming
available

Class 5 No margin for error
Calling Service
Called Service
“Guaranteed”
“Guaranteed” Class
Booking
“Defn of Ready”
requires
confirmed
“Guaranteed”
booking on
called service
No margin for
error!
We want 100%
confidence in the
start time for
customer lead
time and no risk
on dependent
capacity
availability

Multiple Reservations
Cost of delay (and other risk assessment) can be
used to establish, optimal start, and whether earlier
or later is preferred if optimal isn’t available
Make multiple bookings at lower classes of service
“reserved”, or “standby” for the same item.
If it shows up early and capacity is available start it,
cancel its other reservations
“Guaranteed”
“Reserved”
“Stand by” 3 bookings for same ticket

#noCrossFunctionalTeams

Don’t reorganize. Make the existing organizational structure work
better – provide transparency, create “Einheit”
Kanban doesn’t share the cross functional team agenda of Agile
methods
If you have cross functional teams, then we’ll start with what you do
now
If you don’t have cross functional teams, then we’ll start with what you
do now
Don’t reorganize
http://leankanban.com/kanban-does-not-share-your-agile-cross-functional-team-agenda/

Kanban improves “Einheit”
Kanban provides a simple means to improve unity and alignment
 Transparency onto who is the customer and why did they request something
 Risk assessment
Kanban provides a sense of purpose, enabling large groups of people
across organizational units to collaborate towards a common goal
Kanban turns a network of services into a team! No need to reorganize!

Kanban facilitates geographical distribution
No need for collocation
Kanban, from its beginnings at Microsoft, enabled superior performance
from geographically distributed organizations
Transparency, sense of purpose, explicit risks, ease of tracking
Kanban has low coordination costs even for distributed organizations

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!

The Alternative Path to Enterprise Agility

It’s not about #noVoodooRituals
Kanban isn’t some anarchistic rage against the system. It isn’t anti-Agile!
There are simple principles at work!
If something is disruptive, painful, time-consuming and yields
information of low value then consider stopping it altogether. Add it
back when, and only when, risks suggest you need to pay attention to it.
Plan at system design level. Plan your policies and decision frameworks
Empower people with explicit policy. Enable high quality dynamic
decision making

And finally…
#noPrescriptiveProcessDefinitions
Find your own path to agility!

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 and Scope
Forecasting courtesy of Digite
Acknowledgements

Appendices

You are part of a professional services business!
An ecosystem of
professionals
providing
interdependent
services, often with
complex
dependencies.
Professional
Service
organizations
build intangible
goods

The challenge of professional services businesses
A constantly changing
external environment
has a ripple effect
across your entire
business ecosystem
Priorities change and
required capability & service
levels rise in response to
competition, disruptive
market innovation &
changes in customer tastes

Agility = Capability x Optionality
Skills
Experience
Capacity
# Options x Frequency of decision making

Survivability = Agility x Adaptability
Capability x Optionality
Capability
(to manage change)
Frequency of change opportunitiesx
Skills
Experience
Org maturity

Capability
OptionalityAdaptability
Agility
Survivability
Out-maneuvered
Unfit for purpose

Just say #no____ the altenative path to enterprise agility

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Just say #no____ the altenative path to enterprise agility

Similaire à Just say #no____ the altenative path to enterprise agility (20)

Dernier

Dernier (20)

Just say #no____ the altenative path to enterprise agility

Notes de l'éditeur