© 2009-2010 leffingwell, llc. scaling software agility: best practices for large enterprises by...
TRANSCRIPT
© 2009-2010 Leffingwell, LLC.
Scaling Software Agility:Best Practices for Large
Enterprises
By Dean Leffingwell
September, 2010
(Rev 9 (9_10)
© 2009-2010 Leffingwell, LLC. (Rev 6)
About Dean Leffingwell
2
AuthorExecutive
Founder/CEO Requisite, Inc.
Makers of RequisitePro
Senior VPRational Software
Responsible for Rational Unified Process (RUP) &
Support of UML
Founder and CEOProQuo, Inc., Internet identity
Agile Executive MentorBMC, John Deere and others
Agile Enterprise CoachContinuing…medium size,
large and very large software enterprises...
Coach
Cofounder/AdvisorPing Identity, Roving Planet,
Rally Software
© 2009-2010 Leffingwell, LLC.
More from Dean Leffingwell
Books
– Coming Soon: Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise
– Scaling Software Agility: Best Practices for Large Enterprises
Blog and Resources
– www.scalingsoftwareagility.wordpress.com
Reach me at [email protected]
3
© 2009-2010 Leffingwell, LLC. Copyright 2007 Dean Leffingwell
Approaching Agile at Scale
.We place the highest value on actual implementation and
taking action.
There are many things one doesn’t understand; therefore, we ask them, why don’t you just go ahead and take action?
You realize how little you know, and you face your own failures and redo it again, and at the second trial you realize
another mistake . . . So you can redo it once again.
So by constant improvement one can rise to the higher level of practice and knowledge.
This guidance reminds us that there is no problem too large to be solved if we are only willing to take the first step
-- Fuijo Sho, Chairman, Toyota
© 2009-2010 Leffingwell, LLC.
If you accept the premise that market needs change faster than the software industry’s traditional ability to develop solutions, you’re left with the question “what can we do about it?” For me, the answer is Agile.
--Israel Gat, Vice President,Infrastructure Management, BMC Software, Inc.
5
© 2009-2010 Leffingwell, LLC.
BMC Results
QSM Associates press release … remarkable levels of time-to-market and quality … produce large scale enterprise software in 4-5 months,
compared to typical one year … exceptional time-to-market without sacrificing quality … especially noteworthy - BMC 'Secret Sauce‘ enables
process to succeed in spite of geographically dispersed teams– “Other companies experience higher defects and longer
schedules with split teams, BMC does not. I've never seen this before. The low bug rates also result in very low defect rates post-production”
… clearly ahead of more than 95 percent of all the software projects captured in the SLIM metrics database, they're among the best I've seen
Source: QSM Associates Press Release, Sep 10, 2007
6
© 2009-2010 Leffingwell, LLC.
What is Software Agility?
1. A disciplined project management process that encourages frequent inspection and adaptation and continuous strategic improvement
2. A leadership philosophy that encourages teamwork, self-organization and accountability
3. A set of software engineering best practices that promotes rapid delivery of high-quality software
4. A business approach that aligns IT with customer needs and company goals
7Source: wikipedia
© 2009-2010 Leffingwell, LLC.
Before: Predictive Process Approach
1970 1980 1990 2000
Predictive Processes
Waterfall
Predictive, plan-based Process
Plan – measure – re-plan - repeatPr
oces
s
Inpu
ts
Out
puts
8
© 2009-2010 Leffingwell, LLC.
Predictive vs. Empirical Process
If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach
(measure and adapt) is the method of choice. - Ken Schwaber
Empirical (Adaptive) Process
Proc
ess
Controls
Inpu
ts
Out
puts
Plan – measure – re-plan - repeat
9
© 2009-2010 Leffingwell, LLC.
Agile Process Movement
IterativeProcesses
Spiral RAD RUP…
Often confused with waterfall Continued to be artifact heavy
A stepping stone to agile…
1970 1980 1990 2000
Predictive Processes
Waterfall
10© 2007 Trail Ridge Consulting, LLC
© 2009-2010 Leffingwell, LLC.
Agile Process Movement
IterativeProcesses
Spiral RAD RUP…
Agile (Adaptive) Processes
Scrum, XP, Lean, Open UP, FDD, Crystal…
1970 1980 1990 2000
Predictive Processes
11Adapted from Trail Ridge Consulting, LLC
2010
Enterprise Agility
Yahoo, Google, BTI, BMC, Nokia, DTE Energy, Cisco, Citrix, HP, JP Morgan, AOL Boeing, Comcast, PayPal, EDS, Emerson, Fidelity…
© 2009-2010 Leffingwell, LLC.
Agile Methods
Adaptive Software Development (Highsmith)
Crystal Methods (Cockburn)
Dynamic System Development Method (Faulkner et al)
Feature Driven Development (Coad & DeLuca)
Lean Software Development (Poppendiecks)
SCRUM (Schwaber, Beebe, Sutherland)
Extreme Programming (XP) (Beck, Gamma)
Iterative/Agile – RUP and Open Unified Process (Jacobson, Kruchten, Royce, Kroll)
12
© 2009-2010 Leffingwell, LLC.
Agile Principles—The Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more”
13
http://www.agilemanifesto.org
© 2009-2010 Leffingwell, LLC.
Agile Manifesto Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
Working software is the primary measure of progress
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Business people and developers must work together daily throughout the project
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
14
http://agilemanifesto.org/principles.html
© 2009-2010 Leffingwell, LLC.
Principles (continued)
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
15
© 2009-2010 Leffingwell, LLC.
Agile Turns Tradition Upside-Down
PlanDriven
Requirements Cost ScheduleConstraints
Cost Schedule FeaturesEstimates
Value/VisionDriven
Predictive Process(Waterfall)
Adaptive Process(Agile)
The plan createscost/schedule estimates
The vision createsfeature estimates
16
© 2009-2010 Leffingwell, LLC.
Helps Avoid the Death March
Agile
Waterfall
Time
Pre
ssu
re
Deadline
17
Peak performance achieved and maintained indefinitely at a sustainable pace
© 2009-2010 Leffingwell, LLC.
Reduces Risk
Time
Deadline
Ris
k
Agile
Waterfall
18
© 2009-2010 Leffingwell, LLC.
Starts Delivering Immediately
Time
Deadline
Va
lue
De
live
ry
Agile Waterfall
19
© 2009-2010 Leffingwell, LLC.
Makes Money Faster
Time
Deadline
Va
lue
De
live
ry
20
Market value of a feature over
time
Cumulative gross margins
© 2009-2010 Leffingwell, LLC.
Project Multiplexing
Your team has three projects. Each will take the entire team one month and delivers value of one unit.
Plot value delivery curves over time of doing the projects in Scenario A Serially and Scenario B parallel (simultaneously)
(Assume 20% task switching overhead for each team member in Scenario B)
What is the efficiency of the team in Scenario A vs. B?
Project A Project B Project C
Scenario A – Serial Delivery
Scenario B – Parallel
Time
Project A
Project B
Project C
Time
© 2009-2010 Leffingwell, LLC.
Delivers Better Fit for Purpose
Time
What the customer would, in the end,
like to have
What the customer thought they
wantedwaterfall plan, result
agile(adaptive) plan, result
Measure ofwaterfall customerdissatisfaction
22
© 2009-2010 Leffingwell, LLC.
Achieving Team Agility
1. The Define/Build/Test Team
2. Mastering the Iteration
3. Two-levels of Planning and Tracking
4. Smaller, More Frequent Releases
5. Concurrent Testing
6. Continuous Integration
7. Regular Reflection and Adaptation
Seven Agile Team Practices that Scale
23
© 2009-2010 Leffingwell, LLC.
Seven Agile Team Practices That Scale
The Define/Build/Test Team
Mastering the Iteration
Two-level Planning and Tracking
Smaller, More frequent releases
Concurrent Testing
Continuous Integration
Regular Reflection and Adaptation
24
© 2009-2010 Leffingwell, LLC.
1. Define/Build/Test Team
Optimized for vertical communication
Friction across the silos
Location via function
Political boundaries between functions
Pro
du
ct M
gt
Arc
hit
ectu
re
Dev
elo
pm
ent
Test
an
d Q
A
Before Agile: Typical Functional Silos
Management Challenge: Connect the Silos
25
© 2009-2010 Leffingwell, LLC.
A self-organizing team that can Define, Build and Test a thing of interest
Optimized for communication about the thing Repeated at larger scales to produce larger
systems Teams can be based on
– Features
– Products
– Components
– Subsystems
– Interfaces
D/B/T Team – Agile Fractal
Team 1
Team 100
26
© 2009-2010 Leffingwell, LLC.
D/B/T Teams Have the Necessary Skills
8-10 Team members maximum
Developer Developer Developer Tester
TesterDeveloperProduct Owner
Tech
nic
al
Inte
rfac
eArchitect
Tech lead Scrum / Agile Master
Team
of
Team
In
terf
ace
QA/Release Mgt
27
© 2009-2010 Leffingwell, LLC.
The iteration is the heartbeat of agility. Master that, and most other things agile tend to
naturally fall into place.
2. Mastering the Iteration
28
© 2009-2010 Leffingwell, LLC.
Iteration Pattern
Story AStory BStory CStory DStory EStory F
Story …
Iteration backlog
Define
Develop
Accept
Iteration Objective
Pla
n
Review
Fix
ed
Res
ourc
es
Fixed Time (Iteration)
Story A Story B
Story C
29
© 2009-2010 Leffingwell, LLC.
3. Two-Level Planning and Tracking
Iteration Cycle
Release Cycle
Drives
Feedback - Adjust
Plan Releases at the System Level– Three to six months
horizon
– Prioritized feature sets define content
Plan iterations at the component/feature level– 2-4 iteration visibility
– Currency: user stories
ReleaseVision
Release PlanningRelease Scopeand Boundaries
30
Iteration Planning
Develop & TestReview &
Adapt
© 2009-2010 Leffingwell, LLC.
Release Pattern
Prioritized Release (feature)
Backlog
– Feature 1– Feature 2– Feature 3– Feature 4
Feature 1
Feature 2
Feature 3
PlanStories
Release timebox
Release theme and objectives
Review
31
© 2009-2010 Leffingwell, LLC.
4. Regular Cadence - 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
BEFORE
Release Time Frame
Cycle Cycle Cycle
AFTER
Cycle Cycle Cycle Cycle Cycle Cycle
Release Time Frame
32
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
© 2009-2010 Leffingwell, LLC.
Achieving Cadence: Fix Dates & Quality - Float the 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
PSI 1 PSI 2 PSI 3
10/1/2010 11/1/2010 12/1/2010 1/1/2010 2/1/2010 3/1/2010
3/25/20109/24/2010
33
“
© 2009-2010 Leffingwell, LLC.
5. Concurrent Testing
All code is tested code. Teams get no credit for delivering functionality that is coded, but not tested.
Tests are written before, or concurrently with, the code itself.
Testing is a team effort. Testers and developers all write tests.
Test automation is the rule, not the exception.
Philosophy of Agile Testing
34
© 2009-2010 Leffingwell, LLC.
Concurrent
Unit Testing
– Developer written
Acceptance Testing
– Customer, product owner, tester written
Component Testing
– Integrated BVT (build verification tests) at component/module level
System, Performance and Reliability Testing
– Systems tester and developer Written
– QA Involvement
35
© 2009-2010 Leffingwell, LLC.
Agile Testing Quadrants
36
Business-Facing
Su
pp
ort
Dev
elo
pm
ent C
ritiqu
e Pro
du
ct
Technology-Facing
Functional TestsStory
acceptance tests
Exploratory TestingUsability TestingScenario Testing
User Acceptance Testing
Unit TestsComponent Tests
System QualitiesPerformance and LoadSecurity“ility” (NFR) Testing
ManualAutomated & Manual
Automated Tools
Q1
Q2 Q3
Q4
Adapted from Brian Marick, and Agile Testing by Crispen and Gregory 2009
© 2009-2010 Leffingwell, LLC.
On Test Automation
You have no choice Manual tests bottleneck velocity You can’t ship what you can’t test
Automate Now
37
© 2009-2010 Leffingwell, LLC.
6. Continuous Integration
Continuous integration is neither new nor invented by agile
It has been applied as a best practice for at least a decade
However, continuous integration is mandatory with agile
the teams ability to build continuously is a critical bottleneck to delivered
velocity
38
© 2009-2010 Leffingwell, LLC.
Continuous Integration Success
Team can build at least once a day– Effort is inversely proportional to time between builds!
– A broken build “stops” production and is addressed immediately
Successful builds– Checks in all the latest source code
– Recompile every file from scratch
– Successfully execute all unit tests
– Link and deploy for execution
– Successfully execute automated Build Verification Test
39
Source: Martin Fowler
© 2009-2010 Leffingwell, LLC.
Memo from an XP Shop
40
“The XP environment provides us with many benefits, not the least of which is the incredible pace of progress we are so proud of. Lately we have had a rash of build failures, some related to infrastructure issues, but more related to carelessness. Broken builds destroy the “heartbeat” of an XP team. Each of you has a primary responsibility to ensure that this doesn’t happen . . . but here are a few tips to ensure that you aren’t the one who broke the build:
– Write your test cases before you write the code
– Build and test the code on your desktop BEFORE you check it in
– Make sure you run all of the cases that the build does
– Do not comment-out inconveniently failing unit tests. Find out why they are broken, and either fix the test or fix your code
– If you are changing code that may affect another team, ASK before you check it in
– Do not leave the building until you are SURE your last check-in built successfully and the unit tests all ran
The Build master is there to make sure that broken builds get addressed, not to address them. The responsibility for a broken build is yours. Breaking the build will have an affect on your standing within the team and, potentially, your review, so let’s be careful out there.”
© 2009-2010 Leffingwell, LLC.
7. Regular Reflection and Adaptation
Periodically, the entire team including owners/end users– reflects on the results of the process
– learn from that examination
– adapt the process - and organization - to produce better results
The team decides what is working well, what isn’t, and what one thing to do differently next time
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Manifesto, Principle 12
The shorter the iterations and releases ‒ the faster the learning
41
© 2009-2010 Leffingwell, LLC.
Enterprise Agility
That harness large numbers of agile teams to build and release quality enterprise-class software more rapidly than ever before
Explicitly driven by intimate and immediate customer feedback
A set of – organizational best practices– core values and beliefs
42
© 2009-2010 Leffingwell, LLC.
Achieving Enterprise Agility
1. Intentional Architecture
2. Lean Requirements at Scale
3. Systems of Systems and the Agile Release Train
4. Managing Highly Distributed Development
5. Impact on Customers and Operations
6. Changing the Organization
7. Measuring Business Performance
Seven Enterprise Practices
43
© 2009-2010 Leffingwell, LLC.
1. Intentional Architecture
Continuous refactoring of large-scale, system-level architectures is problematic:– Substantive rework for large numbers of teams
– Some of whom would otherwise NOT have to refactor their component or module
– Potential Impact on deployed systems/ users
– Best possible BVT (Build Verification Tests) are imperfect
– Common architectural constructs ease usability, extensibility, performance and maintenance
For systems of scale, some “intentional architecture”
is necessary44
© 2009-2010 Leffingwell, LLC.
Principles of Agile Architecture
Principle #1 The teams that code the system design thesystem.
Principle #2 Build the simplest architecture that canpossibly work.
Principle #3 When in doubt, code (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
45
© 2009-2010 Leffingwell, LLC.
System Architecture is a Role Collaboration
Value Stories+ Arch. Spikes
Agile Team
Customers
System/ Portfolio Team
SystemArchitect
Design Spike Tech lead/
architect
ProductManager
ProductOwner
Scrum/Agile
Master
Project Stakeholders
ProductVision
Architectural- Inputs- Ideas
- Constraints
46
Architectural Evolution
© 2009-2010 Leffingwell, LLC.
2. Lean Requirements at Scale
Requirements still matter in agile. At scale, lean and more extensible
requirements practices can be applied.
47
© 2009-2010 Leffingwell, LLC.
Lean Requirements at Scale
A scalable requirements practice with three elements
Vision+ Roadmap Just-in-Time Elaboration
Story 1
Story 2
Story 3
|1 |3|2 |4
48
© 2009-2010 Leffingwell, LLC.
Vision - Management’s responsibility
Where are we headed as a business?
What problem does this product solve?
What features and benefits does it provide?
For whom does it provide it?
What performance does it deliver?
49
© 2009-2010 Leffingwell, LLC.
Common and Non-functional Requirements
Some requirements must be known by all teams
– Common components, common behaviors
– Internationalization, accessibility
– Performance, reliability and security requirements
– Industry/Regulatory/Customer standards/specifications
– Corporate standards: copyright, logo, graphics, legal
Common Requirements
Documented and available to all affected teams.
50
Non-functional (Quality) Requirements
© 2009-2010 Leffingwell, LLC.
Roadmap – System Team’s Responsibility
May 15, 10 May 22, ’10 July ‘10
Features Road Rage Completed (single user) Brickyard Ported (single
user) Road Rage multiuser
demonstrable First multiuser game
feature for Road Rage New features (see
prioritized list) Beemer game in Alpha
Features Multiuser Road Rage
first release Brickyard Ported
multiuser demo New features for both
games (see prioritized list)
Beemer game to E3 Tradeshow?
Features Road Rage Ported
(part I) Brickyard port started
(stretch goal to complete)
Distributed platform demo
ALL GUIs for both games demonstrable
New features (see prioritized list)
Demo of Beemer game
First two games available (Road Rage and Brickyard)
First distributed game (Road Rage)
Game 1 Demo - Proof of viability on new platform
IR1 IR2 IR3
51
© 2009-2010 Leffingwell, LLC.
FEATURE
Story 1Omnis decus
Plurubus unum
Story 2
Agile investment in documenting requirements is minimal prior to implementation– Features are high level, abstract
– Communicate only concept
– Little “work in process”
At iteration boundaries, elaboration is required – Refine the team’s understanding
– Support design, implementation and testing
– Define acceptance criteria
User Stories are the currency
Just-In-Time Elaboration – Agile Team’s Responsibility
52
© 2009-2010 Leffingwell, LLC.
Implemented byStoryEpic Feature
Realized by Realized by
0,1 1..* 0,1 1..*
Is one of
Backlog ItemNonfunctionalRequirement0.. 0..*
Constrained by
Investment Themes 0, 1 1..*
Realized byTask
1 1..*
Acceptance Test
Done when passes
1..*
1..*
0..*
System Qualities Test
Compliant when passes
User Story
Other Work Item
1..*
Is one of
1..*
A Lean, Enterprise-Scale Requirements Model
version
*
© 2009-2010 Leffingwell, LLC.
3. Systems of Systems and the Agile Release Train
Align all teams to the enterprise mission Scaling agile requires managing interdependencies
amongst distributed agile teams Teams themselves must understand and manage their
dependencies Requires coordinated planning and synchronized
development activities This is facilitated by an “agile release train” delivery
model
Rolling-wave Enterprise Release Planning drives release train vision and execution
54
© 2009-2010 Leffingwell, LLC.
Principles of the Agile Release Train
Release dates for the solution are fixed
Intermediate, global integration milestones are established and enforced
Therefore, component functionality must flex
Teams evolve to a flexible model:
– Design spectrum for new functionality
– Backup plan to ship existing assets if necessary
55
Lease Imaginable
Minimum Credible
Moderate Best
“Time pressures will drive extreme use of simultaneous engineering”
-- The New, New Product Development GameHarvard Business Review, 1986
© 2009-2010 Leffingwell, LLC.
Everybody Must Be on the 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
System test and bug fix
Test drop 2
Ports, certs
Actual releaseAgile works better
PSI
Iterate Iterate Iterate
Release docs
Harden
Ports, certs
Iterate Iterate Iterate Harden
56
Waterscrumming doesn’t work
What do we integrate here?
© 2009-2010 Leffingwell, LLC.
But Cadence Alone is not Enough
57
Time when you discover you are not
Planned system release date
…....time spent thinking you are on track…….
Integrate and slip!
System
External Release
External Release
External Release
Internal Release
Internal Release
Iterate Iterate Iterate Harden Iterate Iterate Iterate Harden
Iterate Iterate Harden Iterate Iterate Harden
A
B
C
Modules
Internal Release
Iterate Iterate Iterate Harden Iterate Iterate Iterate Harden
The slowest component drags the whole train
Release docs
Port and certs
Port and certs
Release docs
Release docs
© 2009-2010 Leffingwell, LLC.
Synchronize to Assure Delivery
58
First PSI Second PSI or Release
Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 Sys 7 Sys 8
Iterate Iterate Iterate Harden Iterate Iterate Iterate Harden
Iterate Iterate Iterate Harden Iterate Iterate Iterate Harden
Iterate Iterate Iterate Harden Iterate Iterate Iterate Harden
Team A
Team B
Team C
Modules
System Iterations
External Release
External Release
External Release
Release docs
Ports certs
Release Docs
Release Docs
Ports certs
Ports certs
Internal Release
Internal Release
Internal Release
Continuous Integration
Continuous Integration
Continuous Integration
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
© 2009-2010 Leffingwell, LLC.
Business Context
Product Vision
Team Breakouts
Draft Release Plan Review
Problem Solving / Scope
Management
9-10
10-11
11-12
12-1
1-2
2-3
3-4
4-6
Eng mgrs
State of the business Objectives for upcoming periods
Objectives for release Prioritized feature set
Each team presents plans to group Issues/impediments noted
Issues/impediments assigned Release commitment vote?
Teams plan stories for iterations Work out dependencies Architects and PMs, POs circulate
|1
|1
|2
|2
|3
|3
|4
|4
architects
Product managers/ Product Owners
PMs
Executives
Rolling Wave Release Planning Drives the Train
59
© 2009-2010 Leffingwell, LLC.
Rolling Wave Release Planning Day 2
9-10
10-11
11-12
12-1
1-2
2-3
Objectives for release Prioritized feature set
All Issues/impediments assigned Release commitment vote
What did we learn? Update Product Roadmap
60
Revise Objectives?
Plan/Re-plan as necessary
Final Plan Review
Commitment
Dev teams
Eng mgrs
Eng mgrs/PMs
Product Managers
|1
|1
|2
|2
|3
|3
|4
|4
© 2009-2010 Leffingwell, LLC.
Release Commitment
61
© 2009-2010 Leffingwell, LLC.
4. Managing Highly Distributed Development
Co-locate team often – at least at Release Planning Establish core hours, with overlap required Apply high cohesion and low coupling to sites (organize
and reorganize around features/components) Don’t let anyone go dark - apply daily Integration Scrums Establish a single global instance of project assets Invest in tools that support distributed, but shared view of
status
62
© 2009-2010 Leffingwell, LLC.
5. Changing the Organization
Transition as a Project “All in” or Incremental Rollout Eliminating Impediments Moving to Agile Portfolio Management
63
© 2009-2010 Leffingwell, LLC.
Establish an Agile Enterprise Transition Team– Drives the enterprise vision and facilitates
implementation
– Cross-functional involvement
– Cross-level involvement
– Executive leadership
Create a transition backlog Run project in iterations
– Commit to weekly iteration goals
– Meet at least weekly
– Report to other executive stakeholders
– Experience agile project management
Transition as a Project
64
− Executive sponsors
− Cross functional
© 2009-2010 Leffingwell, LLC.
All-In or Incremental?
Advantages Disadvantages
Minimizes adoption risk More modest training resources Develop successful organizational
patterns Develop internal mentors
Failure is an option Dual software processes Continuously re-factoring process
guidance Delayed enterprise benefits
Advantages Disadvantages
Failure not an option All hands on deck Unified software practices Enterprise benefits achieved most
quickly
Enterprise disruption Risk of larger scale failure Risk of organizational buy-in Training and education resource
demands
All-in
Incremental
65
© 2009-2010 Leffingwell, LLC.
Eliminating Impediments
Existing rules demand adherence to document-driven, waterfall processes and artifacts
Software test/ system test not integrated, responsive
Inadequate build and support infrastructure
Organization rewards individual over team behavior
Teams not co-located to maximum extent feasible
Teams not truly empowered
Other functions - sales, marketing, customer not supportive of increased delivery pace
Legacy thinking - Management expectations for fixed-price, fixed-time, fixed-function delivery
66
© 2009-2010 Leffingwell, LLC.
Moving to Agile Portfolio Management
67
Changing Legacy Mindsets
From:
To:
DTE Energy Case Study, Agile 2009
© 2009-2010 Leffingwell, LLC.
6. Impact on Customers and Operations
More frequent releases challenge:– Customers
– Suppliers
– Marketing and Sales
– Support
– Documentation, certification, localization
68
© 2009-2010 Leffingwell, LLC.
Solution: Separation of Concerns
Version 1.0Analyst toursCustomer shipComprehensive U
General Availability Version 2.0Analyst toursCustomer shipComprehensive U
Marketing Controlled Announcement Window
Release to Market Processes
Asynchronous Collaborative
Development release (internal release) train 8/20/2010
7/1/20104/1/20101/1/201010/1/20107/1/2010
6/10/2010
Customer upgrade Possible
New productIR 5IR 4IR 3IR 2IR1
Docs and certsCustomer preview Docs and certs
General Availability Firewall
© 2009-2010 Leffingwell, LLC.
7. Measuring Business Performance
70
The primary metric for agile is whether or not working software actually exists, and is
demonstrably suitable for its intended purpose.
This is determined empirically, by demonstration, at the end of every single iteration.
All other measures are secondary ….. (but not useless)
© 2009-2010 Leffingwell, LLC.
Release theme established and communicated
Release planning meeting attended and effective
Release backlog defined
Release backlog ranked by priority
Release backlog estimated at plan level
The team has small and frequent releases
The team has a common language and metaphor to describe the release
Release progress tracked by feature acceptance
Team completes and product owner accepts the release by the release date
Release review meeting attended and effective
Team inspects and adapts (continuous improvement) the release plan
Team meets its commitments to release
Total Release Planning and Tracking Score
Process Self-Assessment Metrics
Software Agility Team Self-AssessmentScore(0-5)
Comments
Backlog prioritized and ranked by business value
Backlog estimated at gross level
Product owner defines acceptance criteria for stories
Product owner and stakeholders participate at iteration andrelease planning
Product owner and stakeholders participate at iteration and release review
Product owner collaboration with team is continuous
Stories sufficiently elaborated prior to planning meetings
Total Product Ownership Score
All testing is done within the iteration and does not lag behind
Iteration defects are fixed within that iteration
Unit tests are written before development
Acceptance tests are written before development
100% automated unit test coverage
Automated acceptance tests
Total “Testing” Practices Score
Iteration progress tracked by task to do (burn-down chart) and card acceptance (velocity)
Work is not added by the product owner during the iteration
Team completes and product owner accepts the iteration
Iterations are of a consistent fixed length
Iterations are no more than 4 weeks in length
Iteration review meeting attended and effective
Team inspects and adapts (continuous improvement) the iteration plan
Total Iteration Planning and Tracking Score
71
© 2009-2010 Leffingwell, LLC.
Team Agility Assessment Radar Chart
Product Ownership
Development Practices/Infrastructure
Release Planning and Tracking
Testing Practices Iteration Planning and Tracking
Team
150%
125%
100%
75%
50%
25%
0%
72
© 2009-2010 Leffingwell, LLC.
Watch for these Anti-patterns…
Insufficient refactoring of testing organizations and inadequate test automation
Lack of team proficiency in agile technical practices– iterations and sprints treated as demo milestones, rather than
potentially shippable increments
Insufficient depth/competency in the critical product owner role
Inadequate coordination of vision and delivery strategies– due to lack of coordinated, multi-level release planning
73
© 2009-2010 Leffingwell, LLC.
Summary
1. The Define/Build/Test Team
2. Mastering the Iteration
3. Two-level Planning and Tracking
4. Smaller, More Frequent Releases
5. Concurrent Testing
6. Continuous Integration
7. Regular Reflection and Adaptation
Agile Teams
1. Intentional Architecture
2. Lean Requirements at Scale
3. Systems of Systems and the Agile Release Train
4. Managing Highly Distributed Development
5. Changing the Organization
6. Impact on Customers and Operations
7. Measuring Business Performance
Agile Enterprise
74
Team
Portf
olio
Prog
ram
Re
lea
se
(o
r P
SI)
Developers & Testers
Tea
m B
ac
klo
g
Stories fit in iterations
(Implemented by) Tasks
Features fit in
releases
Epics span
releases
Iterations Iterations
Release theme and objectives
Architectureevolves
continuously
Spikes are research, design, refactor Stories
Systems, applications, products
The Big Picture
Agile Teams(3-10 typical per “pod”)
Architectural Runway
Epic 3
Epic 4
Portfolio Vision
H
HH
H
Stories
Features and components
Scrum/Agile
Master
Rel
ea
se P
lan
nin
g
Rel
ea
se P
lan
nin
g
Pla
n
Dem
o
Feature 3
Feature 4
System Team
Release Planning
Feature 2
Feature 1
Epic 1
Epic 2
Pla
n
Dem
o
Nonfunctional
requirements (
NFRs
Stories
Investment Themes
RoadmapVision
Arch 1
©2010 Leffingwell, LLC.
Re
lea
se
(o
r P
SI)
Po
rtfo
lio
Bac
klo
g
Pro
gra
m
Bac
klo
g
Product Owner
NFRsTea
m B
ac
klo
gTe
am
Ba
ckl
og
Source: Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise.
Copyright 2010, Leffingwell, LLC.See www.scalingsoftwareagility.wordpress.com
© 2009-2010 Leffingwell, LLC.
Suggested Readings
Scaling Software Agility: Best Practices for Large Enterprises. Leffingwell, Dean. Addison-Wesley. 2007.
Scaling Lean and Agile Development: Thinking and Organizational tools for Large-Scale Scrum. Larman, Craig and Bas Vodde. Addison-Wesley. 2009.
76