Lean principles and practices have long been applied to manufacturing, with Agile arguably the inevitable evolution of Lean applied to knowledge-based work.   When viewed from a customer’s perspective much of software development may be seen as lower value.  How can organizations become lean by eliminating waste and working smarter? This presentation explores Lean principles and practices applied to software beginning with value stream mapping and the 7 (+1) types of waste.  Presented as an Agile 101 session at Agile New England on 5 August 2021.

1. Lean 101:
Applying Lean to Software
Focus on Lean principles, value stream mapping, and types of waste
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5
Presented at Agile New England, 5 August 2021

2. 2
Lean principles and practices have long been
applied to manufacturing, with Agile arguably the
inevitable evolution of Lean applied to knowledge-
based work.
When viewed from a customer’s perspective much
of software development may be seen as lower
value. How can organizations become lean by
eliminating waste and working smarter?
This session will explore Lean principles and
practices applied to software beginning with value
stream mapping and the 7 (+1) types of waste.
About the presentation… About the presenter…
David Hanson has applied Lean principles and
practices throughout his career, on both traditional
and Agile projects, to help eliminate waste in the
process and deliver value to the customer.
In 2013 David was certified as a Lean facilitator and
since then has been presenting versions of this
Lean 101 to help others apply Lean to software.
David is currently a Scrum master for the Data Lake
team in the Data & Analytics Organization at Mass
General Brigham.
Lean 101: Applying Lean to Software
https://www.slideshare.net/DavidHanson5 dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/

3. 3
“Our group already operates pretty lean.
Reporting to me, we have a project
manager, shared across projects, and
just one developer currently supporting
a half-dozen initiatives.”
Sound Lean?

4. 4
Lean? Lean!
Working
Smarter
Cutting
Waste
Working
Harder
Cutting
Staff
Lean?
Not Lean Lean
Lean seeks to maximize customer value and to
minimize process waste.
Lean is:
 A mindset
 A set of behaviors
 A skill set
 A tool set
Lean is a journey of continuous improvement.
Agile is founded on Lean.
Lean Introduction

5. 5
 Lean Principles
 Lean Process
 Value Stream
 Lean Waste
 Software Waste
 Waste Exercises
 Lean Toolkit
 Push vs. Pull
 Scrum and XP
 Lean History
Agenda

6. Exercise Preview
Zoom annotation
 Value
Required
 Waste

7. 7
Eliminate
Waste
Build
Quality In
Create
Knowledge
Defer
Commit-
ment
Deliver
Fast
Respect
People
Optimize
the Whole
Focus on
Customer
Lean Principles
1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole
8. Focus on Customer
Lean Foundation
Mary and Tom Poppendieck published the first 7 principles in Lean Software Development: An Agile Toolkit 2003.

8. 8
Management Analysts Scrum Master Security Product Owner Infrastructure
Data Scientists VIPs Support Data Governance PMO Marketing
Reporting Group Data Source Data Warehouse Project Sponsor Vendor Audit
Stakeholders
Who are the customers willing to pay for access to a data lake? 
Who are the stakeholders likely to drive required work that customers aren’t expecting to pay for? 
Data lake is a collection of structured and unstructured data;
e.g., tables, files, documents, and images

9. 9

10. 10
Lean Principles: Another View Expounded
Optimize the Whole Focus on Customers Energize Workers Eliminate Waste
Clarify purpose Ask the right questions Purpose Building the wrong thing
Appreciate entire value
stream
Solve the right problems Challenge Building the thing wrong
Think long term Design a great experience Responsibility Batch and queue mentality
Sources: www.poppendieck.com and www.leantoolkit.com
Learn First Deliver Fast Build Quality In Keep Getting Better
The predictability paradox Speed & quality lower cost Mistake proof the process Change as fast as the world
changes
Integrating events Focus on flow, not
resource, efficiency
Integrate early and often Pay attention to the small
stuff
Last responsible moment Manage workflow, not task
schedules
Don’t tolerate defects Use the scientific method

