dare slilja-flow
TRANSCRIPT
© Reaktor 2013
Achieve flow! Balancing capability with demandSami Lilja
Agile coach and TrainerFinland
1Saturday, June 15, 13
© Reaktor 2013
I dare you..
Is your company “customer-centric” or “customer-oriented”?
2Saturday, June 15, 13
© 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
© Reaktor 2013
Balancing Demand with Capability
4Saturday, June 15, 13
© 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
© Reaktor 2013
Process Improvement?
Do we need this process at all?
What kind of thinking has created this process?
6Saturday, June 15, 13
© Reaktor 2013
System
Thinking
Performance
7Saturday, June 15, 13
© 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
© 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
© 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
© 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
© 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
© Reaktor 2013
Capability of an organization
Sprints
Rea
dy &
tes
ted
feat
ures
Target setting? Bonuses?
13Saturday, June 15, 13
© 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
© Reaktor 2013
15Saturday, June 15, 13
© 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
© 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
© 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
© Copyright Reaktor 2011 Confidential
Improve capability
New processes
New tools
Organization change
Removing waste
Targets and bonuses
Create FLOW
19Saturday, June 15, 13
© 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
© 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
© 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
© 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
© 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
© 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
© Reaktor 2013
26Saturday, June 15, 13
© Reaktor 2013
Priority or Capacity allocation?Product Owner
Team
Product Owner
Team
40%
40%
20%
27Saturday, June 15, 13
© Reaktor 2013
Project delivery or Classes of Service
28Saturday, June 15, 13
© 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
© 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
© 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
© 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
© 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
© 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
© Copyright Reaktor 2011 Confidential
Thank you
Twitter: @samililjaLinkedin: samililjaBlog: http://samililja.wordpress.com
35Saturday, June 15, 13