Lean software engineering emphasizes continuous delivery of high quality applications. Ken Pugh explains the principles and practices that form the basis of lean software development―concentrating on developing a continuous flow by eliminating delays and loopbacks; delivering quickly by developing in small batches; emphasizing high quality which decreases delays due to defect repair; making policies, process and progress transparent; optimizing the whole rather than individual steps; and becoming more efficient by decreasing waste. Ken describes lean’s emphasis on cycle time, rather than resource utilization, and demonstrates the value stream map which helps you visualize the development cycle flow to identify bottlenecks. He explores the differences between push and pull flow, describes how lean thinking shows up in agile processes including Scrum and Extreme Programming, and discusses how lean can be applied to the entire workflow—not just the development portion. Ken concludes with a discussion of how you can begin your lean transformation.

1. LEAN-agile
© copyright 2010. Net Objectives, Inc.
B E C O M I N G
Lean Software For
Everyone
Ken Pugh
Fellow Consultant
KP Aug 2014

2. • Introduction and
Background
• Lean as Flow
• Lean Software Development
• Lean-Agile
• Transforming into Lean
Outline

3. Ken Pugh
ken.pugh
@netobjectives.com
Photo
Size:
Height: 2.25
Position:
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

4. Lean
Enterprise
Business
Manag
ement
Team
ASSESSMENTS
CONSULTING
TRAINING
COACHING
Lean for
Executives
Product Portfolio
Management
Business Product
Owner
Lean Management
Project
Management
ILAFYT
Kanban / Scrum
ATDD / TDD / Design Patterns
technical process

5.  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

6. Overall Rule
 There are exceptions to every statement, except
this one
6

7. copyright © 2010 Net Objectives Inc.
Introduction and
Background

8.  Lean software engineering
– Continuous delivery of high quality applications
In short

9.  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

10.  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)

11.  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

12.  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

13.  Eliminate Waste
 Create Knowledge
 Build Quality In
 Defer Commitment
 Deliver Fast
 Respect People
 Improve the System
Lean Software Development
Principle

14. Agile

15. copyright © 2010 Net Objectives Inc.
Workflow

17. drive from
Business Value

20. concentration

21. Idea
Business decision
Implementation
Availability
FLOW
© Warp and

22. outcome

24. business value
trumps Reducing Waste
© Warp and Byte Designs, Inc..

25. Flow From Concept to Consumption

26. 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

27. 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

28. Business Value
Projects
Next Project BV = 8
Current Project BV = 13
Previous Project BV= 20

29. Transparency – Trust

30. Transparency
To Do Working On Done
Next Project Current Project Previous Project

31.  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

32. Small Pieces
To Do Working On Done
Current Project Current Part Previous part
Still Another Part
Another Part
Some Part

33. Flow

34. Business
Priority
BUSINESS DISCOVERY BUSINESS DELIVERY
Business
Planning
Business
Readiness
Ready
to Pull
Incremental
Development
Incremental
Deployment
Support &
Feedback
Decision
Is it technically
feasible?
Decision
Is it ready to
release?
PORTFOLIO
Decision
Is there enough
business value?
Flow

35. Cycle Time

36. Lean Principle
Idea to Delivery
Support &
Feedback
Project
Approval
Project
Staffing
Project
Development
Project
Deploy-
ment
Visioning
Total cycle time

37. Lean Principle
Support &
Feedback
Project
Approval
Project
Staffing
Project
Development
Project
Deploy-
ment
Visioning
Support &
Feedback
Project
Development
Project
Deployment
$$$ Cost

38. Support &
Feedback
Project
Approval
Project
Staffing
Project
Development
Project
Deploy-
ment
Visioning
Support &
Feedback
Project
Development
Project
Deployment
Project
Approval
Project
Staffing
Visioning
Lean Principle
Opportunity Cost

39. Value Stream

40. 1. Identify the actions taken in the value stream
Approv
e
Request Reqts Sign Off
Review Deploy
Analysis
Design Code Test

41. 0.5 hrs 160 hrs8 hrs 8 hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
Approv
e
Request Reqts Sign Off
Review Deploy
Analysis
Design Code Test
1. Identify the actions taken in the value stream
2. What was the real time from start to finish of the action?

42. 0.5 hrs 160 hrs8 hrs 8hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs
1. Identify the actions taken in the value stream
2. 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?

