lean software development is for everyone
TRANSCRIPT
LEAN-agile© copyright 2010. Net Objectives, Inc.
B E C O M I N G
Lean Software For EveryoneKen PughFellow Consultant
KP Aug 2014
• Introduction and Background
• Lean as Flow • Lean Software
Development• Lean-Agile • Transforming into Lean
Outline
Ken Pugh
PhotoSize: Height: 2.25Position: from top left corner Horizontal 0.75 Vertical 1.Picture Style: Simple Black Frame
No code goes in till the test goes on.A journey of two thousand miles begins with a single step.
Fellow Consultant SPC, Lean, Scrum, ATDD, TDD, OOA&D, Design
Patterns, Over 2/5 century of software development
experience Author of seven books, including:
– Prefactoring: Extreme Abstraction, Extreme
Separation, Extreme Readability (2006 Jolt Award)
– Interface Oriented Design
– Lean Agile Acceptance Test-Driven Development:
Better Software Through Collaboration
Lean Enterprise
Business
ManagementTeam
ASSESSMENTS
CONSULTING
TRAININGCOACHING
Lean for ExecutivesProduct Portfolio
ManagementBusiness Product Owner
Lean Management
Project Management
ILAFYTKanban / Scrum ATDD / TDD / Design Patterns
technical
process
Lean Thinking, Jim Womack and Daniel Jones Lean Software Development, Mary and Tom
Poppendieck The Principles of Product Development Flow:
Second Generation Lean Product Development, Donald Reinertsen
Alan Shalloway, http://www.netobjectives.com/blog
Resources
Overall Rule There are exceptions to every statement,
except this one
6
copyright © 2010 Net Objectives Inc.
Introduction and Background
Lean software engineering – Continuous delivery of high quality applications
In short
Toyota Production System– Lean Manufacturing
Lean Thinking – Use lean thinking on workflow– Software development is workflow
Lean Software Development Creating software is not the same as producing a car Principles derived from Lean
Lean Approaches
Taiichi Ohno, chief engineer Eiji Toyoda (and cousin Kiichiro Toyoda and his
father Sakichi Toyoda, (Toyoda Loom Works founder))
Design out overburden (muri) and inconsistency (mura), eliminate waste (muda).
Smooth process - design out inconsistency Flexible – without overburden which generates
waste Elimination of waste
Toyota Production System (TPS)
Continuous improvement– Kazien
Respect for people Long-term philosophy
– Not short term goals
Right process will produce right results– Stop to fix problems– Visual controls– Use reliable, tested technology
Add value to organization by developing your people and partners– Develop exceptional teams
Continuously solving root problems drives organizational learning– Decisions by consensus
TPS Principles
Value comes from end customer Value stream
– Eliminate steps not creating value
Make remaining steps flow in integrated sequence
Let customers pull from upstream activity Transparency
– Helps eliminate waste – Continuous improvement
Lean Thinking
Eliminate Waste Create Knowledge Build Quality In Defer Commitment Deliver Fast Respect People Improve the System
Lean Software Development Principle
Dilbert on AgileAgile
copyright © 2010 Net Objectives Inc.
Workflow
3key points
drive from
Business Value
SMALL INCREMENT
S
m a k e a l l w o r kvisible
1concentration
Idea Business decision
Implementation
Availability
FLOW
© Warp and Byte Designs, Inc..
1outcome
business value trumps flow
trumps Reducing Waste
© Warp and Byte Designs, Inc..
Flow From Concept to Consumption
Business Value – What Is It? (1) Need to measure business value Deliver best ROI for business value
"I can't define it, but I know it when I see it“
Question: What is it to you?
26
Business Value – What Is It? (2) Business Value can be:
– Increased revenue (sales, royalties, fees) ($$)– Decreased expenses ($$)
Less resources More efficient use of resources
– Customer satisfaction ($$ ??) Promoters / Satisfiers/ Detractors
– Staying in business ($$ ??)– Staying out of jail ($$ ??) – Avoiding risk ($$ ??) – Your suggestions?
27
Business Value
Projects
Next Project BV = 8
Current Project BV = 13
Previous Project BV= 20
Transparency – Trust
Transparency
To Do Working On Done
Next Project Current Project Previous Project
Deliver – Minimum Marketable Feature (MMF)– Minimum Business Increment (MBI) – Key = Independently Releasable Item (IRI)
Develop – Stories – Scenarios
Key = Separately Developable Items (SDI) Although may be sequenced dependent
Small bites
Small Pieces
To Do Working On Done
Current Project Current Part Previous part
Still Another Part
Another Part
Some Part
Flow
BusinessPriority
BUSINESS DISCOVERY BUSINESS DELIVERY
BusinessPlanning
Business Readiness
Ready to Pull
IncrementalDevelopment
IncrementalDeployment
Support & Feedback
DecisionIs it technically feasible?
DecisionIs it ready to release?
PORT
FOLI
O
DecisionIs there enough business value?
Flow
Cycle Time
Lean Principle
Idea to Delivery
Support & Feedback
ProjectApproval
ProjectStaffing
ProjectDevelopment
ProjectDeploy-ment
Visioning
Total cycle time
Lean Principle
Support & Feedback
ProjectApproval
ProjectStaffing
ProjectDevelopment
ProjectDeploy-ment
VisioningSupport & Feedback
ProjectDevelopment
ProjectDeployment
$$$ Cost
Support & Feedback
ProjectApproval
ProjectStaffing
ProjectDevelopment
ProjectDeploy-ment
VisioningSupport & Feedback
ProjectDevelopment
ProjectDeployment
ProjectApproval
ProjectStaffing
Visioning
Lean Principle
Opportunity Cost
Value Stream
Value Stream
1. Identify the actions taken in the value stream
Approve
Request Reqts Sign Off
Review Deploy
Analysis
Design Code Test
Value Stream0.5 hrs 160 hrs8 hrs 8 hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
Approve
Request Reqts Sign Off
Review Deploy
Analysis
Design Code Test
1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?
Value Stream0.5 hrs 160 hrs8 hrs 8hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
Approve.1 / 7.9 hrs
Request0.5 / 0.0 hr
Reqts60 / 100 hrs
Sign Off1 / 7 hrs
Review 2 / 0 hrs
Deploy3 / 5 hrs
Analysis40 / 60 hrs
Design40 / 80 hrs
Code80 / 200 hrs
Test40 / 200 hrs
1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?
Value Stream0.5 hrs 160 hrs8 hrs 8hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
320 hrs 80 hrs 320 hrs 80 hrs
80 hrs
160 hrs 80 hrs 80 hrs 80 hrs
1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions
Approve.1 / 7.9 hrs
Request0.5 / 0.0 hr
Reqts60 / 100 hrs
Sign Off1 / 7 hrs
Review 2 / 0 hrs
Deploy3 / 5 hrs
Analysis40 / 60 hrs
Design40 / 80 hrs
Code80 / 200 hrs
Test40 / 200 hrs
Value Stream
April 15, 2023
0.5 hrs 160 hrs8 hrs 8hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
320 hrs 80 hrs 320 hrs 80 hrs
160 hrs 80 hrs 80 hrs 80 hrs
1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions5. Identify any loop backs required
80 hrs
65% defectiveRepeat 3X
20% rejectedRepeat 1X
Approve.1 / 7.9 hrs
Request0.5 / 0.0 hr
Reqts60 / 100 hrs
Sign Off1 / 7 hrs
Review 2 / 0 hrs
Deploy3 / 5 hrs
Analysis40 / 60 hrs
Design40 / 80 hrs
Code80 / 200 hrs
Test40 / 200 hrs
1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions5. Identify any loop backs required6. Calculate Process Cycle Efficiency:
Value StreamApprove.1 / 7.9 hrs
Request0.5 / 0.0 hrs
Reqts60 / 100 hrs
Sign Off1 / 7 hrs
Review 2 / 0 hrs
Deploy3 / 5 hrs
Analysis40 / 60 hrs
Design40 / 80 hrs
Code80 / 200 hrs
Test40 / 200 hrs
0.5 hrs 160 hrs8 hrs 8hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
320 hrs 80 hrs 320 hrs 80 hrs
160 hrs 80 hrs 80 hrs 80 hrs
65% defectiveRepeat 3X
20% rejectedRepeat 1X
80 hrs
Approve.1 / 7.9 hrs
Request0.5 / 0.0 hrs
Reqts60 / 100 hrs
Sign Off1 / 7 hrs
Review 2 / 0 hrs
Deploy3 / 5 hrs
Analysis40 / 60 hrs
Design40 / 80 hrs
Code80 / 200 hrs
Test40 / 200 hrs
Avg Time Worked Total Cycle Time
0.5 hrs 160 hrs8 hrs 8 hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
320 hrs 80 hrs 320 hrs 80 hrs
160 hrs 80 hrs 80 hrs
65% defectiveRepeat 3X
20% rejectedRepeat 1X
80 hrs
80 hrs
PCE = = 14.9%509 hrs
3433 hrs
509 hrs
3433 hrs
Avg Time Worked Total Cycle Time
Value StreamApprove.1 / 7.9 hrs
Request0.5 / 0.0 hrs
Reqts60 / 100 hrs
Sign Off1 / 7 hrs
Review 2 / 0 hrs
Deploy3 / 5 hrs
Analysis40 / 60 hrs
Design40 / 80 hrs
Code80 / 200 hrs
Test40 / 200 hrs
0.5 hrs 160 hrs8 hrs 8hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
320 hrs 80 hrs 320 hrs 80 hrs
160 hrs 80 hrs 80 hrs 80 hrs
65% defectiveRepeat 3X
20% rejectedRepeat 1X
80 hrs
320 hrs 80 hrs 320 hrs 80 hrs
160 hrs 80 hrs 80 hrs
65% defectiveRepeat 3X
20% rejectedRepeat 1X
80 hrs
80 hrs
3433 – 509 = 2924
Eliminating delays
between what you
do
Getting better at what you
do
Which gives a better return?
Cycle Time What’s the cycle time from input to output? How can it be shortened?
– Eliminate delays – Eliminate loop-backs– Manage WIP –
Waste and Delays
1. Partially Done Work2. Paperwork3. Extra Features4. Task Switching5. Handoffs6. Delays7. Defects
Waste Indicators
how much of what you do is
valuable?rework?
DELAY IS
hand-offs bottlenecks information delayuntested codeunread requirementstransaction related
setup/cleanupcoordination related
assign people
finding
redoing
reworking
waiting
Pull
PUSH
Work enters queue
When someone needs new work, they pull from queue
Work goes through stages When the work done in a stage, it flows to next.
Until work is done
Pull
PULL
BUT LIMIT QUEUES
Reduce WIP
Queuing theory
Focus on quality
Practice
EXERCISE
Part OneAGILE IS FUN
EXERCISE
Part Two AGILE IS FUN
Lean Software Development
Implement lean across entire value stream – To deliver business value – Not just improve development
Optimize the Whole / See the Whole
Focus on customer value Only start work that can be completed
Eliminate Waste
Move tests forward– Acceptance Test Driven Development
Automated testing Write change tolerant code
Build Quality In / Build Integrity In
Small batches Get feedback fast Emphasize cycle time, not utilization
Deliver Fast / As Possible
Use knowledge learned from creating application
Cross-functional teams to share knowledge Quick feedback
Create Knowledge / Amplify Learning
Create clear frameworks for decisions Decision making at lowest possible level
Empower People / The Team
Periodic reflections Perform root cause analysis
Continually Improve
Wait till last practical moment to make decision – More information available
Defer Commitment / Decide as Late as Possible
Points and Practices
Driving in Germany - picture of autobahn
policies© Warp and Byte Designs, Inc..
© Warp and Byte Designs, Inc..
Measurement
© Warp and Byte Designs, Inc..
Metrics
What is important?
Customer /user satisfaction
Production defects
Rate of delivery of business value
© Warp and Byte Designs, Inc..
copyright © 2010 Net Objectives Inc.
Lean – Agile
Apply lean principles/practices to agile processes
What lean principles/practices do you see in– Scrum– Kanban
Lean Agility
l e a n
a g i l e
WHAT is the most important thingWHEN is it most neededHOW we break down that workHOW we FLOW that work
Delivering
l e a n
a g i l e
Breaking work downCreating the best environment to deliver that workIncremental and Iterative development
Business Value
Delivering
l e a n
a g i l e
copyright © 2010 Net Objectives Inc.
Beginning the Transformation
Getting Started Agree to goals
– Why change?
Map the value stream Determine what process to use
– Scrum, Kanban, Scrumban, etc.
Agree to transparency– Up and down the line
Agree to policies– Done-ness definitions, etc.
Agree to operational review– Team and organization
Educate the team(s) Start doing it
David Anderson. XTC, London 2009, October
Getting started with kanban
Old Status Quo New Status Quo
Chaos Transforming Idea
Change Model From Virginia Satir
copyright © 2010 Net Objectives Inc.
This is Not an Ending,
But a Beginning
Shorten time to realize values Pay attention to delays Actively manage queues Emphasize cycle time, not utilization
Summary - Focus on Flow
copyright © 2010 Net Objectives Inc.
Supplementary
Roles
Purpose
MAKE• INCREMENTAL
DELIVERY• CREATIVELY SOLVING
THEIR PROBLEMS• QUALITY BUILT IN
technical
technical
VALUE• PRIORITIZATION• BUSINESS
ITERATIONS• RELEASE
PLANNING
FLOW• VALUE STREAM
VISUALIZATION• IMPEDIMENT IMPACT• WORKFLOW AS PROCESS
technical
WITH
ACCOUNTABILITY• MANAGE (LIMIT)
QUEUES• VISUAL CONTROLS• MANAGE FLOW
(PROCESS)
WHOLE team engaged to Understand and deliver VALUE
Business Value
Question What percentage of features are never used?
Waste and the Delay of Value
Always7%
Often13%
Sometimes16%
Rarely19%
Never Used45%
Source: Standish GroupStudy of 2000 projects at 1000 companies
Usage of Features and Functions in Typical System
_g
Teams
© U.S. Army
© Warp and Byte Designs, Inc..
Successful teamsCollaborate Shared accountability Shared approach to doing work Shared history
© Warp and Byte Designs, Inc..
Feedback
Agile Feedback – Small Increments
100
No feedback
Desired Delivered
With feedback
Desired
Delivered
Frequency of feedback
Deliver Quickly
Focus on known, valuable features
gives greater certainty
produces greater value
lowers risk of mis-building and over-building
Deliver in Stages when possible
do the most important half first
standard development sequence
More important
Less important
do the most important 25% first
standard development sequence
More important
Less important
Time to
Market Lower riskHigher satisfactionHigher ROI
Profit!
Market Share
Product Life
First Release
InvestmentPeriod
PaybackPeriod
ProfitPeriod
Breakeven
Cash
flow
Time
economics of responsiveness
Mark Denne and Jane Cleland-Huang, Software by Numbers.
Staged Releases
First Release
Invest-mentPeriod
ProfitPeriod
Pay-back
Period
Cash
flow
Time
Release 1 Net Return
Staged Releases
ProfitPeriod
Second Release
Invest-mentPeriod
Pay-back
Period
Release 2 Net Return
Cash
flow
Time
Release 1 Net Return
ProfitPeriod
Investment
Invest-mentPeriod
Pay-back
Period
BreakevenPoint
Total Return
Cash
flow
Time
staged releases
Cash
flow
BreakevenSingleRelease
First Release
Time
Staged Releases
10
increased profit
Cash
flow
Breakeven
Single Release
First Release
Time
Staged Releases
10
When competition is intense
Multi-Tasking
Request 1/Team 1
Month 1
Month 2Month 3
Request 2/Team 2
Request 3/Team 3
A Harder ProblemSCENARIO B
another way to think of it
Request 1
Month 1
Month 2Month 3
Request 2
Request 3
A Harder ProblemSCENARIO B
try this: quicker feedback
Project 1
Project 2
Project 3
Month 3Month 2Month 1 Month 4
Three ways to do three projects
Do one at a time – may not be politically feasible.
Do them all at once, switching between them when delayed waiting for answers
Do them guided by Minimal Marketable Features
Product Development for the Lean Enterprise by Michael Kennedy. Oaklea Press. 2003
Task-Switching and Schedules
Capacity Utilization
Busy Doesn’t Mean Productive
Eff iciency How do you measure i t ?
Keep ing peop le busyOr
Produc ing bus iness va lue
utilizationthroughput
@ throughput vs. utilization
Here’s a spot!
And another!
Miscellaneous
Technical Versus Business Technical Inside – Components –Architect Business – Outside
Risks – what are there?
© Warp and Byte Designs, Inc..
Observation
Anticipation of long delivery cycles encourages piling on of poorly prioritized requirements
Large batches create delay and waste
whileSmall batches create incremental value
FlowOptimiz
ethe
Whole!
Focus on
TIME
Getting Requirement
s
Testing
Programming
Design
Integration
Planning
Collaboration
Re-doing requirement
s
Working from old
requirements
“Fixing” bugs
“Integration” errors
Faster methods
Automation
Remove
Delays
Remove
Delays
Remove
Delays
Remove
DelaysDeploymen
t
Building unneede
d features
Overbuilding frameworks
Lack of feedback
Lack of Tech knowledge
What Work Do You Do?
TrainingDocumentatio
n
Essentially duplicating components
Lack of Tech knowledge/delay
Lean-Agile: Evolving Agility
Continually evolvingSustaining, not improvingDeclining
Initiation &
Rollout
Maturation
Lea
n-A
gil
ity
Year 1 Year 2 Year 3
Iterative Flow Highest Business Value
Low
∞
Project-based Business Value-based
Defined• Scope• Budget• Schedule
Require-ments
• Defined without priority
Limited evolution
• Scope• Budget and
schedule fixed
Big bang deploym
ent
• Build & deploy at end
Discovery
• Highest value• Allocate
budget
Require-ments
• Prioritized on Business Value
• Sequenced on ROI
Constant evolution
• Based on discovery
• Budget follows
Increments
• Build & deploy increments