just say #no____ the altenative path to enterprise agility

Copyright Lean Kanban Inc.Email: [email protected] 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

mailto:[email protected]


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 daylightsout 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?



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

CurrentProcess Future

Process

Defined

Designed

transition

* Value stream mapping, ** Theory of Constraints Thinking Processes



What change really feels like:The J Curve




Safe

ty!




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

EvolvingProcess

Rollforward

Rollback

InitialProcess

Future process is emergent

EvaluateFitness

EvaluateFitness

EvaluateFitness

EvaluateFitness

EvaluateFitness

We don’t know the end-point but we do know our emergent

process is fitter!



StrategyReview

RiskReview

Monthly

ServiceDeliveryReview

Bi-WeeklyQuarterly

KanbanMeeting

Daily

OperationsReview

Monthly

Replenishment/Commitment

Meeting

Weekly

DeliveryPlanningMeeting

Per delivery cadence

change change

change

change

change

change

change change

change

info

info

info

info

info

infoinfo

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



Change

Req

ues

ts

SLA (customer expectation or fitness criteria)60 days

Use Lead Time Distribution to Evaluate Service Delivery Effectiveness

22-150 dayspread of variation

85%on-time

15% lateDue DatePerformance(DDP)

Predictability



Delivery Rate

Lead Time

WIP=

Avg. Lead Time

Avg. Delivery RateWIP

Backlog ReadyTo

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



DigiteProd Dev(5 months)

CME NynexDept “A”(2 months)

CME NynexDept “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



TestReady

FF

FFF

F F

Replenishment Frequency

EG

D

Replenishment

Discarded

I

Pull

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATReleaseReady

∞ ∞

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!



TestReady

FF

FFF

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

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATReleaseReady

∞ ∞

Frequent delivery gives more agility

On-demand delivery gives most agility!



I

TestReady

FN

K

M

L J

F

Specific delivery commitment may be deferred even later until delivery planning

E

GD

2nd

Commitmentpoint*

Discarded

I

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATDeliveryReady

∞ ∞

We are now committing to a specific release date

*This may happen earlier if circumstances demand it



TestReady

FN

K

M

L J

F

Forecast tickets completed for delivery

E

I

G

D

Discarded

I

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATDeliveryReady

∞ ∞

100% confidence

70+% confidence



TestReady

FN

K

M

L J

F

Boost class of service on marginal tickets to ensure delivery

E

G

D

Discarded

I

IdeasDev

Ready

5Ongoing

Development Testing

Done

3 35

UATDeliveryReady

∞ ∞

100% confidence

Fixed date CoSprovides 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

Dem

and

ObservedCapability

Dem

and

Dem

and

ObservedCapability

ObservedCapability



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

NewMid

Cow

Expedite

FD

StdIntangible

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

NewMid

Cow

Expedite

FD

StdIntangible

ELE

Maj. Cap.

Disc

Unknown Soln


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!



Visualize Risks to provide Scheduling Information

TS

Market Risk

CR

Spoil

Diff

Lifecycle

Cost of Delay

Tech Risk

Delay Impact

NewMid

Cow

Expedite

FD

StdIntangible

ELE

Maj. Cap.

Disc

Unknown Soln


Commodity

Risk profile for a work item or project

Outside:Commit Early

Inside:Commit Late



Demand Shaping – picking the right things

Dimension 1

Dimension 2

Dimension 3

Dimension 5

Dimension 4

DefinitelyDoThis

Demand shapingthreshold

Talk aboutthis one

DefinitelyDon’tThis



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



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 2011http://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 ServiceWIP 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” ClassBooking

DependencyAnalysis

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” ClassBooking

“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” ClassBooking

“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



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/



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



Treat each service separately

Dem

and

ObservedCapability

Dem

and

Dem

and

ObservedCapability

ObservedCapability



Organizational Improvements Emerge



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



ChangeRequests 3

1

Prod.Defects

Maintenance

UsabilityImprovement

2

1

Improving Liquidity through Labor Pool Flexibility

Teams

F

E

Engin-eeringReady

G

D

GY

PBDE

MN

2

P1

AB

Ongoing

Analysis Testing

Done Verification Acceptance3 3

Ongoing

Development

Done3

Joe

Peter

Steven

Joann

David

Rhonda

Brian

Ashok

TeamLead

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



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


#noEstimates

#noIterations

#noPlanning

#noPrioritization

#noBacklogGrooming





Kanban

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



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

SkillsExperienceCapacity

# Options x Frequency of decision making



Survivability = Agility x Adaptability

Capability x Optionality

Capability(to manage change)

Frequency of change opportunitiesx

SkillsExperienceOrg maturity



Capability

OptionalityAdaptability

Agility

Survivability

Out-maneuvered

Unfit for purpose


just say #no____ the altenative path to enterprise agility

Leadership & Management