35
© Reaktor 2013 Achieve flow! Balancing capability with demand Sami Lilja Agile coach and Trainer Finland 1 Saturday, June 15, 13

Dare slilja-flow

Embed Size (px)

Citation preview

Page 1: Dare slilja-flow

© Reaktor 2013

Achieve flow! Balancing capability with demandSami Lilja

Agile coach and TrainerFinland

1Saturday, June 15, 13

Page 2: Dare slilja-flow

© Reaktor 2013

I dare you..

Is your company “customer-centric” or “customer-oriented”?

2Saturday, June 15, 13

Page 3: Dare slilja-flow

© Reaktor 2013

Today’s agenda• Understanding Capability• Flow• Understanding demand • Balancing demand with capability• Designing system to meet the demand

• Controversial thought

3Saturday, June 15, 13

Page 4: Dare slilja-flow

© Reaktor 2013

Balancing Demand with Capability

4Saturday, June 15, 13

Page 5: Dare slilja-flow

© Reaktor 2013

Improve capability

Most management only focuses on this side!

New processes

New tools

Organization change

Removing waste

Targets and bonuses

5Saturday, June 15, 13

Page 6: Dare slilja-flow

© Reaktor 2013

Process Improvement?

Do we need this process at all?

What kind of thinking has created this process?

6Saturday, June 15, 13

Page 7: Dare slilja-flow

© Reaktor 2013

System

Thinking

Performance

7Saturday, June 15, 13

Page 8: Dare slilja-flow

© Reaktor 2013

Organization change?

!!

!!

!!Compa

nies l

ose m

oney

in th

is dir

ectio

n

Companies make money in this direction

8Saturday, June 15, 13

Page 9: Dare slilja-flow

© Reaktor 2013

What if Demand > Capability?

Prioritization meetings

Working weekends and overtime

Waiting for another team

Multitasking or lot of work-in-progress

Filling in status reports

WASTE!

Work that adds no val

ue

9Saturday, June 15, 13

Page 10: Dare slilja-flow

© Reaktor 2013

Should we remove waste?

Optimizing part of a system will not improve

the whole system

“Getting rid of what you don’t want does not give you

what you do want”- Russell Ackoff

10Saturday, June 15, 13

Page 11: Dare slilja-flow

© Reaktor 2013

Most of so-called waste is a product of imbalance between

demand and capability

Getting rid of waste requires getting rid of unevenness and

overburden

11Saturday, June 15, 13

Page 12: Dare slilja-flow

© Reaktor 2013

Theory of variation• We should expect things to vary, they always do• Understanding variation will tell us what to

expect• Understanding variation leads to improvement

• Causes of variation are always found in the system

• Understanding variation tells when something has happened. • Crucial for learning and performance improvement.

Source: http://www.systemsthinking.co.uk/variation.asp

12Saturday, June 15, 13

Page 13: Dare slilja-flow

© Reaktor 2013

Capability of an organization

Sprints

Rea

dy &

tes

ted

feat

ures

Target setting? Bonuses?

13Saturday, June 15, 13

Page 14: Dare slilja-flow

© Copyright Reaktor 2011 Confidential

Improve capability

Most management only focuses on this side!

New processes

New tools

Organization change

Removing waste

Targets and bonuses

14Saturday, June 15, 13

Page 15: Dare slilja-flow

© Reaktor 2013

15Saturday, June 15, 13

Page 16: Dare slilja-flow

© Reaktor 2013

Little’s Law and work-in-progress

• Most organizations try to increase throughput by ... • ... demanding higher velocity from teams

• ... decreasing project duration by cutting corners or

• ... imposing impossible deadlines

• Limiting work-in-progress would give better results

Time through system =Work-in-progress

Throughput

Little’s Law

16Saturday, June 15, 13

Page 17: Dare slilja-flow

© Reaktor 2013

Why WIP limits?• Limiting Work-in-Progress creates Pull

• Without WIP limit, we do not know when to take (pull) new work

• Why Pull system?• Creates visibility to system• Removes queues from the system• Helps organization work in optimal way

17Saturday, June 15, 13

Page 18: Dare slilja-flow

© Reaktor 2013

Achieving flow

Pull creates visibility to the system and makes it work at its

current optimal

Limiting Work-in-Progress (WIP) enables Pull

WIP-limits and Pull create Flow

18Saturday, June 15, 13

Page 19: Dare slilja-flow

© Copyright Reaktor 2011 Confidential

Improve capability

New processes

New tools

Organization change

Removing waste

Targets and bonuses

Create FLOW

19Saturday, June 15, 13

Page 20: Dare slilja-flow

© Copyright Reaktor 2011 Confidential

1. Eliminate causes of

failure demand

2. Shape Demand

1

Most significant improvement is on this side!

Improve capability

Create FLOW

20Saturday, June 15, 13