11. 11
The Predictability Paradox
Early planning is predictably wrong. Instead
develop a capacity to learn and adapt quickly.
Integrating Events
Integrating events identify issues, test options,
validate learning and reduce risks.
The Last Responsible Moment
Early decisions are expensive to change. Decide as
late as possible and just in time.
Learn First Deliver Fast
Speed, Quality & Low Cost are Compatible
Focus on delivering fast, will require quality and
lowers costs.
Focus on Flow Efficiency, not Resource Efficiency
Maximizing resource utilization impedes smooth
flow of value to customer.
Manage to Priorities not to Schedule*
Focus on pulling work based on customer priority,
not on pushing work based on scheduled dates.
Lean Principles: Focus on Two
Fail fast, learn fast
* My variation to Poppendiecks’ published principles.
The Predictability Paradox

12. 12
Lean Process: Five Steps to Lean*
* Often identified as Lean Principles
Identify Value
Map Value Stream
Create Flow
Establish Pull
Pursue Perfection
Identify value from customer perspective; aim to deliver
no more, no less
Map steps to create customer value with activity and wait
time; eliminate steps that do not create customer value
Create continuous flow to deliver value; remove obstacles
that impede smooth flow
Let customer demand pull value through entire value
stream; limit work in progress
Adopt culture which continuously pursues perfection

13. 13
 Creates competitive
advantage
 Transforms inputs into
outputs customer needs
or wants
 Customer willing to pay
for this activity
o Minimum standards or
required inputs
o Transforms inputs into
outputs customer may
not want, but may be
required
o Customer unlikely to pay
for this activity
× Creates waste, stress,
instability
× Transforms inputs into
outputs customer does
not want
× Customer unwilling to
pay for this activity
Value Added
Non-value Added
But Required* Non-value Added
Minimize Eliminate
Optimize
Types of Activity in Value Stream
*Non-value add but required may be regulatory or legal requirements, necessary inputs for setup or initiation, or safety and security necessities.

14. 14
Value Added Non-value Add But Required Non-value Added
Value Add?
How can this activity be
streamlined?
How can this activity be minimized
or can this activity be abandoned?
How can this activity be
eliminated?

15. 15

16. 16
Value Stream Map
Process efficiency is value add activity time / lead time
Lean organizations strive for >25% process efficiency
Research
Submit
Approve
Story
Refine
Planning
Code
Test
Debug
Retest
Request
Review
Acceptance
Debug
Retest
Deploy
Release
Reaccept
Request
Research
Submit
Approve
Story
Refine
Planning
Code
Test
Debug
Retest
Review
Acceptance
Debug
Retest
Reaccept
Signoff
Deploy
Release
Cycle Time
Lead Time
How can we improve process efficiency?
Cycle Time
Sprint
Signoff
Activity:
Value Add
Non-value Add But Required
Non-value Add
time

17. 17
Initiate Analysis Design Code Test Accept Deploy Close
Project Management
A Typical SDLC: How much is value add from a client’s viewpoint?
Initiate Analysis Design Code Test Accept Deploy Close
Maybe that’s not a fair view, but perhaps 2/3rds of our activity is not value add from the client’s perspective.
Project Management
A client’s view (perhaps):
1. Initiate: Sure, I need to get this started.
2. Analysis: At least this will help me understand what I want, I think.
3. Design: I don’t really care, as long as it works.
4. Code: Maybe I should have made it myself using Access.
5. Test: How many mistakes were caught by QA?
6. Accept: If I approve then at least I can use it, but did I really ask for this?
7. Deploy: Finally!
8. Close: Sign, where?
9. Project Management: Please, not another status report.
Value
Add
But
Required
Non-
value Add

18. 18
Eliminating waste in a typical development activity chain
Coding
required
function
Coding
needed
function
Coding
extra
function
Testing
required
function
Testing
needed
function
Testing
extra
function
Debugging
required
function
Debugging
needed
function
Debugging
extra
function
Retesting
required
function
Retesting
needed
function
Retesting
extra
function
Value Added: 2 of 12 steps
Non Value Added But Necessary: 2 of 12 steps
Non Value Added: 8 of 12 steps
Instead of focusing on how to optimize the value added steps, first focus on eliminating the non-value added steps
Finding better ways to do something useful or required is harder than finding ways to eliminate something useless
Maximize the work not done!

19. 19
Defects (product)
Overdone (process)
Waiting (people or process)
Neglect (people)
Transport (product)
Inventory (product)
Motion (people)
Excess (product)
Lean Waste: 7 types of waste (plus 1)
O and E interchangeable: Overproduction and Excess processing
Add Neglect as the plus 1 for the acronym DOWNTIME

