Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Scaling Software Agility: Advanced Practices for Large
Enterprises
Five Keys to Building the Lean|Agile Enterprise
By Dean Leffingwell
Agile 2011 Salt Lake City, Utah
August, 2011
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
© 2011 Leffingwell, LLC.
About Dean Leffingwell
2
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Five Keys to Building the Lean|Agile Enterprise ➵ Not Everything is a User Story:
Scalable Agile Requirements ➵ Think Agile Programs, Not Just Agile Teams:
The Agile Release Train and Program Kickstart ➵ Enterprise Systems Require Intentional
Architecture: Rearchitecting with Flow ➵ Portfolio Management Must be Agile Too:
Addressing Legacy Mindsets and the Agile PMO ➵ Your Enterprise Can Be No Leaner Than the
Executives Thinking: Lean Education and The Big Picture
3
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
#1 – NOT EVERYTHING IS A USER STORY
SCALABLE AGILE REQUIREMENTS
The Agile Team in The Enterprise
H
H H
H
There can be a large number of teams in the enterprise
“pods” of 5-10 teams building a feature, component, or subsystem is not unusual
Some product lines require 30-40-50 teams to build
However, the structure of each team is largely the same
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Their work is based on the user story
User Story
As a <role> I can <activity>
So that <business value>
“As a Gmail user, I can select and highlight a conversation for further action”
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Stories drive iterations
Story A Story B Story C Story D Story E Story F
Story …
Plan
Fixe
d R
esou
rces
Fixed Time (Iteration)
7
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story
Is one of
Backlog Item
Task 1 1..*
Stories are maintained in the teams backlog
There is only one backlog for the team
All work comes from the backlog
If isn't a user story (defect, etc) it still goes in the backlog
“If there isn’t a story in the backlog, it ain’t gonna happen”
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story
Is one of
Backlog Item
Task 1 1..*
Acceptance Test
Done when passes
1..*
1
A test and quality-centric approach
Teams perform unit testing and functional testing for every story
The details of the story go into the functional test, where they are the persistent representation of system behavior
Stories are temporal (not maintained after implementation)
Unit Test Functional Test
Consists of 1
1..* 1..*
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Scaling Challenges
Assume a program requires – 200 practitioners, (25 agile teams) to deliver a product – The enterprise delivers software every 90 days in five, two
week iterations. – Each team averages 15 stories per iteration. – Number of stories that must be elaborated and delivered to
achieve the release objective = 25*5*15= 1,875!
How is an enterprise supposed to reason about things? – What is this new product going to actually do for our users? – If we have 900 stories complete, 50% done, what do we
actually have working? How would we describe 900 things? – How will we plan a release than contains 1,875 things?
And, what if it took 500 people? 10
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
And further
And, even if I know 100 things that “as a <role> I can <activity> so that <business value>”, can do
what Features does the system offer to its user and what Benefits do they provide?
11
Feature Benefit Stars for conversations Highlight conversations of
special interests Colored label categorization Easy eye discrimination of
different types of stories (folder like metaphor)
Smart phone client application
Faster and more facile use for phone users – ease adoption
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
So we need an additional level of planning
Iteration Cycle
Drives
Feedback - Adjust
Product & Release Cycle
Release Vision
Release Planning Release Scope and Boundaries
12
Iteration Planning
Develop & Test Review &
Adapt
Features
Stories
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Which creates an iteration and release pattern
Stories
Release timebox
13
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Feature Realized by 0,1 1..*
Is one of
Backlog Item
Task 1 1..*
So we need to extend the information model
Features are another kind of Backlog Item
Introduce Gmail “Labels” as a “folder-like” conversation-organizing metaphor.
Or:
As a modestly skilled user, I can assign more than one colored label to a conversation so that I can see a conversation from multiple perspectives
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Feature Realized by
Is one of
Backlog Item
Task 1 1..*
Features also require testing
0,1 1..*
Acceptance Test
Done when passes
1..*
1 1
And maybe a new team …..
Features typically span many teams
Sometimes, a special team is dedicated for the purpose of testing system level features
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Feature
Realized by
0,1 1..*
Is one of
Backlog Item Non-functional Requirement
Constrained by
Task 1 1..*
Acceptance Test
Done when passes
1..*
1 1
1..*
0..*
System Qualities Test
Compliant when passes
0..* 0..*
Nonfunctional requirements (system qualities) also require testing
Often requires specialty skills and tools
May also be province of system team
1
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
At the enterprise portfolio level, even system features are too fine grained There may be dozens of concurrent programs Each delivering dozens of features to market How do portfolio managers and system
architects communicate the sweeping, larger scale initiatives that drive those programs?
We use the word “Epic” to describe this content type
17
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Epic Feature Realized by Realized by 0,1 1..* 0,1 1..*
Is one of
Backlog Item Non-functional Requirement
Constrained by
Task 1 1..*
Acceptance Test
Done when passes
1..*
1 1
1..*
0..*
System Qualities Test
Compliant when passes
0.. 0..*
Epics drive programs Epics are key value propositions that create competitive advantage
Epic may be implemented over long periods, even years
Epics may be user, or technology based
Big, abstract, high level, visionary
Arch User
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
One last question: Where do epics come from? Investment themes represent the budget
allocations that drive the portfolio – Agreed to investments in product lines or business units – Typically updated annually or twice annually
16% 18%
7%
22%
17%
13% 7%
Cloud Computing Business Unit Strategic Investment Themes
2HF11
Customer Relationship Management
Employee data backup
Social Intranet
E-Commerce
Back office storage
User authentication
Computing Resources
E Commerce Epics
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
#2 – THINK AGILE PROGRAMS: NOT JUST AGILE TEAMS
AGILE RELEASE TRAIN & AGILE PROGRAM KICKSTART
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
The challenge: lots and lots of teams
There are a lot of potentially agile teams (20-50-100-more) in the larger enterprise
They all require training but team by team by team training is sloooowwww and expen$$ive
Plus: – Teams must be aligned to a common mission – Scaling requires constant dependency management
amongst non-collocated teams – Scaling delivery requires coordinated planning and
synchronized development
Solution: launch Agile Release Trains Train, Plan and Execute.
21
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
The Agile Release Train
Organize teams along value delivery lines These teams train, plan and execute together Development cadence (common schedule) is
fixed across all teams Intermediate, integration milestones are
established Common release governance
– Release management team – Scrum of Scrums – Release Train Engineer
and Conductor
Common architectural governance 22
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Regular cadence of smaller, more frequent releases
Faster value delivery and faster feedback – 60-120 days
Less Work In Process
Predictable delivery – Date, theme, planned
feature set, quality
Scope is the variable – Release date and
quality are fixed
23
We have to figure out a way to deliver software so fast that our customers won’t have time to change their minds. ─Poppendiecks - Implementing Lean
Software Development
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Fix: Cost, quality, schedule
24
Variable: Scope
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Achieving cadence: Fix dates & quality, float features
Teams learn that dates MATTER Product owners learn that priorities MATTER Agile teams MEET their commitments Floating features provides the capacity reserve to meet deadlines
10/1/2010 11/1/2010 12/1/2010 1/1/2011 2/1/2011 3/1/2011
3/25/2011 9/24/2010
25
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Everybody must be on the train
26
What do we integrate here??
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Cadence alone is not enough
27
Time when you discover you are not
…....time spent thinking you are on track…….
The slowest component drags the train
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Synchronize to assure delivery
28
S H I P !
Regular, system wide integration provides higher fidelity tests and objective assessment
Synch events facilitate cross functional tradeoffs
Assured Potentially Shippable Increment
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Separate Development Concerns from Release Concerns
Release Release
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Cadence pacemaker: Release Planning
A full day or two for every release Collocation: most everyone attends in person Decentralized planning: the plan is owned by the teams Product/Solution Managers own feature priorities The team builds the plan from the vision Development team owns
planning and high-level estimates Architects work as intermediaries for
technical governance, interfaces, etc.
30
Global alignment. Local prioritization.
Lean Principle D7: There is more value created with overall alignment than local optimization. The Principles of Product Development Flow, Reinertsen 2009.
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
What is an agile program, really?
31
Plan
Commit
Execute Demo
Retro
Day 1 Day 10 Day 2-9
Team
One sprint (2 weeks)
Program: 5-10 teams
Plan
Commit
Demo
Retro
One PSI (10 weeks)
Execute
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
One week “All In” Agile program kickstart
When you’ve selected a domain for the train, go “All In” and “All at Once”
32
Training: Scrum for Teams
Release Planning
Scrum Master
Orientation
Product Owner
Orientation
Mon Tue Wed Thu Fri
Train everyone at the same time Same instructor, same method, same terminology Most cost effective
Align all teams to common release (PSI) objectives Continue training during planning
Orientation for specialty roles (defer formal role training for now) Tool training for teams
Tool training
GO. AGILE. NOW.
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
#3 – ENTERPRISE SYSTEMS REQUIRE INTENTIONAL ARCHITECTURE
REARCHITECTING WITH FLOW
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
The Challenge of Refactoring at Scale
Excessive refactoring of large-scale systems can drive crappy economics and slow time to market – Creates rework for large numbers of teams, most of whom would
otherwise NOT have to refactor
– Potential impact on deployed systems/users
Many drivers for system architecture arise from outside the domain, purview and visibility of the agile programs – Business drivers: M&A, etc.
– Common architectural constructs ease usability, extensibility, performance and maintenance
For systems of scale, some intentional architecture is necessary
34
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Principles of Agile system architecture
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
35
© 2011 Leffingwell, LLC.
System architecture is a role collaboration
Architectural - Inputs - Ideas
- Constraints
36
Architectural Evolution
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Architectural epics
Large, technology development initiatives, cutting across dimensions:
Time – affecting multiple releases of products, systems, services or solutions Scope – affecting multiple products, systems, services, or solutions Organization – affecting multiple teams, programs, business units
Examples – UI framework for porting existing apps to mobile devices – Common installer and licensing mechanism – Industry security standard to lower data purchasing costs – Support 64 bit back office servers
37
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Where do these monsters come from?
New product or service opportunities. Mergers/acquisitions.
Changes in technologies that affect multiple products and services
Problems within the existing solution set Architectural governance
– usability, extensibility, performance, and maintenance
Common infrastructure and avoidance of duplication of effort
Cost
38
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Motivation for an architectural epic kanban system Provide an agile framework for system
architects. They must be agile, too. Drive incrementalism in architectural refactoring Make architectural work in process (AWIP)
visible Establish AWIP limits to control queue sizes, limit
global WIP and help assure product development flow
Drive an effective collaboration with the development teams
39
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen4. Implementa5on
Ownership transi-ons Teams begin implemen-ng at
release planning boundaries Teams break epics into
features Architect support on “pull”
basis
Problem/Solu-on Needs Iden-fica-on
Evalua-on Architecture Team Ownership
Implementa-on Development Team Ownership
Agile Release Trains
WIP Limit
Release planning boundary
Innova5on feedback
Ac-vi-es: Effort size es-mate Value size es-mate Investment theme
alignment
Authority approves epic Meets
threshold criteria
Architect Team Pulls Epic Lead architect
assigned
Product/ Technology Council Approval
1. Funnel Technology roadmap Disrup-ve technology Solu-on problem: compa-bility
speed, size, security, usability, Common infrastructure/duplicate
investment
2. Backlog Refine
understanding Est. cost of delay Refine effort est. Rela-ve ranking
3.Analysis Design alterna-ves Modeling Development
collabora-on Solu-on/product management
collabora-on 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
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Splitting epics for implementation in the release train
41
Partition by subsystem, product or service
Major/Minor effort
System qualities Simple/Complex
Incremental functionality Variations in data
Build scaffolding first Break out a spike
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
# 4 PORTFOLIO MANAGEMENT MUST BE AGILE TOO
ADDRESSING LEGACY MINDSETS & THE AGILE PMO
© 2011 Leffingwell, LLC.
Changing legacy mindsets
43
Investment Funding
“widget engineering” “order taker mentality”
Epic based portfolio planning
Intense development collaboration
Change Management
“Maximize utilization”
“Get it done”
Fixed resources short term only
Team commitments Adjust priorities
quarterly
Governance and Oversight
“Control through milestones/data”
“plan out a full year of projects”
Control through empirical release
increments Rolling wave
release planning
From:
To:
DTE Energy Case Study, Agile 2009
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From “too many projects” to continuous content delivery
Getting anything done (new feature or epic) requires creation of a new project
Projects have significant overhead, planning, resourcing, execution, closure
Once started, projects take on a life of their own. They develop antibodies to change and closure.
Many small projects cause people to multiplex between projects – Each project switch takes 20% overhead – Working on three projects means people only deliver
value 40% of the time – While switching to agile, one company diagnosed the
failures of the first 5 teams first few iterations. Conclusion: No one worked on the project long enough to accomplish anything!
Project, portfolio mix: Size, risk, reward
Dedicated teams stop multiplexing – no one works on more than one team
Project overhead is replaced by standard iteration and release cadence
New initiatives appear as new content and are prioritized at each iteration/release boundary
Work in an iteration/release is fixed Team resources are adjusted only at
periodic release boundaries
Agile Release Train with content management
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From waterfall/WBS/PERT to Agile velocity estimating and planning
Traditional project estimates tasks at the lowest leaf
Requiring all leafs be identified before estimate is given
Forces Big Up Front Analysis and estimates based on false precision
Force fits later activities into a flawed WBS
Agile teams develop and monitor “velocity” (capacity) based on story points at iteration level
Story points can be normalized across teams Standardized estimating by analogous model can also
be applied at the level of Epics and Features Epic estimating can be used for gross, portfolio-level
planning Feature estimates can be used for release (product)
level planning Story points used for iteration planning
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From PMBOK to Agile project management
Work Breakdown Structure estimating
Gantt Charts scheduling
Critical Path analysis
Iteration planning
Actual velocity based estimating
Release planning and roadmap
Release/iteration review/ retrospective
2 pts
4 pts
2 pts
Reporting
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From Gantt to asynchronous Sprints to Agile Release Train
Issues: Irrelevant to agile teams Hard to maintain Always obsolete If a team isn’t on the plan, is it
a “bad” team or “bad” plan? Measure paper, not software
Issues: Most agile companies start here Little coordination amongst teams Non-harmonized schedules No visibility beyond the next
sprint Little or no system level visibility
Coordinates sprints Multi- sprint visibility and
commitment Teams work out
interdependencies on the fly Full system visibility Requires set-based development
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From milestone-based to fact-based governance
Teams report milestones with document -based reviews
Subjective, milestone reports do not correlate to actual project status
Teams “report to” project office (leader as conductor/boss)
Teams cannot proceed until and unless they pass milestones (start-wait-start-wait waste cycle)
Scheduling delays and overhead Process changes dictated by “those who know
best”
Milestones are iterations and incremental releases of working code
Status and quality are quantitative, not subjective
Project office “comes to teams” (enabling leadership model)
Teams default model is to proceed unless stopped by business case (no process driven delays/waste)
No scheduling delays and overhead Process changes applied and harvested from
team’s retrospectives
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From waterfall milestones to driving incremental delivery
If (you must have them) Then (they must drive incremental delivery) Else (you don’t need them)
Commit to Maintenance
Program Approved
1.1 - 1.n Potentially shippable Increments
2.1 - 2.n Incremental releases
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
From legacy mindsets to Agile PMO drives release planning, reviews, retrospectives Release planning is a routine, major enterprise “event” Requires: coordination, cooperation, logistics, facilitation,
planning, discipline, metrics Difficult for teams themselves to coordinate this across teams-of-
teams function. Resource adjustment (change management) happens at these
boundaries! – May be inappropriate for them to change their own resources
Question: who has the skills and discipline necessary to institutionalize this critical agile best practice?
Answer: PMO?
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Summary - The Agile PMO New Mission: Enable, Empower, Ensure
1. Leads value chain analysis 2. Educate project managers in lean and agile 3. Adopt agile estimating and portfolio planning 4. Implement Agile Release Train best practices 5. Implement common agile metrics: iteration, release &
process sets 6. Join Agile Project Management Leadership Network
PMO enables, fosters, and promotes agile practices
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
#5 – YOUR ENTERPRISE CAN BE NO LEANER THAN THE EXECUTIVES THINKING
LEAN EDUCATION & GIVE THEM THE BIG PICTURE
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
The Challenge: 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 be not 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
53
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Lean Thinking House
54
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)
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
The Goal: Sustainably deliver value fast
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
Focus on the baton, not the runners. -- Larman and Vodde
55
1) Focus on customer requirements as they move through the system, not the people and organizations who manage them
2) Minimize delays, handoffs and non-value added activities
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Managers are teachers, not directors
Mentor people closely for years, in engineering and problem solving
Teach people to analyze root causes and make problems visible; they discover how to improve
Employees see managers understand and act on the goal of eliminating waste and delays
Lean Pillar 1: Respect for people
56
Your customer is anyone who consumes your work or decisions
Relentlessly analyze and change to stop troubling them
Don't force people to do wasteful work Don't give them defects Don't make them wait Don't impose wishful thinking on them Don't overload them
Management challenges people to change and may ask what to improve, but ...
Workers learn problem solving skills and then decide how to improve
Form long-term relationships based on trust
Help partners improve and stay profitable
Source: Larman and Vodde, 2009
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Lean Pillar 2: Continuous improvement Respect your network of partners.
– Treat your partners as extensions of your business.
– Set challenging targets and assist your partners in achieving them.
– Challenge them to grow and develop.
Make decisions slowly by considering all data; implement decisions rapidly
Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen). – Once you have established a process, use continuous improvement
tools to determine the root cause of inefficiencies and apply effective countermeasures.
– Protect the organizational knowledge base by developing stable personnel, slow promotion, and careful succession systems.
– REFLECT (hansei) at key milestones and after you finish a project to identify shortcomings
57 Source: The Toyota Way, 2004
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Lean foundation: Lean-thinking manager-teachers Management is trained in lean thinking - bases decisions on
this long term philosophy Management is trained in the practices and tools of continuous
improvement Management leads, coaches and drive teams to continuously
improve
58
Kaizen Mind – your job, and the job of your employees, is to do the job AND improve your job. Endlessly.
Source: Larman and Vodde, 2009
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
IN THE HOUSE OF LEAN – PRINCIPLES OF PRODUCT DEVELOPMENT FLOW
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Principles of Product Development Flow
1. Take an economic view 2. Actively manage queues 3. Understand and exploit variability 4. Reduce batch sizes 5. Apply WIP constraints 6. Control flow under uncertainty - cadence and
synchronization 7. Get feedback as fast as possible 8. Decentralize control
60
Reinertsen, Principles of Product Development Flow, 2009.
Give them the Big Picture: Scaled Agile Delivery Model
H
H H
H
©2011 Leffingwell, LLC.
See Agile So8ware Requirements: Lean Requirements Prac>ces for Teams, Programs, and the Enterprise and www.scalingsoRwareagility.wordpress.com
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Inform, educate, inspire
Inform – Make sure the agile working group executes an
effective communication plan
Educate – Suggested Readings
– The Principles of Product Development Flow. Reinertsen – Scaling Software Agility, Best Practices for Large
Enterprises. Leffingwell. – Lean Software Development: An Agile Toolkit.
Poppendieck.
– Have them attend a leadership workshop that you hold
Inspire – Expect and challenge them to lead, not follow
© 2011, Leffingwell, LLC.
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
More from Dean Leffingwell
http://www.informit.com/store/product.aspx?isbn=0321635841)
63