Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Multi team release framework

62 views

Published on

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.

Published in: Business
  • Be the first to comment

Multi team release framework

  1. 1. © Alinement Network, 2018 Multi Team (Agile) Release Framework Alinement Network & USYD Scrum Australia, 25th Oct 2018 Dr Louis J. Taborda
  2. 2. © Alinement Network, 2018 Agenda Release Dependencies Collaboration Matrix Conclusions & Questions Introductions Multi Release Context
  3. 3. © Alinement Network, 2018 Introductions And the winner is … Survivor of the Methodology Wars
  4. 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. 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. 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. 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. 8. © Alinement Network, 2018 Technical Oneness! The Release Management Challenge Single Developer
  9. 9. © Alinement Network, 2018 Team Oneness! The Release Management Challenge Team of Developers
  10. 10. © Alinement Network, 2018 The Release Management Challenge A Team of Teams Complex Product Oneness?
  11. 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. 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. 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. 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. 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. 16. © Alinement Network, 2018 Specialists (Dependencies) … … are BAD! … are good? … are important!!! Researcher
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 35. © Alinement Network, 2018 So What !?! Shared Perspectives Striving for ONE Truth!
  36. 36. © Alinement Network, 2018
  37. 37. © Alinement Network, 2018 If any of this sounds familiar … I am collecting case studies on multi-team release!
  38. 38. © Alinement Network, 2018 Louis.Taborda@alinement.net Further information?

×