Many people equate Lean and agile or claim that one is a subset of the other. In fact, they have almost opposite emphases: thinking versus doing; teams versus individuals; planning versus reacting; and many more. This talk will help you clarify the distinction in a way that will help you focus soberly on how to improve your environment, team, product and process, by going beyond the buzzwords to the fundamental building blocks.
1 of 31
More Related Content
Balancing the tension between Lean and Agile
1. Balancing the Tension
between Lean and Agile
James O. Coplien
Gertrud&Cope
Scrum Training Institute
cope@gertrudandcope.com
2. What is Agile?
We all know the Manifesto
It comes down to two things:
Self-organization
Feedback
An exercise exemplifying Agile
4. What is Lean?
Lean is a more complex system aimed at
adding value for the end user
To do that,
We eliminate waste
We eliminate inconsistency
We smooth out flow
We are constantly improving: Kaizen
An exercise to illustrate Lean
5. Just a thought...
Lean:
Eliminate Waste
Eliminate
inconsistency
Smooth out flow
Agile:
Favor product over
documentation
Communication
Sustainable pace
Snowden and Boone, A Leader’s Framework for Decision Making, Harvard Business Review, Nov. 2007
6. Reflection
What can you learn from the Agile exercise
that would help software development?
What about the same for the Lean exercise?
What is common between these two
exercises?
What is different?
Can you see any conflicts between them?
9. Complex versus
Complicated
Agile: Dealing with
complex systems:
autopoeietic
systems, self-
organization; wholes
greater than the
sum of their parts
Lean: Dealing with
complicated
systems. Building a
car is complicated
but not complex;
the whole is the
sum of its parts
Snowden and Boone, A Leader’s Framework for Decision Making, Harvard Business Review, Nov. 2007
13. Rework
Agile: Refactoring
compensates for
architectural short-
sightedness,
maintenance, and
emergent
requirements (as
well as keeping the
code clean)
Lean: Rework in
design adds value,
while rework in
production is waste
(Ballard: Negative
Iteration, Lean
Institute)
Ballard, Glenn, Positive vs Negative Iteration in Design. Lean construction Institute, University of California, Berkeley
14. Last Responsible
Moment
Agile: early
decisions are likely
to be wrong and
cause rework, so
defer to the last
responsible
moment
Lean: letting a
decision go beyond
the point where it
affects other
decisions causes
rework, so bring
decisions forward to
a point where their
results don’t
propagate
Ballard, Glenn, Positive vs Negative Iteration in Design. Lean construction Institute, University of California, Berkeley
15. Summary
Complex vs Complicated
Ad-hoc vs Standards
Doing vs Thinking
Generalization vs Specialization
Rework vs Protoyping
Late versus Early Decisions
16. Focus
Agile: Doing
Where is the thinking
in Scrum?
Scrum allows thinking
but neither requires it
nor provides
techniques for it
Agile is about doing
just enough to get
just enough quality
Lean: Doing and
thinking
Lean requires
thinking and even
planning
Lean is about doing
the least you can do
to achieve
excellence
17. Repercussions
Agile fears future change; Lean embraces it
Enlist a fire brigade or build a brick city?
Agile shuns architecture; Lean considers it essential
Agile avoids committing to agreed standards; Lean is
about commitment
Agile is about individuals; Lean about teams
Agile diffuses responsibility; Lean encourages it
Agile puts value in production rework (refactor; do-
inspect-adapt); Lean avoids rework (design, inspect-
plan-do)
18. Reflection
We can mix Lean and Agile
Reflect on a mixture of practices, ideas, and
philosophies that combine Lean and Agile
thinking
19. Scrum
Comes from a Lean legacy, but has many
trappings we associate with Agile
Common problems in Scrum implementations:
People don’t do the up-front analysis, lean
architecture
People don’t take the value chain out to the
end user
People think locally rather than in terms of
their networks
20. Does the Nokia Test test
Lean or Agile?
Iterations
Expanding scope of Done to deployment
Up-front specifications w/User Stories
Product owner who plans
Up-front Product Backlog
Up-front estimates
Business-oriented burndown chart
Team disruption
21. Most Nokia Test points
are Lean — not Agile
Iterations (Agile)
Expanding scope of Done to deployment
(Lean)
Up-front specifications w/User Stories (Lean)
Product owner who plans (Lean)
Up-front Product Backlog (Lean: DSM)
Up-front estimates (Lean planning)
Business-oriented burndown chart (Lean)
Team disruption (Agile)
22. Summary: The Lean /
Agile Compromise
Do up-front work — but minimize artefact
inventory and be postured for change
Prototypes and enabling specifications
Architecture
Make short-term sacrifices for long-term ROI
Pay strong attention to common strengths,
such as short feedback loops
Use common sense!
25. 2. Testing
No dedicated QA - 0
Unit tested - 1
Feature tested - 5
Feature tested as soon as completed - 7
Software passes acceptance testing - 8
Software is deployed - 10
Back
26. 3. Agile Specification
No requirements - 0
Big requirements document - 1
Poor user stories - 4
Good requirements - 5
Good user stories - 7
Software is deployed - 10
Just enough, just in time specifications - 8
Good user stories tied to specifications as
needed - 10
Back
27. 4. Product Owner
No Product Owner - 0
Ignorant product owner - 1
Meddling product owner - 2
Detached product owner - 2
Product owner with clear product backlog estimated
by team before Sprint Planning meeting (READY) -
5
Product owner with release road map based on
team velocity - 8
Product owner who motivates the team - 10
Back
28. 5. Product Backlog
No Product Backlog - 0
Multiple product backlogs - 1
Single product backlog - 3
Product backlog clearly specified and ordered for
ROI before sprint planning (READY) - 5
Product owner with release plan based on Product
Backlog - 7
Product Owner can measure ROI based on
revenue, cost per story point, or other metrics - 10
Back
29. 6. Estimates
Product Backlog not estimated - 0
Estimates not produced by team - 1
Estimates not produced by planning poker - 5
Estimates produced by planning poker by
team - 8
Estimate error < 10% - 10
Back
30. 7. Burndown Chart
No burndown chart - 0
Burndown chart not updated by team - 1
Partial task burndown - 2
Using Track Done - 4
Using Track Story done - 5
Add 3 points if the team knows velocity
Add 2 points if Product Owner release plan is
based on known velocity
Back
31. 8. Team Disruption
Manager / Project Leader disrupts team - 0
Product Owner disrupts team - 1
Managers, Project Leaders or Team Leaders
assign tasks - 3
Have Project Leader and Scrum roles - 5
No one disrupts team, only Scrum roles - 10
Back
Editor's Notes
Most of you have seen the Agile Manifesto. It is a brilliant document, and we let it speak for itself here. Let me ask you a couple of things about the Manifesto:
What does it say about iteration?
What does it say about customer satisfaction with the product?
What new things does it tell you to do that you are not already doing?
What are the consequences of using processes, tools, documentation, contracts, and plans?
You get the idea. The Manifesto is a framework for thinking about what you value; it is not a framework that you can fill in according to your needs.
It is nonetheless a firm starting point for Scrum—which itself is a framework that guides you and you can fill in. However, don’t leave your brains behind: you will need your wits just as much as a Scrum practitioner as an Agile fan.