llkd13 thriving under uncertainty

© Patrick Steyaert, 2013 Thriving under uncertainty

Thriving under uncertainty with

Discovery Kanban

[email protected]

@PatrickSteyaert

London Lean Kanban Day March 2013


2 Options and variation

Option 1

Effort = 300MD Most likely delivery = May 31 Variation = ±10 days

Option 2

Effort = 300MD Most likely delivery = May 31 Variation = ±20 days

Deadline = May 15

© Patrick Steyaert, 2013

Options perspective (Anti-fragile)

§  thrive from disruption; variation can be beneficial

Thriving under uncertainty

3

Risk perspective (Resilient)

§  absorb variation and tolerate disruption without collapsing

TEAM

Customers/ Users / Stakeholders

FLEXIBLE BOUNDARY


Plan perspective (Robust but fragile)

§  variation and disruption are not tolerated very well


4

Pains and gains in the history of projects

Absorbing variation - Classes of Service

Thriving on variation - Options

Kanban variations


A calamitous history of projects*

Project Actual traffic as percentage of forecast

Channel tunnel UK-FR

18%

Miami metro, USA

15%

Denver International Airport, USA

55%


5

Project Cost overrun

Channel tunnel UK-FR

80%

Øresund access link, DE

70%

Great belt link, DE

54%

Øresund coast-to-coast

26%

Conclusion: don’t trust cost estimates Conclusion: don’t trust

usage forecasts

*Source: Megaprojects and risk, an anatomy of ambition, Bent Flyvbjerg, Nils Bruzelius and Werner Rothengatter, 2003


IT projects


6

4

