Agile Portfolio Based Release Trains We all know that Agile works great for small dedicated projects. However, only a small part of projects do fit that profile, especially in larger corporate environments. In those environments, you typically will need to add features and fixes to recently launched products, provide maintenance and support for older products until they reach their end of life and last, initiate and release new projects. This challenge has to be solved by any successful enterprise. The ‘Responding to Change over following a Plan’ thinking of the Agile Manifesto seems to contradict such an environment where big planning upfront seems to be mandatory. What a false truism! Agile is the perfect tool to combine those different types of work into regular cohesive but flexible releases. ​ This talk will show how a Scrum implementation based on release trains and agile portfolio management is an effective solution to a very common large enterprise problem.

1. Agile Portfolio
based
Release Trains
Ralph Jocham
effective agile.
ralph.jocham@effectiveagile.com

2. Ralph Jocham
•
•
•
•
•
•
•
•
Started as programmer; discovered process as a problem early on
First Unified Process with UML
Agile since 2000 with XP
Scrum in 2003
Oracle, LinkedIn, Roche, Google, The Gap, Swisscom, Texas Instruments, Siemens Medical,
ThoughtWorks, JPMorganChase
Did come around, different cultures and domains
Founder of effective agile.
Trainer with

3. 1 Product
Easy
1 Project
1 Scrum Team
26-­‐Sep-­‐13
effective agile.
3

4. OK
1 Product
1 Project
n Scrum Teams
26-­‐Sep-­‐13
effective agile.
4

5. n Products
n Projects
?
26-­‐Sep-­‐13
n Scrum Teams
effective agile.
5

6. Work is organized
by activity
Plan
è
è
26-­‐Sep-­‐13
Analyze
Design
Code
Test
Big Batches
Release
Major Releases
effective agile.
6

7. Phases and FTE/Multitasking
Number of emergency projects that must start
reduces
leads to
Number of new projects
that start
reduces
Number of active projects
leads to
perpetuates
reduces
leads to
Ease of managing the portfolio
Number of completed projects
leads to
leads to
Ability of people to finish projects quickly
Competition for people’s time
reduces
(source:
Johanna
Rothman)
26-­‐Sep-­‐13
effective agile.
7

8. 100%
50%
40%
Planning
Analysis
Design
Design
Dev
TesBng
Dev
Release
Planning
Release
TesBng
Major
Release
Release
Analysis
Design
Dev
Dev
TesBng
Release
Major
Release
100%
Planning
Analysis
Design
Dev
TesBng
Release
Major
Release
Planning
Analysis
Design
Dev
TesBng
Release
(Source:
Gerald
Weinberg,
Quality
SoNware
Management:
Systems
Thinking)
26-­‐Sep-­‐13
effective agile.
Major
Release
V1
©
2012
Ralph
Jocham
effective agile.
www.effectiveagile.com

9. n Products
n Projects
?
26-­‐Sep-­‐13
n Scrum Teams
effective agile.
9

10. Scrum is Fractal
26-­‐Sep-­‐13
effective agile.
10

11. We can apply the same
principles of the micro at
macro level …
Strategy
Portfolio
Product
Portfolio Backlog
Prioritize
Release
Sprint
Daily
26-­‐Sep-­‐13
Prioritize
effective agile.
Product Backlog
11

12. We can apply the same
principles of the micro at
macro level …
Strategy
Portfolio
Product
Portfolio Backlog
Prioritize
Release
Sprint
Daily
26-­‐Sep-­‐13
Prioritize
effective agile.
Product Backlog
12

13. Is this enough?
26-­‐Sep-­‐13
effective agile.
13

14. Three primary release strategies
Lots of changes, happen infrequently,
freezes other work, relatively stale
functionality, high customer absorption
costs.
Major
Minor
Minor
Minor
Minor
Functional
Lots of broad changes, happen more
frequently, often not cohesive, often
bug fixes instead of new functionality.
Individual pieces of functionality,
happen often, most important piece of
functionality at the time, relatively low
customer absorption costs.
(source: ADM)
26-­‐Sep-­‐13
effective agile.
14

15. Prioritized Portfolio
with
Functional Releases
26-­‐Sep-­‐13
effective agile.
15

16. Two problems to solve
How can we do this?
What does this mean for our requirements?
26-­‐Sep-­‐13
effective agile.
16

17. Classic approach
External Release
Release Docs
PRD
SRS
Dev
Drop 1 to
QA
Drop 2 to
QA
System test and bug
fix
Test Drop
1
MRD
Test Drop
2
Ports, Certs
(source: Dean Leffingwell)
26-­‐Sep-­‐13
effective agile.
17

18. Wanted approach
Start
External Release
Release Docs
Sprint
Sprint
Sprint
Harden
Sprint
Sprint
Sprint
Ports, Certs
(source: Dean Leffingwell)
Target
External Release
External Release
Release Docs
Release Docs
Sprint
Sprint
Sprint
Sprint
Sprint
Ports, Certs
26-­‐Sep-­‐13
Harden
effective agile.
Sprint
Sprint
Sprint
Ports, Certs
18