20. 20
Defects
Overdone
Waiting
Neglect
Transport
Inventory
Motion
Excess
Bugs
Technical Debt
Delays
Relearning
Handovers
Work In Progress
Task Switching
Extra Features
Lean Waste: A Software Perspective
Poppendieck omits Neglect and Technical Debt, mapping Overdone to Relearning
underdone

21. 21
Defect | Bug Overdone | Tech Debt Wait | Delay Neglect | Relearning
Transport | Handover Inventory | WIP Motion | Multi-tasking Excess | Extra Features
Early test finds
performance
issue
1st team gets
file; 2nd team
loads file
Tracking dates
weekly on 30
milestones
Stakeholders
suggest
alternatives
during review
Start now for
delivery in 9
months
20-page
support doc
before go-live
Stories without
acceptance
View hides PII
data
DevOps
refactoring
Prod, but not
Dev
12 people
attend; 6
people
participate
Product
owners lack
Scrum training
Testing
postponed due
to
maintenance
New
environment
takes weeks to
configure
2nd team with
primary and
secondary
sprint goal
1st team with 5
sprint goals
EST <> EDT
Support 2
machine
learning
packages
PO writes
stories for
requirements
gathering
Same data
from source to
raw to refined
to curated
Team member
misses sprint
planning
Does the type of waste categorization really matter?
Type of Waste? Lean Waste | Software Waste

22. 22
Defect | Bug Overdone | Tech Debt Wait | Delay Neglect | Relearning
Transport | Handover Inventory | WIP Motion | Multi-tasking Excess | Extra Features
Test finds
performance
issue
Twice weekly
status report
1st team gets
file; 2nd team
loads file
Tracking dates
weekly on 2-
dozen
milestones
Stakeholders
suggest
alternatives
during review
Start now for
delivery in 9
months
OKRs defined,
but not shared
Product owner
doubles as
tech lead
20-page
support doc
before go-live
Stories without
acceptance
Team members
not T-shaped
View hides PII
data
DevOps
refactoring
Prod, but not
Dev
1st team pulls
story, then
assigns tasks to
2nd team
12 people
attend; 6
people
participate
Product
owners lack
Scrum training
Development
w/o test data
Testing
postponed due
to
maintenance
Key participant
arrives 5 min
late
New
environment
takes weeks to
configure
2nd team with
primary and
secondary
sprint goal
1st team with 5
sprint goals
EST <> EDT
Production
dashboard
without user
Tableau,
Cognos, Power
BI
PO writes
stories for
requirements
gathering
Same data
from source to
raw to refined
to curated
Team member
misses sprint
planning
Does the type of waste categorization really matter?
Type of Waste? My Categorization

23. Lean Toolkit
Lean manufacturing has developed
dozens of practices which can be applied
effectively to software development

24. 24
More Tools in the Lean Toolkit
Not to be overlooked Value Stream Mapping and Lean Waste covered in depth in prior slides
Lean Canvas
Single page project definitions
useful to quickly assess and
prioritize projects
A3 Problem Solving
Single 11x17 sheet useful for
tracking problem from current
state to future state to solution
5 Whys
Simple technique asking why
five times to find the deeper
root cause of an issue
Voice of Customer
Ask who, what, why, when and
where to gather the voice of
your customer
Gemba Walk
Go-and-see, observing business
processes and software
development first-hand
SIPOC
Process flow technique
following supplier > input >
process > output > customer
5S
Organize work and workplace
using sort, straighten, shine,
standardize, sustain
A3
A
4
A
4
Why?
Why?
Why?
Why?
Why?
Who
What
Why
When
Where
S I P O C
S
S
S
S
S
Fishbone
Sophisticated technique for
finding multiple root causes
from various sources
5

25. 25
Frequently Practiced:
• Kanban
• Kaizen
• Pareto Principle
• Plan-Do-Check-Act
• MoSCoW
Occasionally Used:
• Andon Cord
• Takt Time
• Single Piece Flow
• Poka-Yoke
• Kano Analysis
Related to Lean:
• Day-in-the-Life
• Silent Brainstorming
• Mind Mapping
• SMART Goals
• Empathy Mapping
Even More Tools in the Lean Box
And there are still many more…

26. Pull, not Push
A Case Study