43. 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
80 hrs
160 hrs 80 hrs 80 hrs 80 hrs
1. Identify the actions taken in the value stream
2. 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
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs

44. 16 June 2015
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 stream
2. 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
5. Identify any loop backs required
80 hrs
65% defective
Repeat 3X
20% rejected
Repeat 1X
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs

45. 1. Identify the actions taken in the value stream
2. 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
5. Identify any loop backs required
6. Calculate Process Cycle Efficiency:
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hrs
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 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% defective
Repeat 3X
20% rejected
Repeat 1X
80 hrs
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hrs
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 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% defective
Repeat 3X
20% rejected
Repeat 1X
80 hrs
80 hrs
PCE = = 14.9%
509 hrs
3433 hrs
509 hrs
3433 hrs
Avg Time Worked
Total Cycle Time

46. Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hrs
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 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% defective
Repeat 3X
20% rejected
Repeat 1X
80 hrs
320 hrs 80 hrs 320 hrs 80 hrs
160 hrs 80 hrs 80 hrs
65% defective
Repeat 3X
20% rejected
Repeat 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?

47. Cycle Time
 What’s the cycle time from input to output?
 How can it be shortened?
– Eliminate delays
– Eliminate loop-backs
– Manage WIP
–

48. Waste and Delays

49. 1. Partially Done Work
2. Paperwork
3. Extra Features
4. Task Switching
5. Handoffs
6. Delays
7. Defects
Waste Indicators

50. how much of what you do is
valuable?
rework?

51. DELAY IS hand-offs
bottlenecks
information delay
untested code
unread requirements
transaction related
setup/cleanup
coordination related
assign people
finding
redoing
reworking
waiting


52. Pull

53. PUSH

54. 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

55. PULL

56. BUT LIMIT QUEUES

57. Reduce WIP
Queuing theory
Focus on quality

58. Practice

59. EXERCISE
Part One
AGILE IS FUN

60. EXERCISE
Part Two
AGILE IS FUN

61. Lean Software
Development

62.  Implement lean across entire value stream
– To deliver business value
– Not just improve development
Optimize the Whole /
See the Whole

63.  Focus on customer value
 Only start work that can be completed
Eliminate Waste

64.  Move tests forward
– Acceptance Test Driven Development
 Automated testing
 Write change tolerant code
Build Quality In / Build Integrity In

65.  Small batches
 Get feedback fast
 Emphasize cycle time, not utilization
Deliver Fast / As Possible

66.  Use knowledge learned from creating application
 Cross-functional teams to share knowledge
 Quick feedback
Create Knowledge
/ Amplify Learning

67.  Create clear frameworks for decisions
 Decision making at lowest possible level
Empower People / The Team

68.  Periodic reflections
 Perform root cause analysis
Continually Improve

69.  Wait till last practical moment to make decision
– More information available
Defer Commitment /
Decide as Late as Possible

70. Points and
Practices

71.  Driving in Germany - picture of autobahn
© Warp and Byte Designs, Inc..

72. © Warp and Byte Designs, Inc..

73. Measurement

74. © Warp and Byte Designs,

75. Metrics
What is important?
Customer /user satisfaction
Production defects
Rate of delivery
of business value
© Warp and Byte Designs, Inc..

76. copyright © 2010 Net Objectives Inc.
Lean – Agile

77.  Apply lean principles/practices to agile processes
 What lean principles/practices do you see in
– Scrum
– Kanban
Lean Agility

78. Thinking
l e a n a g i l e
WHAT is the most important thing
WHEN is it most needed
HOW we break down that work
HOW we FLOW that work

79. Delivering
Thinking
l e a n a g i l e
Breaking work down
Creating the best environment to deliver that work
Incremental and Iterative development

80. Business Value
Delivering
Thinking
l e a n a g i l e

81. copyright © 2010 Net Objectives Inc.
Beginning the
Transformation

82. 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

83. Old Status Quo New Status Quo
Chaos Transforming Idea
Change Model
From
Virginia Satir

84. copyright © 2010 Net Objectives Inc.
This is Not an Ending,
But a Beginning

85.  Shorten time to realize values
 Pay attention to delays
 Actively manage queues
 Emphasize cycle time, not utilization
Summary - Focus on Flow

86. copyright © 2010 Net Objectives Inc.
Supplementary

