by Louis Taborda This session describes a simple, self-organizing release management framework that addresses the integration and synchronization of interdependent user stories or the product components of multiple Scrum teams. Tracking these dependencies can be a problem especially when multiple teams contribute to an epic, There can be a temptation to revert to traditional, top-down release management, however this session describes how dependencies can be tracked bottom-up, using a shared construct we call the Collaboration Matrix, which helps multiple teams have visibility of their contribution to the epic allowing them to prioritize and coordinate their releases for optimal value. We start by reviewing the horizontal vs vertical cake slicing analogy and use simple scenario to illustrate the challenges faced in delivering business epics that span multiple teams. Dependencies resulting from functional (horizontal) teams can make tracking progress across different sprints and releases a multi-dimensional problem – i.e. too difficult. Value delivery requires teams with different velocities and capacities to synch their component releases so the desired workable software/ solution is delivered. This challenge is evident in all Agile scaling efforts and simple, team-based prioritization and release management is shown to have limitations that can result in sub-optimal prioritization of team backlogs – or plain, old bottlenecks. The Collaboration Matrix is introduced as a configuration management pattern resulting from research into a generalized approach to coordinate the release and integration of multi-component solutions. Its use as a self-organizing tool results from the visibility provided to each component team of the dependencies and blockers to the readiness of an epic or solution release train. The matrix, with its visual (Kanban style) representation, can be used in conjunction with other scaling frameworks, including Scrum of Scrums, LeSS and SAFe, to improve value delivery even where value is obscured by dependencies.

1. © Alinement Network, 2018
Multi Team (Agile) Release Framework
Alinement Network & USYD
Scrum Australia, 25th Oct 2018
Dr Louis J. Taborda

2. © Alinement Network, 2018
Agenda
Release Dependencies
Collaboration Matrix
Conclusions & Questions
Introductions
Multi Release Context

3. © Alinement Network, 2018
Introductions
And the winner is …
Survivor of the Methodology Wars

4. © Alinement Network, 2018
Introductions
And the winner is …
Survivor of the Methodology Wars
The Winter Getaway That Turned the Software World Upside Down
AGILE!
More to the point – Scrum Won!

5. © Alinement Network, 2018
Seeking Oneness
▪ Once a Physicist ….
− The Holy Grail of a unified theory
▪ Defence systems development
− Discovered the discipline of Configuration Management
− Software CM evangelist for tools that supported Agile/ DevOps
▪ Realization that configurations have arbitrary boundaries
− In complex systems you only control a component
− But all components have to work together as one!
▪ Later consulted in software process improvement
− Realized development models are just theories
− Still seeking one unifying model!

6. © Alinement Network, 2018
▪ Configuration Management (CM) is an
interesting discipline
− Encompasses people, process and product
− Starting point of my research
▪ More often we split management between
people and product
− We can benefit from Agile’s more balanced
and holistic perspective
− And CM’s multiple versions & dependencies
capture the release management challenge
− Value in making CM challenge more visible
rather than hidden in testing/ build scripts
An Oldie but a Goodie!
Product
PeoplePeople
Product
+

7. © Alinement Network, 2018
Trying to get the big picture can drive you a little crazy!
What we need is to understand some simple recurring patterns.
Think Mad Wall – Remind you of Dependencies?!?

8. © Alinement Network, 2018
Technical Oneness!
The Release Management Challenge
Single Developer

9. © Alinement Network, 2018
Team Oneness!
The Release Management Challenge
Team of Developers

10. © Alinement Network, 2018
The Release Management Challenge
A Team of Teams
Complex Product Oneness?

11. © Alinement Network, 2018
The Problem Domain
▪ A multi-dimensional release puzzle
− Shared understanding of the product/ solution
− Synchronization of delivery
− Integration of (architectural) components
− Testing of compatible component versions
▪ Difficult even for relatively simple product/ solution
− It is not just a development problem
− It is also a logistics and delivery problem
▪ That needs an end-to-end lifecycle viewpoint
− To get the full picture!
Coordinating the Multi Team Release

12. © Alinement Network, 2018
Delivery is about integration, test
and release of product components
Development starts with selection
and breakdown of epics/ features
Analysis Integration
& Test

13. © Alinement Network, 2018
Breaking Down Requirements
Point where theories diverge - Agile Cake Analogy
If the product or solution a teams
is developing is a multi-layer cake:
▪ Teams should work on vertical slices
(user stories) that cut across multiple
architectural components to deliver a
working story or feature
▪ Work should not be allocated as
horizontal slices (to specialist/
architectural team) as it does not
result in working software!