27. 27
Traditional Process with Push: Flow Becomes Uneven
As work is pushed onto the queue, flow becomes uneven, with work often stalled in the process.
Requirements Specification Design Development Testing Acceptance Release

28. 28
Traditional Process with Pull: Flow Becomes Smooth
As work is pulled through the queue, flow becomes smooth; only then can new work be added.
Requirements Specification Design Development Testing Acceptance Release
Kanban:
Visualize Work
Limit WIP
Continuous Flow
What could we try to reduce cycle time?

29. Pull, Don’t Push
Pushing work onto the queue based on schedule is resulting in too much work
in analysis and design phases
Changing focus to pulling work through the process into production will result
in better flow and higher productivity

30. 30
Keep Getting Better
Change as Fast as the World Changes
Don’t let today’s best practice prevent adoption of tomorrow’s better practice.
Lean Principles: One more, briefly

31. Appendix
Flow with Scrum and XP
Lean history

32. 32
Scrum Process Flow
Regular backlog refinement creates a steady flow of ready stories.
Advanced deployment strategies complete user acceptance in production.
Test
Code
Design
Not
Ready
To Do Doing Done
Ready
Increment
Product
Backlog Refinement Sprint Acceptance Release

33. 33
Scrum Process Flow: supplemented with XP practices
Regular backlog refinement creates a steady flow of ready stories.
Advanced deployment strategies complete user acceptance in production.
Test
Code
Design
Not
Ready
To Do Doing Done
Backlog Refinement Sprint Acceptance Release
Ready
Incre-
ment
Product
1 day
XP
Refactor

34. 34
Toyota is often credited as inventing Lean with the
Toyota Production System, however the history, like
Lean itself, is one of continuous evolution and
improvement with numerous contributors and
practitioners.
A few key figures from the last century:
Frederick Taylor
Frank Gilbreth
Henry Ford Sakichi Toyoda
Edwards Deming Kiichiro Toyota
Joseph Juran Taiichi Ohno
Shigeo Shingo
Agile is the next advance in the evolution of Lean.
Lean Manufacturing: Origins
http://www.strategosinc.com/lean_manufacturing_history.htm

35. Alternate Exercises
not used

36. 36
Alert sent
when job fails
Sample Activity
Just a few examples that I’ve seen recently
Team
members
work in pairs
12 people
attend; 6
people
participate
Tracking dates
on dozens of
milestones
Two weekly
status reports
Early testing
finds
performance
issue
OKRs defined,
but not shared
Stakeholders
suggest
alternatives
during review
1st team gets
file; 2nd team
loads file
Stories
without
acceptance
20-page
support doc
before go-live
Key
participant
arrives 5 min
late
Product owner
lacks Scrum
training
Requirements
signed off by
stakeholder
Development
w/o test data
PO writes
stories for
requirements
gathering
PII data
removed
One team with
5 sprint goals
Two teams
with common
sprint goal
New
environment
takes weeks to
configure
New member
submits access
request
1st team pulls
story, then
assigns tasks
to 2nd team
Testing
postponed
due to
maintenance
Start now for
delivery in 9
months

37. 37
Alert sent
when job fails
Sample Activity
Just a few examples that I’ve seen recently
Team
members
work in pairs
12 people
attend; 6
people
participate
Tracking dates
on dozens of
milestones
Two weekly
status reports
Early testing
finds
performance
issue
OKRs defined,
but not shared
Stakeholders
suggest
alternatives
during review
1st team gets
file; 2nd team
loads file
Stories
without
acceptance
20-page
support doc
before go-live
Key
participant
arrives 5 min
late
Product owner
lacks Scrum
training
Requirements
signed off by
stakeholder
Development
w/o test data
PO writes
stories for
requirements
gathering
PII data
removed
One team with
5 sprint goals
Two teams
with common
sprint goal
New
environment
takes weeks to
configure
New member
submits access
request
1st team pulls
story, then
assigns tasks
to 2nd team
Testing
postponed
due to
maintenance
Start now for
delivery in 9
months

38. 38
Type of Waste? Lean Waste | Software Waste
Add your own examples
Defect | Bug Overdone | Tech Debt Wait | Delay Neglect | Relearning
Transport | Handover Inventory | WIP Motion | Multi-tasking Excess | Extra Features