Page 21: Dare slilja-flow

© Reaktor 2013

Value demand and failure demand

Value demand

Adds value to our product or service from customer point of view.Something customers are willing to pay for.This type of demand we want.

Failure demand

Failure to do what customer needs.Bad quality, delay, wrong product or service. No product or service.Missing either what or how customer wants the service or product.Can account up to 80% of work

21Saturday, June 15, 13

Page 22: Dare slilja-flow

© Reaktor 2013

Sources of Failure Demand in SW Development

• Poor quality of work• Bugs

• Technical Debt (also Architecture Debt, Learning Debt etc)

• Features developed without thinking about User Experience• Requirements solely driven by HiPPO

• Lack of end user involvement

• Lack of understanding what matters to customer

• Misunderstandings• DependenciesSource: http://www.thekua.com/atwork/2013/05/what-is-failure-demand-in-software-development/

22Saturday, June 15, 13

Page 23: Dare slilja-flow

© Reaktor 2013

Shaping Demand• In order to create value, we need to

understand what is value• Customer demand tells us where the value is

• Only after we have the knowledge we can shape demand• I.e. choose what value we deliver

23Saturday, June 15, 13

Page 24: Dare slilja-flow

© Reaktor 2013

Spectrum of work

IT OpsHelpdesk

Software maintenance

Major projects

Mostly Failure demand

Lead time

Change requests

Product fixes

Throughput

Mostly Value demand

Learning

Push / Reactive

Pull / Proactive

Little scope to shape demand

Large scope to shape demand

Improve capability

Reduce failure demand

Treat demand as pool of options, improve option conversion rate

Improve capability

24Saturday, June 15, 13

Page 25: Dare slilja-flow

© Reaktor 2013

Demand Analysis

1. Define work item types. For example

- Source- Destination- Workflow- Order of Magnitude in Size

2. For each work item type analyze- Demand- Arrival Rate (seasonal fluctuations?)- Nature of Demand (stochastic, burst, seasonal, batches, chaotic)- Customer Expectations (even if unreasonable)

3. Describe Sources of Internal Dissatisfaction

- Variability that randomizes the process- Prevents work being delivered on-time, with good quality etc

4. Describe Sources of Customer Dissatisfaction

- Reasons customers are unhappy / expectations not met (or points of customer conflict)

25Saturday, June 15, 13

Page 26: Dare slilja-flow

© Reaktor 2013

26Saturday, June 15, 13

Page 27: Dare slilja-flow

© Reaktor 2013

Priority or Capacity allocation?Product Owner

Team

Product Owner

Team

40%

40%

20%

27Saturday, June 15, 13

Page 28: Dare slilja-flow

© Reaktor 2013

Project delivery or Classes of Service

28Saturday, June 15, 13

Page 29: Dare slilja-flow

© Reaktor 2013

Demand, Value and FlowStudy and understand customer

Demand

Understand what is Value from customer point of view

Design Flow of work against value demand

29Saturday, June 15, 13

Page 30: Dare slilja-flow

© Reaktor 2013

The foundational principles of Kanban

Start with what you do now

Agree to pursue incremental, evolutionary change

Initially, respect current roles, responsibilities & job titles

Encourage acts of leadership at all levels

Study and understand customer demand

30Saturday, June 15, 13

Page 31: Dare slilja-flow

© Reaktor 2013

Measurements• Measure against the Purpose of the organization

• From customer perspective

• Look at variation over time• Allows learning

• Measure to understand and improve• Instead of arbitrary target, bonus or competition

• Measurements are used (a) by those who do the work and (b) people who design and act on the system

Are we achieving the Purpose of the system?

31Saturday, June 15, 13

Page 32: Dare slilja-flow

© Reaktor 2013

Summary• The system operates at its optimal when demand

and capability are balanced• Limiting work-in-progress creates a pull-

system which helps to achieve flow• Flow improves predictability and throughput of the

system

• Studying and understanding Demand is the most important activity when designing a system

• Understanding Demand creates Purpose and makes measurement possible

32Saturday, June 15, 13

Page 33: Dare slilja-flow

© Reaktor 2013

I dare you..

Is your company “customer-oriented”

Study and understand Demand

Measure against Purpose

Limit WIP in order to improve lead times

Have Pull system

Remove root causes of Failure Demand

Design work against Value Demand

33Saturday, June 15, 13

Page 34: Dare slilja-flow

© Reaktor 2013

Controversial thought

All work management systems are waste!

Need for management system is a symptom of imbalance between

demand and capability.

Understanding demand helps to find the right system to manage

work, reach balance and achieve Flow!

34Saturday, June 15, 13

Page 35: Dare slilja-flow

© Copyright Reaktor 2011 Confidential

Thank you

Twitter: @samililjaLinkedin: samililjaBlog: http://samililja.wordpress.com

35Saturday, June 15, 13