14. © Alinement Network, 2018
Breaking Down Requirements
Point where theories diverge - Agile Cake Analogy
If the product or solution a teams
is developing is a multi-layer cake:
▪ Teams should work on vertical slices
(user stories) that cut across multiple
architectural components to deliver a
working story or feature
▪ Work should not be allocated as
horizontal slices (to specialist/
architectural team) as it does not
result in working software!
Vertical slices are “natural” and
clearly relate to value delivery
and MVP considerations
Agile demands cross-functional teams … using specialist teams results in dependencies!

15. © Alinement Network, 2018
Agile Theory Suited to Small Teams
Specifically avoiding some situations
▪ At scale it is sometimes impossible for teams to be responsible
for all facets of a product/ solution
− Vendor/ Partners
− Distributed teams
− Centralized specializations e.g. Security
− Working software is somewhat unique to software
▪ Consider non-software aspects in enterprise:
− Procurement
− Infrastructure
− Engineering
− Legal
− Marketing
What happens if we embrace the possibility of dependencies?!?

16. © Alinement Network, 2018
Specialists (Dependencies) …
… are BAD!
… are good?
… are important!!!
Researcher

17. © Alinement Network, 2018
Dependencies Destroy Everything!
▪ Even simple dependencies create problems – they are BAD!
▪ One reason for the failure of Project Planning
▪ Introduces risk/ uncertainly with permutations + combinatorics
▪ Plans become unstable and minor changes have a ripple-on effect
Initial
Plan
d2
d1
t
New Baseline
Discovered
d’1
d’2
t’
Next Baseline
Discovered
d’’1
d’’2
t’’
Release
Planning
Team 1
Team 2
Team 3
When we cannot address dependencies and the churn … we lose flow!

18. © Alinement Network, 2018
Scott Adams Got It!
Dependencies!
Bottlenecks!
Cadence Mismatch!Silos!
Delays!
Waste!
Releases are where the dependencies rise up and bite us!

19. © Alinement Network, 2018
Scalability, Theories & Patterns
▪ Two apparently different ends of the spectrum
o Small and Agile
o Large and Controlled
▪ Is there is an answer that works across both
o An answer/ technique that scalable
o A “well grounded” one ideally should
▪ Does it make sense at different levels in the
organization?
o The ultimate “test” for any theory/ method(ology)
Seek unifying constructs – that resonate and scale!

20. © Alinement Network, 2018
Notice anything similar about these models?
Requirements
Analysis
Solution
Design
Detailed
Design
Construction
Testing
Maintenance
Requirements
Analysis
Acceptance
Testing
Solution
Design
Detailed
Design
Integrating
Testing
Unit
Testing
Construction
a) Waterfall Model, 1970 b) V Model, 1991-7 c) Spiral Model, 1986 d) SCRUM, 1986
How different are they lifecycles really?

21. © Alinement Network, 2018
Multi-Project Execution & Release
Program A
Project C
Project B
REL 1
Project D
Project B
REL 2
MULTI-PROJECT DELIVERY
Different techniques needed
to manage:
• Integration
• Interdependencies
• Synchronization
BAU
My research explores the different patterns found in multi-project environments

22. © Alinement Network, 2018
The Release from Planning to Delivery
Customer requirements
o Features or Epics
o Drawings or Blueprints
o Documents or Specifications
Organize people to work on it
o Team(s)
o Project(s)
NEED SOLUTION
?
Domain specific products
o IT System
o Building or Facility
o Organization Transformation
Generically
o Configuration of components
o Configuration Item (CI)

23. © Alinement Network, 2018
Scaling Pattern – Team(s) and Component(s)
▪ Traditional management patterns were
appropriate for their time
1. Team delivering single-use monolithic
product/ solution
2. Team of Teams delivering complex,
integrated product/ solution
3. Teams reliant upon vendors / commercial
components COMPONENTTEAM
m 1
3
COMPONENTTEAM
1 n
2
TEAM COMPONENT
1 1
1
© Alinement, 2009
CONTROL
CONTROL
CONTROL

24. © Alinement Network, 2018
Generalized Release Pattern
COMPONENTTEAM
m n
4
© Alinement, 2009
COLLABORATION
▪ The fourth pattern is where things get
interesting
− The result of increased complexity which
challenges our language / constructs – both
planned & agile
− Suggests a highly inter-dependent
environment that requires collaboration rather
than control
− Products team no longer independent and
have to synchronize with each other for
integration
− Model separates planning and implementation
and works well with project terminology – still
figuring out agile consequences
TEAM COMPONENT
a) Textbook Pattern
11
TEAM COMPONENT
b) Integration Pattern
n1
TEAM COMPONENT
c) Reuse Pattern
1m
TEAM COMPONENT
d) Enterprise Pattern
nm
Teams Components
T1
T2
T3
C 4
C 3
C 2
C 1
Does it take us closer to a unified theory?

