Post on 08-May-2015
8/15/12
1
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 1
Scaling Lean|Agile Development Myths and Ideologies Meet the Scaled Agile Framework
Dean Leffingwell deanleffingwell@gmail.com
DeanLeffingwell.com ScalingSoftwareAgilityblog.com
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 2
Myths and Ideologies
1. Scaling Value: Not everything is a User Story
2. Scaling Team and Timebox: No team is an island
3. Scaling Design: Emergent design meets intentional architecture
4. Scaling Portfolio Management: Addressing legacy mindsets
5. Scaling Leadership: Your enterprise can be no leaner than your executives thinking
Agile: • Myths • Ideologies • Misperceptions • Legacy Mindsets
8/15/12
2
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 3
Context for Scaling Lean and Agile
Respect for People
Product Development
Flow
Continuous Improvement
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 4
Lean Goal: Speed, Value, Quality
All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we collect the cash. And we are reducing the time line by reducing the non-value added wastes. Taiichi Ohno
We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds.
Poppendieck Minimize delays, handoffs and non-
value added activities
The Goal of Lean: Sustainably shortest lead time
• Best quality and value to people and society
• Most customer delight, lowest cost, high morale, safety
8/15/12
3
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 5
Lean Goal: Speed, Value, Quality
Take an economic view Actively manage queues Understand and exploit
variability Reduce batch sizes Apply WIP constraints Control flow under
uncertainty: cadence and synchronization
Get feedback as fast as possible
Decentralize control
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 6
The Scaled Agile Framework™
The Scaled Agile Framework (“SAFe”) is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale
More on SAFe: Synchronizes the vision,
planning, interdependencies, and delivery of many teams
Web version available to public since February 2012
Works well for teams of 50-100
Has been scaled to hundreds of teams and thousands of people
Browse the framework at ScaledAgileFramework.com
8/15/12
4
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 7
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 8
#1 Scaling Value Not Everything is a User Story
8/15/12
5
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 9
Agile Teams Know User Stories
The Team Backlog consists primarily of the user stories that express the needs of the stakeholders
User stories are negotiable, expressions of intent
Expressed in user-voice form:
A great invention, User Stories replace traditional requirements expression
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 10
User Story Scaling Problems
If a large program requires – 10 teams that plan two PSIs at a time, about 10 weeks apart – If each team averages 10 stories per two week iteration, then
1,000 stories must be elaborated – How can an enterprise reason about 1,000 things? (On just
the one program!)
– And if we are about half done (500 stories), what do we actually have working, and how would we describe that to our customer?
And – Even if I know 500 things that “as a <role> I can <activity> so
that <business value>”, can do What Features does the system offer and what Benefits does each provide? What is the larger purpose here?
Billions and billions of stories
8/15/12
6
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 11
Features Fill the Program Backlog
The term “Feature” is an industry-standard term familiar to Marketing and Product Management.
Features are identified, prioritized, estimated, and maintained in the Program Backlog.
Features can be expressed as a short phrase describing the feature, along with its benefits.
A Feature is a service that fulfills a user need
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 12
Actively Manage Backlogs (Queues)
Backlogs are a form of queue (If items are committed, then it is a queue)
The longer the queue, the slower the delivery (Little’s Law)
Operating at high levels of utilization increases variability
For fast, and predictable results:
Reinertsen, Principles of Product Development Flow, 2009.
• Keep the backlogs short and uncommitted
• Limit WIP to keep planned utilizations at 80% or below
8/15/12
7
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 13
Epics and the Portfolio Backlog
Business Epics are customer-facing solutions
Architecture Epics are technology solutions which enable the business needs, improve operational efficiencies, or drive innovation
Epics are identified, prioritized, estimated, and maintained in the Portfolio Backlog
Work-in-progress limits are set to minimize the number of unfinished Epics at any given time. They are managed through a Kanban system.
Epics often cut across teams, releases, programs, and systems
Epics can be expressed in any form to communicate the intent of the initiative (a business case, prototype, etc.)
Epics describe large-scale development initiatives which are the highest level expression of a business
or technology need
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 14
“Cover your eyes”…Enterprise Backlog Technical View
Realized by Realized by
0,1 1..* 0,1 1..*
Is one of
Constrained by
0, 1 1..*
Realized by
Done when passes
1..*
1
1..* 0..*
Compliant when passes
0..* 0..*
Is one of Is one of
1..*
1
0..*
Done when passes
1
Source: 2011, Leffingwell, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. © Pearson Education
8/15/12
8
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 15
#2−Scaling Team and Timebox No Team is an island
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 16
‘Tis far better to have agile teams than non-agile teams, BUT How do we know what they are doing?
How do we know how well they are performing? How do we manage interdependencies?
How do we know if they are working to a common mission? How do we know we are getting the benefits for the enterprise? How can we harness all that new found energy and entropy?
The Problem with “Pockets of Agility”
The Agile, Twelve Tribes of Israel Problem:
There is more value created with overall alignment than with local excellence. – Don Reinertsen.
8/15/12
9
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 17
Everybody Must Be on the Agile Train
Waterfall Doesn’t Work
delay
Planned release
MRD PRD SRS Dev Drop 1 to QA
Drop 2 to QA
Test drop 1
Release docs
Test drop 2
Ports, certs
Actual release
Agile Works Better
Iterate Iterate Iterate
Release docs
Ports, certs
Iterate Iterate Iterate
Mixing doesn’t work
What do we integrate here?
PSI
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 18
But Cadence Alone is Not Enough
Planned system release date
…....time spent thinking you are on track……. Integrate and slip!
System
External Release
External Release
External Release
PSI
PSI
Iterate Iterate Iterate Iterate Iterate Iterate
Iterate Iterate Iterate Iterate
PSI
Iterate Iterate Iterate Iterate Iterate Iterate
Release docs
Port and certs
Port and certs
Release docs
Release docs
8/15/12
10
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 19
Synchronize to Assure Delivery
First PSI Second System PSI or Release
Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 Sys 7 Sys 8
Iterate Iterate Iterate Iterate Iterate Iterate
Iterate Iterate Iterate Iterate Iterate Iterate
Iterate Iterate Iterate Iterate Iterate Iterate
System Iterations
External Release
External Release
External Release
Release docs
Ports certs
Release Docs
Release Docs
Ports certs
Ports certs
PSI
PSI
PSI
Continuous Integration
Continuous Integration
Continuous Integration
System Team
Dev Teams
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 20
Align teams to a common mission Standardize iteration lengths; normalize estimating units Use cadence and synchronization to manage R&D variability
A fractal above the agile team. Same shape; similar behavior; different parameters
Solution: The Agile Release Train
Organize “agile release trains” wherever you have a number of teams provding continuous value delivery
Agile Release Train delivers solutions
NFRs Iterations Iterations
NFRs
NFRs
Agile Teams
Product Owner
Scum/Agile Master
Developers & Testers
Team
Bac
klog
Team
Bac
klog
Iterations Iterations
Stories
Stories
Pla
n
Dem
o &
Ret
ro Stories fit in
iterations Implemented
by Tasks
Spikes are research and
design Stories
Pla
n
Dem
o &
Ret
ro D B
T
Team
Features and components
8/15/12
11
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 21
NFRs
NFRs
Organized around enterprise value streams
Create self-planning, self-organizing, self-managing agile programs
Self-manages interdependencies amongst teams Full, system-level solutions available every 8-10 weeks
The Agile Release Train
H
H
H
H
Agile Teams
Product Owner
Scum/Agile Master
Developers & Testers
Team
Bac
klog
Team
Bac
klog
Iterations Iterations
Stories
Stories
Pla
n
Dem
o &
Ret
ro Stories fit in
iterations Implemented
by Tasks
Spikes are research and
design Stories
Pla
n
Dem
o &
Ret
ro D B
T
Team
Features and components
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 22
Separation of Concerns
Agile Release to Market Process
Asynchronous Collaborative
Agile Development Train Process 7/1/2011 4/1/2011 1/1/2011 10/1/2011 7/1/2011
Key Customer upgrade
Possible New product
PSI 5 PSIPSI 3 PSI1
Customer preview Docs and
certs
General Availability Firewall
Release Release
Docs and certs
Scenario A: Release less frequently than cadence
8/15/12
12
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 23
Release Whenever You Like
Scenario B: Release on cadence
Scenario C: Release more frequently than cadence
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 24
What Is a Release Train, Really? A Fractal.
Team
Plan
Commit
Execute
One sprint (2 weeks)
Product Owner
Scum/Agile Master
5-10 teams
One PSI (8-10 weeks)
Execute
Team
8/15/12
13
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 25
What is a PSI, Really?
Value Accumulates small
increments into newsworthy value
Releasable, or released, or not, announced or not
Value that can be planned, measured and assessed with strategic feedback
Timebox Makes planning
routine; lowers planning transaction costs
Limits deviation from plan to a single interval
Suitable for internal roadmapping and external commitments
A strategic quantum of value and timebox
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 26
Scaling Fast Feedback with a System Team
The System Team brings system assets together early and often, allowing fast feedback with objective evaluation
NFRs
NFRs
NFRs NFRs
System Team Feature
Nonfunctional Requirement
Prog
ram
Back
log
Roadmap
Vision
Product Management
Release Management
Shared
Team
Bac
klog
Agile Teams
Product Owner
Scum/Agile Master
Developers & Testers
Team
Bac
klog
Team
Bac
klog
Iterations
Stories
Stories
Pla
n
Dem
o &
Ret
ro D B
T
Release Planning
Stories
Pla
n
Dem
o &
Ret
ro
Build/supports development infrastructure
Full system integration and end to end testing
Integration with third party components
Program demos Interface to deployment
8/15/12
14
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 27
Scaling Tracking: Features, Not Just Stories
Understand completeness of each feature compared to plan at any point in time
" Automatically compiled from number of stories completed/stories remaining in agile project management tooling
" Facilitates decisions of what changes might be necessary to successfully deliver the PSI
70
50
45
20
30
60
20
30
26
20
80
30
40
40
40
62
40
33
28
30
0 10 20 30 40 50 60 70 80 90
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
Feature 7
Feature 8
Feature 9
Feature 10 PLAN
ACTUAL
100
Plan Actual - if within 15% Actual - if >15% behind
Percent Complete
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 28
Scaling Improvement: Inspect and Adapt
Rel
ease
Pla
nnin
g
Establish accountability Create new stories Specify measurable results Set achievable deadlines Monitor progress
Program-level Root Cause Analysis/ Improvement Story Workshop. Every PSI
PSI |
Rel
ease
I&A
8/15/12
15
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 29
#3−Scaling Design: Emergent design meets intentional architecture
Some things that simply emerge, may turn out to be very ugly creatures indeed
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 30
Intentional Architecture
For systems of scale, some intentional Architecture is necessary
Excessive redesign and refactoring of big systems drives bad economics and slows time-to-market – Drives rework for large numbers of teams – Potential impact on deployed systems/users
– Some use cases can and should be anticipated
Plus: Many drivers for system and enterprise architectures arise outside the purview of individual agile programs – Mergers and acquisitions – New, cross-cutting user patterns
– Common architectural constructs for usability, extensibility, performance and maintenance
8/15/12
16
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 31
Change, Challenge and Opportunity Drive Architecture Epics Large technology initiatives, that cut across:
– Time – affecting multiple releases
– Scope – affecting multiple products, systems, services, or solutions
– Organizations – affecting multiple teams, programs, business units
Where do they come from? – New product or service opportunities. – Mergers/acquisitions – Changes in technologies – Problems within the existing solution set, cost. – Architectural governance: usability, extensibility,
performance, etc. – Common infrastructure;
avoid duplication of effort
• UI framework for porting existing apps to mobile devices
• Industry security standard to lower data purchasing costs
• Support 64 bit back office servers
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 32
Intentional Architecture
V0.81
8/15/12
17
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 33
Principle # 1 ─ The teams that code the system design the system
Principle # 2 ─ Build the simplest architecture that can possibly work
Principle # 3 ─ When in doubt, code it (or model it) out Principle # 4 ─ They build it, they test it Principle # 5 ─ The bigger the system, the longer the
runway Principle # 6 ─ System architecture is a role
collaboration Principle # 7 ─ There is no monopoly on innovation Principle # 8 ─ Implement architectural flow
Principles of Agile Architecture
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 34
# 8−Implement Architectural Flow
Provide an agile framework for system architects. They must be agile, too.
Drive incrementalism in architectural refactoring
Make architectural work in process visible Establish WIP limits to control queue sizes,
avoid overload and assure product development flow
Drive an effective collaboration with the development teams
8/15/12
18
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 35
4. Implementa,on Ownership transi8ons Teams begin implemen8ng at
release planning boundaries Teams break epics into
features Architect support on “pull”
basis
Problem/Solu8on Needs Iden8fica8on
Evalua8on Architecture Team Ownership
Implementa8on Development Team Ownership
Agile Release Trains
WIP Limit
Release planning boundary
Innova,on feedback
Ac8vi8es: Effort size es8mate Value size es8mate Investment theme
alignment
Authority approves epic Meets
threshold criteria
Architect Team Pulls Epic Lead architect
assigned
Product/ Technology Council Approval
1. Funnel Technology roadmap Disrup8ve technology Solu8on problem: compa8bility
speed, size, security, usability, Common infrastructure/duplicate
investment
2. Backlog Refine
understanding Est. cost of delay Refine effort est. Rela8ve ranking
3.Analysis Design alterna8ves Modeling Development
collabora8on Solu8on/product management
collabora8on Business case
WIP Limit
PSI 1 PSI 2 PSI 3 PSI 4
WIP Limit
PSI 1 PSI 2 PSI 3 PSI 4
WIP Limit
System Architect Design
Spike
Tech lead/
architect
Architectural Epic Kanban System
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 36
#4−Scaling Portfolio Management Addressing legacy mindsets
Portfolio Vision
8/15/12
19
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 37
“widget engineering” “order taker mentality”
Epic based portfolio planning
Intense development collaboration
“Maximize utilization” “Get it done”
Time boxing WIP Limits
Fix resources short term only
“Control through milestones/data”
“plan out a full year of projects”
Control through empirical release
increments Rolling wave release
planning
From:
To:
Baker and Thomas, Establishing an Agile Portfolio to Align IT Investments with Business Needs. DTE Energy Case Study, Agile, 2009
Changing Legacy Mindsets:
The Problem with Legacy Mindsets
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 38
Eight Transformational Patterns
Legacy Mindset Lean-Agile Pattern #1 Too Many Projects Limiting WIP with Kanban #2 Detailed Project Plans Lightweight Business Cases #3 Annual Funding Incremental Funding #4 Centralized Annual
Planning Decentralized Rolling-Wave Planning
#5 Work Breakdown Structure
Agile Estimating and Planning
#6 Projects Agile Release Trains #7 PMBOK Agile Project Management #8 Waterfall Milestones Fact-Based Governance
We need a transformation “roadmap”, one that builds an Agile PPMO on Lean-Agile Principles
Legacy PPMO Agile PPMO
8/15/12
20
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 39
A Portfolio Kanban System
4. Implementation Ownership transitions Teams begin implementing at
release planning boundaries Teams break epics into features Analyst support on “pull” basis
Agile Release Trains
WIP Limit
Release planning boundary
Innovation feedback
Activities: Effort size estimate Value size estimate Investment theme
alignment
Authority approves epic Meets
threshold criteria
Business analyst pulls Epic Lead analyst
assigned
Portfolio Management
Team/ Product Council
Approval
1. Funnel Product roadmap New business opportunity Cost savings Solution problem
2. Backlog Refine
understanding Est. cost of delay Refine effort est. Relative ranking
3.Analysis Solution alternatives Collaboration
- Solution management - Architects - Market/sales/business - Development
Weighted rank Business case
WIP Limit
PSI 1 PSI 2 PSI 3 PSI 4
WIP Limit
PSI 1 PSI 2 PSI 3 PSI 4
WIP Limit
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 40
The Agile PPMO
The Agile PPMO enables and fosters lean and agile practices for business results
• Limiting Work in Process
• Lightweight business cases
• Incremental funding • Decentralized rolling
wave planning
• Agile estimating and planning
• Agile Release Trains • Agile Project
Management
• Fact-based assessment
• Agile milestones
8/15/12
21
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 41
Investment Themes
Can be at the enterprise or business unit level Done as part of the budgeting process with a
lifespan of 6-12 months Governed by a Portfolio Management Team
Not managed as a backlog in priority order. Rather, investment themes are managed as a percentage of available resources.
Not “testable” – ROI is not measured at this level
Investment Themes represent the budget allocations within a portfolio to systems, products, applications, and
services
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 42
Program Level
Por\olio Level
Program
Agile Release Trains (con8nuous flow programs)
Waterfall programs
Architectural Runway
Portfolio Vision
Portf
olio B
acklo
g
Implementa,on Verifica,on
Design Requirements
Implementa,on Verifica,on
Design Requirements
Program
Por\olio Level
Investment Themes
Budgets
Managing Budgets and Investment Themes
8/15/12
22
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 43
#5−Scaling Leadership Your enterprise can be no leaner than your executives thinking
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 44
The Problem: Let’s Get Real Managers, directors, and executives are not
“chickens” in the enterprise. They are “pigs”. (And really big ones at that.) To be successful, our expectation must not
be that they: a) simply don’t interfere, or b) simply understand, or c) are even simply supportive
Instead, they must LEAD. After all, that’s what leaders do
Our job Inform, Educate, and Inspire them to their new Lean|Agile leadership mission
8/15/12
23
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 45
Lean Thinking Foundation
Product Development Flow
1. Take an economic view
2. Actively manage queues
3. Understand/exploit variability
4. Reduce batch size 5. Apply WIP Constraints 6. Flow with uncertainty
Cadence and Synchronization
7. Apply fast feedback 8. Decentralize control
Derived from: Toyota Production System (2004) Larman and Vodde (2009)
Reinertsen (2009)
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 46
Lean-thinking Manager-teachers
Management is trained in lean thinking - bases decisions on this long term philosophy
Management understands and teaches lean and agile behaviors
Management is trained in the practices and tools of continuous improvement
Source: Larman and Vodde, 2009
8/15/12
24
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 47
Inform – Make sure the agile working group executes an
effective communication plan Educate Management
– Suggested Readings • Principles of Product Development Flow. Reinertsen • Agile Software Requirements: Lean Requirements Practices for
Teams, Programs and the Enterprise. Leffingwell. • Lean Software Development: An Agile Toolkit. Poppendieck.
– Have them attend a lean leadership workshop you hold Inspire
– Expect and challenge them to lead, not follow
Your Job: Inform, Educate, Inspire
© 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 48
Book: Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley. 2011
SAFe Certification: Chicago. October 23-27, 2012. (see ScaledAgileAcademy.com)
Blog: ScalingSoftwareAgilityBlog.com Framework: ScaledAgileFramework.com Website: see DeanLeffingwell.com
Questions?