RI�DOO�WHVW�FDVHV��¿[�FULWLFDO�GHIHFWV��DQG�YHULI\�WKH�

¿[HV�EHIRUH�FRQWLQXLQJ�IURP�WKH�XQLW�WHVW�SKDVH�

to integration testing.

3. Building effective teamsLarge projects can take on a life of their own in an

RUJDQL]DWLRQ��7R�EH�HIIHFWLYH�DQG�HI¿FLHQW��SURMHFW�

teams need a common vision, shared team processes,

and a high-performance culture. To build a solid team,

members should have a common incentive structure

that is aligned with the overall project goal, in contrast

with individual work-stream goals. A business-to-

WHFKQRORJ\�WHDP�WKDW�LV�¿QDQFLDOO\�DOLJQHG�ZLWK�WKH�

value-delivery targets will also ensure that all the

critical change-management steps are taken and

that, for example, communications with the rest

of the organization are clear, timely, and precise.

To ensure the smooth start-up of new front-end

and core systems that more than 8,000 people

would use, one company team launched a massive—

and successful—change-management program.

The program included a regular newsletter, desktop

calendars that highlighted key changes and mile -

stones, and quarterly town-hall meetings with the

CEO. The team made sure all top business-unit

leaders were involved during the user-acceptance

phase. The company included at least one change

agent on each team. These agents received training

WKDW�LQVWLOOHG�D�FOHDU�XQGHUVWDQGLQJ�RI�WKH�EHQH¿WV�

of the IT change. The actions helped the company

to verify that it had the required business capabili-

ties in place to make full use of the technology being

implemented and that it could deliver the business

value expected in the overall project business case.

4. Excelling at core project-management practices

To achieve effective project management, there’s

no substitute for tested practices. These include

having a strategic and disciplined project-manage-

PHQW�RI¿FH�DQG�HVWDEOLVKLQJ�ULJRURXV�SURFHVVHV�

for managing requirements engineering and change

UHTXHVWV��7KH�SURMHFW�RI¿FH�VKRXOG�HVWDEOLVK�D�IHZ�

Unexplainedcause

Rough cost-overrun disaggregation, %

McKinsey On Business Technology 2012 — Value AssuranceExhibit 2 of 3

IT executives identify 4 groups of issues that cause most project failures.

1With cost overrun, in 2010 dollars.2Cost increase over regular cost.

Source: McKinsey–Oxford study on reference-class forecasting for IT projects

Missing focus1

Content issues2

Skill issues3 Execution issues4

13

45

9

6

11

6

IT projects >$15 million1

2 45%

Benefits shortfall –56%

Exhibit 2

Delivering large-scale IT projects on time, on budget, and on value, Michael Bloch, Sven Blumberg, and Jürgen Laartz

17 percent of IT projects go so bad that they can threaten the very existence of the company (cost overruns of +200% and schedule slippage of nearly 70%)

Double Whammy – How ICT Projects are Fooled by Randomness and Screwed by Political Intent, Alexander Budzier, Bent Flyvbjerg, Aug

2011.


Delusions and deception

§  Imperfect forecasting techniques and inadequate data

§  Planning fallacy & optimism bias

§  Strategic misrepresentation and asymmetric information


7


How projects are “sold”


8

Gains/Losses f(X)

Unknown X

Gain

Pain

Gain more than pain

Convexity


9


How projects turn out in practice


10

Gains/Losses f(X)

Unknown X

Gain

Pain

Pain more than gain Concavity


Variation and disruption

§  Political intervention

§  Interrupt work

§  Technical problems

§  Changing requirements

§  Resources not available

§  Environmental problem(s)

§ …


11

§  Order of magnitude (size)

§  Customer

§  Team

§  Policies

§  Technology

§  Environment

§ …


Amplification – pain

Requirements Product Work

Prioritization

Changes


12

Failure load / Rework


Irreversibility & Lock-in


13


Complex projects


14

Convexity Concavity

How they are planned How they turn out





15



TEAM


FLEXIBLE BOUNDARY

Absorbing variation




Kanban systems – Less pain

Demand

Capability

Variable demand

Variable capability

Bottlenecks Uncertainty Loopbacks

Accredited Kanban Training

16

Kanban


Cost of delay

time

17


INTANGIBLE

FIXED DATE

STANDARD

EXPEDITE

Cost/Value

x


Classes of service - Minimize Cost of delay while retaining flexibility


18

Cos

t of

del

ay

§  will be pulled immediately by a qualified resource

§  will be pulled based on risk assessment (delivering on time)

§  will use first in, first out (FIFO) queuing approach to prioritize pull

§  will be pulled through the system in an ad hoc fashion

Urgent

Important Fl

exib

ility

INTANGIBLE

STANDARD

FIXED DATE

EXPEDITE

§  cost of delay may be significant but is not incurred until much later

§  cost of delay is shallow but accelerates before leveling out

§  cost of delay goes up significantly after deadline

§  critical and immediate cost of delay

Respond

Anticipate

Cost of delay Policy


Capacity allocation across classes of service

time

19


INTANGIBLE

FIXED DATE

STANDARD

EXPEDITE

Cost/Value

x

8 = 50%

+1 = +5%

4 = 20%

6 = 30%

Expedite

Fixed date

Standard

Intangible





20



TEAM


FLEXIBLE BOUNDARY





Amplification of gains

Requirements Product Work

Resources

Opportunities


21

User feedback/ Revenue


Risk/Options

Opportunity for learning

time

22

Enablers Can we build it?

Table stakes What is essential?

Exceptionals Protect & exploit existing value

Cost/Value


Probes Is there a need?


Never commit early (unless you know why)


23

EXCEPTIONAL

Potential option

PROBE Potential

option Validate

ENABLERS

Potential option Validate

TABLE STAKES

Potential option Validate


Exercising options


24

Exercised Option

Potential Option Option


Options expire


25

§  Expedite – critical and immediate cost of delay

§  Fixed date – cost of delay goes up significantly after deadline

§  Standard – cost of delay is shallow but accelerates before leveling out

§  Intangible – cost of delay may be significant but is not incurred until much later; important but not urgent

è will be pulled immediately by a qualified resource

è will be pulled based on risk assessment (delivering on time)

è will use first in, first out (FIFO) queuing approach to prioritize pull

è will be pulled through the system in an ad hoc fashion


Options have value


26

Gains/Losses f(X)

Unknown X

Gain

Pain

Gain more than pain

Convexity


Options - Maximize learning, minimize cost of failure

Cos

t of

fai

lure


27

Option

Commitment Le

arnin

g op

por

tunit

y

Exploration

Exploitation

ENABLERS § Minimally coherent end-to-end functionality showing critical quality

§  Explore feasibility and critical quality

TABLE STAKES §  End-to-end functionality with standard quality

§  Explore what is essential for exploitation

EXCEPTIONAL §  Broad and detailed functionality, Hi-Fi implementation

§  Protect & exploit existing value

§  Fragmented functionality, Lo-Fi implementation

§  Explore customers and needs

PROBE


Exploration versus exploitation


28

PROBE

EXCEPTIONAL

TABLE STAKES

ENABLERS

Potential option

Potential option

Potential option

Potential option

Validate

Validate

Validate

Exploitation

Exploration


Real options*

An option is the right to do something but not the obligation

§  Options have value

§  Options expire

§ Never commit early (unless you know why)


29

*Ref: Chris Matts & Olav Maassen


The knowledge discovery process


30

Potential option Option Exercise

option Validate option

Abandoned / Continue

Narrative, fragmented,

possibly conflicting

Coherent, shared concept

Working product (i.e. probe, enabler,…)

Feedback (e.g. user feedback)

Decision to dampen or

amplify

Discovery front-end Development Discovery back-end

Forming hypotheses Validating hypotheses


Discovery Kanban Board

Potential option

Option Exercise option

Validate option

Abandon / Continue

31

table stakes


3/3/9/4 1/1/5/2 1/1/4/2

WIP limits express exploration – exploitation balance

enabler

probe

Expedite

Fixed date

Standard

Intangible

Legend

Probe

Enabler

Table stakes

Exceptional

Fixed date probe Demo for tradeshow on 28/3

Intangible probe R&D

probe 28/3

Exploration Exploitation

FLOW

Expedite table stakes Overdue regulatory development

Standard enabler Framework development

FLOW


Kanban variations

1.  Visualize – options

2.  Minimal options / maximum un-

validated assumptions

3.  Manage Flow – flow of customer/

user acquisition

4.  Make Process Policies Explicit –

option policies (e.g. in terms of

cost of failure)

5.  Implement Feedback Loops –

customer feedback loops

6.  Improve Collaboratively, Evolve

Experimentally (using models/

scientific method)

1.  Visualize – work

2.  Limit work in progress

3.  Manage Flow – flow of work

4.  Make Process Policies Explicit –

work policies (e.g. in terms of

cost of delay)

5.  Implement Feedback Loops – at

workflow, inter-workflow and

organizational levels

6.  Improve Collaboratively, Evolve

Experimentally (using models/

scientific method)

Delivery Kanban Discovery Kanban


32


Not just for start-ups

§  Product development (mature product)

§  Business-IT programmes

§  Business transformation

§  Lean agile coaching


33





34



TEAM


FLEXIBLE BOUNDARY





Inspiration


35

http://alistair.cockburn.us/ The+Design+as+Knowledge+Acquisition+Movement

Knowledge discovery process:


Thank You


[email protected]

@PatrickSteyaert


Classifying features

Anti-fragile projects

37

Epic Epic Epic

Story

Story

Story

Story

Story

Story Story Story Story Story Story

Story Story

Story

Story

Story

Story

Story

Story

Story Story


Classifying features - probes


38

Epic Epic Epic

Story

Story

Story

Story

Story


Story Story

Story

Story

Story

Story

Story

Story

Story Story


Classifying features - enablers


39

Epic Epic Epic

Story

Story

Story

Story

Story


Story Story

Story

Story

Story

Story

Story

Story

Story Story

Enablers


Classifying features – table stakes


40

Epic Epic Epic

Story

Story

Story

Story

Story


Story Story

Story

Story

Story

Story

Story

Story

Story Story

Enablers

Table stakes


Classifying features – exceptionals


41

Epic Epic Epic

Story

Story

Story

Story

Story


Story Story

Story

Story

Story

Story

Story

Story

Story Story

Enablers

Table stakes

Exceptionals

llkd13 thriving under uncertainty

Documents

pain patrick steyaert

days patrick steyaert

service thriving

disruption variation

time cost ofdelay

ict projects

kanban systems

company cost overruns