25. © Alinement Network, 2018
Teams Components
T1
T2
T3
C 4
C 3
C 2
C 1
Relationships
C1 C3 C4
1
1 1
1
0
0
C2
1 1
1
0
0
1
T1
T3
T2
Architecture
Teams
Relationships
A Technique to Take Away
The Collaboration Matrix Representation
Components
Generalization that usage of components is separated from ownership/ implementation.

26. © Alinement Network, 2018
Join
Table
TEAM COMPONENT
COLLABORATION
MATRIX
1 1
m n
Derivation of Collaboration Matrices
TEAM COMPONENT
Release Pattern
nm
• Classic “normalization” method introduces a join table
• Which is our Collaboration Matrix
TEAM COMPONENT
COLLABORATION
MATRICES
1 1
n n
RELEASE
1
n
Release meets the need to
synchronize, integrate & baseline

27. © Alinement Network, 2018
Requirements & Stories in Matrix Notation
These three teams are concurrently attempting to release …
We can put the requirements (or epics and stories) for a
component in the appropriate cell
C1 C3 C4
r 1 1
r 3 3 r 3 4
r 1 4T1
T3 0
0
C2
r 2 3 r 2 4
r 1 2
T2 0
0
r 2 2
System Engineering
calls this breakdown into
component requirements
– System Design!
This product’s
requirement (epics)
can be decomposed into
stories/ requirements
(r11, r12. r14)
And this would be an
“allocated requirement”

28. © Alinement Network, 2018
Consider Different Stakeholder Viewpoints
Project / Change PerspectiveProduct/ Project Team Perspective – Vertical Cake Slice
IT / Ops PerspectiveComponent/ Specialist Team – Horizontal Cake Slice

29. © Alinement Network, 2018
Can Matrices Capture Product Releases?
C_1 C_3 C_4
ProductReleases
r 1 1
r 3 3 r 3 4
r 1 4T1
T3 0
0
C_2
r 2 3 r 2 4
r 1 2
T2 0
0
r 2 2
P1
P
P2
Team of Team release:
Pity it is the
opposite of a
cake slice!

30. © Alinement Network, 2018
Feature Delivery
o Focus on rows to deliver workable software
o This perspective needs product teams to
worry/ track the (external) dependencies
o But these matrices now make it visible!

31. © Alinement Network, 2018
Can Matrices Capture Component Releases?
C_1 C_3 C_4
r 1 1
r 3 3 r 3 4
r 1 4
0
0
C_2
r 2 3 r 2 4
r 1 2
0
0
r 2 2
C_1 C_3 C_4C_2
T1
T3
T2
Component Releases
Separate technical component capability readiness.

32. © Alinement Network, 2018
Architectural Coherence
o Focus on columns to ensure technically coherent
design with merged/ generalized component
evolution
o This perspective supports good, “big” design to
ensures less technical debt but may not be
delivering product/ customer value

33. © Alinement Network, 2018
The Collaboration Matrix
Consider both product and technical dimensions with different
teams all working to deliver agreed (baselined) requirements in
a release/ timebox:
• Project Managers drive a horizontal focus
• Component teams (e.g. specialist teams) take a vertical perspective
Portfolio planning must balance the two!
• Requires negotiation and collaboration
Component Releases
ProductReleases
C_1 C_3 C_4
r 1 1
r 3 3 r 3 4
r 1 4P_1
P_3 0
0
C_2
r 2 3 r 2 4
r 1 2
P_2 0
0
r 2 2
Why might supplier C_4
not be able to deliver all
requirements? What is
the priority now?
All three requirements
have to be met by the
component suppliers
before result is delivered!

34. © Alinement Network, 2018
More Than a Theory!
Scaling releases can scale teams and so Agile
• SAFe does this with massive (synchronous) PI meetings
The Collaboration Matrix is a neutral framework / tool
• Can be used for control and/or self-organization
• Provides Choice e.g. synchronous or synchronous
Agile because there is no need for managers
• Use as a shared “dependency board” much like Kanban
• Empower everyone to identify, address & negotiate
• Recognize & address bottlenecks in the flow
We are using the “Collaboration Matrix” for an
overall view of the scope of a release. This has helped
us track the scope and the teams involved in the
MPV delivery [and] gives us a better view planning
PI plus 2.
Product Release Lead
USA Corporate adopting SAFe

35. © Alinement Network, 2018
So What !?!
Shared
Perspectives
Striving for ONE Truth!

36. © Alinement Network, 2018

37. © Alinement Network, 2018
If any of this sounds familiar …
I am collecting case studies
on multi-team release!

38. © Alinement Network, 2018
Louis.Taborda@alinement.net
Further information?