87. Roles
Purpose

88. MAKE
• INCREMENTAL DELIVERY
• CREATIVELY SOLVING
THEIR PROBLEMS
• QUALITY BUILT IN
technical

89. technic
al
VALUE
• PRIORITIZATION
• BUSINESS ITERATIONS
• RELEASE PLANNING

90. FLOW
• VALUE STREAM VISUALIZATION
• IMPEDIMENT IMPACT
• WORKFLOW AS PROCESS
technic
al
WITH
ACCOUNTABILITY
• MANAGE (LIMIT) QUEUES
• VISUAL CONTROLS
• MANAGE FLOW (PROCESS)

92. Business Value

93. Question
 What percentage of features are never used?

94. Waste and the Delay of Value
Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never Used
45%
Source: Standish Group
Study of 2000 projects at
1000 companies
Usage of Features
and Functions in
Typical System
_g

95. Teams

96. © U.S. Army

97. © Warp and Byte Designs, In
Successful teams
Collaborate
Shared accountability
Shared approach to doing work
Shared history

98. © Warp and Byte Designs, Inc..

99. Feedback

100. Agile Feedback – Small Increments
100
No feedback
Desired Delivered
With feedback
Desired
Delivered

101. Frequency of feedback

102. Deliver Quickly

103. Focus on known, valuable features
gives greater certainty
produces greater value
lowers risk of mis-building and over-building
Deliver
in Stages when possible


104. do the most important half first
standard development sequence
More important Less important

105. do the most important 25% first
standard development sequence
More important Less important

107. First Release
Investment
Period
Payback
Period
Profit
Period
Breakeven
Cashflow
Time
economics of responsiveness
Mark Denne and Jane Cleland-Huang, Software by Numbers.

108. Staged Releases
First
Release
Invest-
ment
Period
Profit
Period
Pay-
back
Period
Cashflow
Time
Release 1 Net Return

109. Staged Releases
Profit
Period
Second
Release
Invest-
ment
Period
Pay-
back
Period
Release 2 Net Return
Cashflow
Time
Release 1 Net Return

110. Profit
Period
Investment
Invest-
ment
Period
Pay-
back
Period
Breakeven
Point
Total Return
Cashflow
Time
staged releases

111. Cashflow
Breakeven
Single
Release
First Release
Time
Staged
Releases
10
increased profit

112. Cashflow
Breakeven
Single Release
First Release
Time
Staged
Releases
10
When competition
is intense

113. Multi-Tasking

114. Request 1/Team 1
Request 2/Team 2
Request 3/Team 3
A Harder ProblemSCENARIO B
another way to think of it

115. Request 1
Request 2
Request 3
A Harder ProblemSCENARIO B
try this: quicker feedback

116. 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

117. Capacity Utilization

119. Efficiency
H o w d o y o u m e a s u r e i t ?
K e e p i n g p e o p l e b u s y
O r
P r o d u c i n g b u s i n e s s v a l u e

120. @ throughput vs. utilization
Here’s
a spot!
And
another!

121. Miscellaneous

122. Technical Versus Business
 Technical Inside – Components –Architect
 Business – Outside

123. Risks – what are there?
© Warp and Byte Designs, Inc..

124. Observation
 Anticipation of long delivery cycles encourages
piling on of poorly prioritized requirements

126. Getting
Requirements
Testing
Programming
Design
Integration
Planning
Collaboration
Re-doing
requirements
Working from old
requirements
“Fixing” bugs
“Integration”
errors
Deployment
Building
unneeded
features
Overbuilding
frameworks
What Work Do You Do?
Training
Documentation
Essentially
duplicating
components

127. Lean-Agile: Evolving Agility
Continually evolving
Sustaining, not improving
DecliningMaturation
Lean-Agility
Year 1 Year 2 Year 3
Iterative  Flow  Highest Business Value
Low
∞

128. Project-based Business Value-based
• Scope
• Budget
• Schedule
Defined
• Defined without
priority
Require-
ments
• Scope
• Budget and
schedule fixed
Limited
evolution
• Build & deploy
at end
Big bang
deployment
• Highest value
• Allocate budget
Discovery
• Prioritized on
Business Value
• Sequenced on
ROI
Require-
ments
• Based on
discovery
• Budget follows
Constant
evolution
• Build & deploy
increments Increments