19. How can we do this
1. More Frequent releases – at least four per calendar year
External Release
2. Develop a cadence for the releases
3. Automate the build and deploy process
Sprint
Sprint
Sprint
Sprint
4. Enforce a prudent Definition of Done
5. Reduce the cycle time continuously
Release Docs
Ports, Certs
à Release Train
Release
4
26-­‐Sep-­‐13
Release
3
Release
2
effective agile.
Release
1
19

20. What does this mean
for our requirements
1. We
need
features
for
every
release
train
2. Break
down
the
projects
into
the
contained
features
3. Reduce
the
feature
granularity
4. Assign
right
sized
work
to
Dev
Teams
(not
resources
to
problems)
à No more Projects
26-­‐Sep-­‐13
effective agile.
20

21. $
$
F5
F6
Project 1
$
$
F3
$
F5
F4
$
$
F2
$
F5
F4
F5
$
F4
$
$
F2
F5
$
F3
F1
$
Project 3
$
$
F3
F4
$
F3
$
$
F1
$
Project 2
F1
$
$
$
F5
F2
F3
$
F1
$
$
F6
F2
$
F1
$
F3
$
$
$
F1
F4
F4
priorising by business
value and capacity
= project
Project
F4
= feature of project
$ = predicted ROI of feature
Software Development
Black Box
capacity is 4 features per release
F2
26-­‐Sep-­‐13
Release 3
F1
F3
F1
Release 4
F3
F5
F4
F4
Release 2
effective agile.
Release 1
Release
Train
1 per month
21

22. Strategic
Release n+1
Team B
Team Backlogs
Team
Scrum Teams
are cross-functional
Teams (Dev, Test,
BA, QA, …)
Team A
Release n
Scrum
Teams
Product
Owner, Scrum
Master, Dev
Team
Team B
Tactic/Strategic
Understood
Requirements
(Features)
Tactical
Release
Management
Team C
Team C
Product
Management
High-Level
Requirements
(Epics)
Release
Executable
Requirements
(User Stories)
Team A
Program
Area PO
Portfolio Backlog
Portfolio
Management
Program Backlog
Portfolio
Steering
Board / PMO
Sprint n
Sprint n+1
ConBnuous
IntegraBon
/
Deployment
effective agile.

23. Strategic
Release n+1
Team B
Team Backlogs
Team
Scrum Teams
are cross-functional
Teams (Dev, Test,
BA, QA, …)
Team A
Release n
Scrum
Teams
Product
Owner, Scrum
Master, Dev
Team
Team B
Tactic/Strategic
Understood
Requirements
(Features)
Tactical
Release
Management
Team C
Team C
Product
Management
High-Level
Requirements
(Epics)
Release
Executable
Requirements
(User Stories)
Team A
Program
Area PO
Portfolio Backlog
Portfolio
Management
Program Backlog
Portfolio
Steering
Board / PMO
Sprint n
Sprint n+1
ConBnuous
IntegraBon
/
Deployment
effective agile.

24. Team C
Tactical
Release n+1
Team B
Team Backlogs
Team
Scrum Teams
are cross-functional
Teams (Dev, Test,
BA, QA, …)
Team A
Release n
Scrum
Teams
Product
Owner, Scrum
Master, Dev
Team
Team B
Tactic/Strategic
Understood
Requirements
(Features)
Release
Executable
Requirements
(User Stories)
Team A
Release
Management
Team C
Sprint n
Integration
Scrum
Product
Management
Program Backlog
Program
Area PO
effective agile.
Sprint n+1

25. Tactical
Team C
Team B
Executable
Requirements
(User Stories)
Team A
Release
Sprint n
Integration
Scrum
Scrum Teams
are cross-functional
Teams (Dev, Test,
BA, QA, …)
Life
Cycle
Product
Owner, Scrum
Master, Dev
Team
Team Backlogs
Team
Scrum
Teams
effective agile.
Sprint n+1
Release Train

26. 100%
50%
40%
Planning
Analysis
Design
Design
Dev
TesBng
Dev
Release
Planning
Release
TesBng
Major
Release
Release
Analysis
Design
Dev
Dev
TesBng
Release
Major
Release
100%
Planning
Analysis
Design
Dev
TesBng
Release
Major
Release
Planning
Analysis
Design
Point
Release
V1
Dev
TesBng
Release
Point
Release
V1.5
Point
Release
V4.2
Point
Release
V4
FR
FR
FR
FR
FR
Major
Release
FR
FR
FR
FR
FR
FR
FR
FR
V1
©
2012
Ralph
Jocham
effective agile.
www.effectiveagile.com

27. Questions?
Ralph Jocham
effective agile.
26-­‐Sep-­‐13
www.effec*veagile.com
ralph.jocham@effecBveagile.com
@rjocham
effective agile.
27

28. References
• Manage
your
Project
Por_olio:
Increase
Your
Capacity
and
Finish
More
Projects,
Johanna
Rothman,
PragmaBc
Programmers,
2009
• Scaling
SoNware
Agilty:
Best
PracBces
for
Large
Enterprises,
Dean
Leffingwell,
Addison-­‐Wesley,
2007
• SoNware
in
30
Days:
How
Agile
Managers
Beat
the
Odds,
Delight
Their
Customers
and
Leave
the
CompeBtors
in
the
Dust,
Ken
Schwaber
&
Jeff
Sutherland,
Wiley,
2012
25-­‐Nov-­‐2011
effective agile.
28