DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? - Matthew Skelton, Conflux

More than 10 years ago - in October 2013 - the influential DevOps Topologies patterns were published by Matthew Skelton. Since then, the DevOps Topologies patterns have been used by thousands of organizations including Netflix, Condé Nast International, adidas, and Accenture to improve their approaches to building and running software services at scale. These patterns were the early inspiration for the groundbreaking and award-winning book Team Topologies - authored in 2019 by Matthew Skelton and Manuel Pais - which has sold over 150,000 copies worldwide.

Another vital industry resource that began life in 2013 is the State of DevOps Report assessments. These reports are based on insights from thousands of IT professionals around the world and use rigorous statistical approaches to create predictive relationships between practices and outcomes. Out of the State of DevOps Reports came the Accelerate metrics (aka DORA metrics) which have helped many thousands of organizations to focus on key foundational practices for high performance in IT.

However, even after more than 10 years of consistent, clear, actionable advice and recommendations, many organizations are still stuck in a low-performing state. Why is this? What is holding back these organizations from improving their IT delivery performance?

In this talk, Matthew Skelton - CEO at Conflux and co-author of the book Team Topologies - explores the key learnings from 10 years of Team Topologies and State of DevOps Reports and outlines key steps that organizations can take to improve IT delivery performance:

- Organize for flow
- Address team cognitive load
- Estimate the cost of “tangled software”
- Use the Accelerate metrics and community techniques to find good boundaries for flow
- Develop secure foundations in social and technical practices that support fast flow
- Take a realistic view about the nature and scale of change needed

By combining learnings from State of DevOps Reports and Team Topologies together with principles championed by the DevOps community, organizations can navigate a route to business agility via a fast flow operating model.

---

Video: https://youtu.be/H0hcHFW4SmU?si=rXPquTiKWaGh0ygD

Transcript

1. DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? Matthew Skelton, Conflux - co-author of Team Topologies Eficode DEVOPS Conference, London | 2024-03-14 K26 Image CC BYNC Duncan Rawlinson https://duncan.co/land-of-plenty/
2. Photo goes here Matthew Skelton Founder at Conflux Co-author of Team Topologies “Ecosystem engineering” LinkedIn: linkedin.com/in/matthewskelton Mastodon: mastodon.social/@matthewskelton 2
3. Team Topologies Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press, September 2019 Order via stores worldwide: teamtopologies.com/book 3
4. Ten years after SODOR and DevOps Topologies, what is holding back lower-performing organizations from improving their IT delivery performance? 4
5. 10 years on: DOTs and SODOR The cost of tangled software Accelerate metrics + TT for flow Success with fast flow 5
6. Almost all decisions need to use the twin ‘lenses’ of fast flow and team cognitive load 👓 6
7. [key point] 7
8. 10 years on: DevOps Topologies and State of DevOps Reports 8
9. 9 2013: Epic battles between Dev and Ops
10. 10 https://blog.matthewskelton.net/2013/10/22/what-team-s tructure-is-right-for-devops-to-flourish/
11. 11 https://web.devopstopologies.com/
12. 12 https://web.devopstopologies.com/ Used by Netflix, Condé Nast, Accenture, etc. etc.
13. Thanks to Gene Kim and IT Revolution Press (and many other inspiring people) 13
15. 15 https://confluxhq.com/d evops-topologies
16. 16 Image taken from devopstopologies.com - licensed under CC BY-SA Example: Anti-Type B (DevOps Team Silo)
17. 17 Image taken from devopstopologies.com - licensed under CC BY-SA Example: Anti-Type E (Rebranded SysAdmin)
18. 18 Image taken from devopstopologies.com - licensed under CC BY-SA Example: Anti-Type H (Fake SRE)
19. 19 Image taken from devopstopologies.com - licensed under CC BY-SA Example: Type 1 (Dev and Ops Collaboration)
20. 20 Image taken from devopstopologies.com - licensed under CC BY-SA Platform grouping Stream-aligned team Collaboration Flow of value DevOps Topologies (2013) Team Topologies (2019+)
21. 21 Image taken from devopstopologies.com - licensed under CC BY-SA Example: Type 3 (Ops as Infrastructure-as-a-Service (Platform))
22. Stream-aligned team 22 Image taken from devopstopologies.com - licensed under CC BY-SA Platform grouping Stream-aligned team Flow of value DevOps Topologies (2013) Team Topologies (2019+) XaaS XaaS
23. 23 Image taken from devopstopologies.com - licensed under CC BY-SA Example: Type 5 (DevOps Team with an Expiry Date)
24. 24 Image taken from devopstopologies.com - licensed under CC BY-SA Platform grouping Stream-aligned team Flow of value DevOps Topologies (2013) Team Topologies (2019+) Facilitating Enabling team
25. Platform grouping 25 Flow of change Stream-aligned team Stream-aligned team Complicated Subsystem team XaaS XaaS Collaboration Stream-aligned team xN 💡 Team Topologies diagrams are always just “snapshots in time”, never fixed designs
26. 26 0 - Success lies in addressing dynamic interactions, not static structure [alone]
27. 27 State of DevOps Reports (SODOR)
28. 28 State of DevOps reports 2013 2014 2015 2016 2017 2018 2019 Annual survey of 1000-5000 IT professionals worldwide using rigorous statistical methods 2020 2021 2022 2023 https://www.puppet.com/resources/history-of-devops-reports
29. 29 State of DevOps 2019 “The use of cloud… is predictive of software delivery performance and availability.” “High performers favor strategies that create community structures at both low and high levels in the organization...”
30. 30 State of DevOps 2019 “Heavyweight change approval processes, such as change approval boards, negatively impact speed and stability. In contrast, having a clearly understood process for changes drives speed and stability, as well as reductions in burnout.”
31. 31 State of DevOps 2019 “We use a structural equation model (SEM), which is a predictive model used to test relationships” → Improvements in practices predict improved organizational performance
32. 33 Team Topologies practices are predictive of higher organizational performance - SODOR https://www.puppet.com/resources/state-of-devops-report “Highly evolved organizations tend to follow the Team Topologies model”
33. 34 Team Topologies ideas are now a key part of the AWS ‘Well-architected’ guidance https://docs.aws.amazon.com/wellarchitected/latest/devops-guida nce/oa.std.1-organize-teams-into-distinct-topology-types-to-optimiz e-the-value-stream.html “[OA.STD.1] Organize teams into distinct topology types to optimize the value stream”
34. 35 Team Topologies ideas are now a key part of the Azure ‘Cloud Adoption Framework’ https://learn.microsoft.com/en-us/azure/cloud-adoption-framew ork/ready/considerations/devops-teams-topologies “Consider establishing an enabling team that can … support applications and platforms … ”
35. 36 2013 2024+
36. 37 2013 2024+ Practitioner-led co-evolution
37. 38 Financial Conduct Authority (FCA) in the UK ‘Implementing Technology Change’ - 2021 report “Overall, we found that firms that deployed smaller, more frequent releases had higher change success rates than those with longer release cycles. Firms that made effective use of agile delivery methodologies were also less likely to experience a change incident.” https://www.fca.org.uk/publications/multi-firm-reviews/implementing-technology-change
38. The cost of tangled software 39
39. 40 If each engineer in the organization is blocked for 1 hour per working day, how much does this cost?
40. 41 • Fully-loaded cost: €160k per year • 260 paid days per year • Total of 400 engineers
41. 42 Engineer fully weighted cost per year Engineer cost per day Hours blocked per 8-hour day Days blocked per 260-day year Cost of blockers per engineer per year Number of engineers Total cost of blockers per year €160,000.00 €615.38 1 32.5 €20,000.00 400 €8,000,000.00 €8 million per year 💥
42. Untangling ≃ Decoupling 43
43. Decoupling: separating things that do not need to be together 44
45. Decoupling enables shorter time-to-value 46
46. Decoupling enables multiple, independent flows of change, each with its own cadence 47
47. 48 Multiple, independent flows
48. Decoupling of teams & technology vs Mingling of ideas for learning 49
49. Decoupling: teams, software, technology, deployments, data, business concepts, ... 50
50. Mingling: principles, practices, learning, techniques, approaches, ... 51
51. 52 Cost of Delay https://blackswanfarming.com/four-steps-to-quantifying-cost-of-delay/
52. 53 1 - Organizing for fast flow helps us to remove inter-team dependencies, improving financial efficiency and time-to-value
53. Accelerate metrics + TT for flow 54
54. 🔍 Use the 4 Key Metrics from Accelerate and add “blocker count” 55
55. Accelerate Building and Scaling High Performing Technology Organizations Nicole Forsgren, Jez Humble, Gene Kim IT Revolution Press, 2018 Order via stores worldwide: https://itrevolution.com/book/accelerate/ 56
56. 4 key metrics: ‘Accelerate’ lead time deployment frequency Mean Time To Restore change fail percentage
57. 4 key metrics: ‘Accelerate’ lead time deployment frequency Mean Time To Restore change fail percentage Encourage fast flow
58. 4 key metrics: ‘Accelerate’ lead time deployment frequency Mean Time To Restore change fail percentage Encourage operability
59. What % of lead time is actual work? Example: 120 hours / (120+630) x 100 = 16% Flow Efficiency 60
60. Measure ‘wait time’? https://www.isixsigma.com/methodology/lean-methodology/identify-constraints-and-reduce-wait-time-processes/ 61
61. Measuring ‘wait time’ is hard Count the number of blocking waits as a proxy ✨ 62
62. 4 key metrics & ‘blocker count’ lead time deployment frequency Mean Time To Restore change fail percentage ‘blocker count’ as a proxy for flow efficiency 63
63. Use 4 key metrics 📊 + “blocker count” to assess and find better service & team boundaries for flow 64
64. “If we adjusted the service & team boundary here, would it improve the 4 key metrics?” 💓 65
65. “If we adjusted the service & team boundary here, reduce the blocker count?” 📉 66
66. 67 TeamForm teamform.co
67. TeamOS 68 teamos.is Disclosure: Matthew Skelton has invested personally in the company behind TeamOS
68. Techniques from the Team Topologies community 69
69. 70 Independent Service Heuristics (ISH)
70. 71 “The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product.” https://teamtopologies.com/ish
71. 72 User Needs Mapping (UNM)
72. 73 “User Needs Mapping attempts to capture the first 4 steps of the Wardley Mapping process … for identifying potential team [and service] boundary” https://teamtopologies.com/unm
73. 74 Team Interaction Modeling (TIM)
74. 75 “[Team Interaction Modeling helps] to describe how to re-organize … teams and their interactions to achieve better flow and deliver value faster.” https://teamtopologies.com/tim
75. 76 2 - Evolving at speed requires a set of core principles and practices, with people trained up and engaged
76. Success with fast flow 77
77. Case Study JP Morgan 78
78. Case Study “How JP Morgan Applied Team Topologies to Improve Flow in a Market Leading Enterprise Platform” 79 https://www.youtube.com/ watch?v=y3OL7dv2l48 Fast Flow Conf 💖 https://www.fastflowconf.com/
79. Case Study 80
80. Case Study “60% of dependencies reduced through better team design” 💥 81
81. 82 Engineer fully weighted cost per year Engineer cost per day Hours blocked per 8-hour day Days blocked per 260-day year Cost of blockers per engineer per year Number of engineers Total cost of blockers per year €160,000.00 €615.38 1 32.5 €20,000.00 400 €8,000,000.00 €8 million per year 💥 Remember this? [Note: these are not figures from JP Morgan]
82. 83 3 - Unblock, not coordinate.
83. Case Study GOV.UK Home Office 84
84. Case Study “How the Home Office’s Immigration Technology department reduced its cloud costs by 40%” 85 https://www.gov.uk/government/case-studies/how- the-home-offices-immigration-technology-departm ent-reduced-its-cloud-costs-by-40
85. 86 https://www.gov.uk/government/case-studies/how-the-home-offices-immigration-technology-department-reduced-its-cloud-costs-by-40
86. Case Study Making service owners accountable for the $ spend for their service helps to clarify service boundaries 💡 87
87. Use cost metrics as a “financial scalpel” 🔪 to split services apart for fast flow 88
88. Principles from Team Topologies that suggest certain architectures 95
89. 96 Multiple, independent flows, fractally
90. Respect Conway’s Law (aka ‘sociotechnical mirroring’) 97
91. Clear ongoing ownership of services and systems 98
92. Stream-aligned teams have end-to-end responsibility for a service (You Build It, You Run It) 99
93. Platforms improve flow and reduce extraneous cognitive load 100
94. Teams are small (~9), slowly changing, with ‘aligned autonomy’ 101
95. Teams are empowered to sense and adjust boundaries to improve flow on a frequent basis 102
96. 103 Architecture for fast flow resembles an ecosystem of loosely-coupled independently-viable services with clear boundaries and ownership aligned to the flow of business value.
97. 104 Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow – 7 July 2024 Susanne Kaiser See https://www.infoq.com/presentations/ddd-wardley- mapping-team-topology/
98. 105 4 - Multiple, loosely-coupled flows of value, with significant automation & helper tooling.
99. Team Topologies is a set of coherent patterns to encourage emergent behaviours for fast flow 106 Matthew Skelton
100. TT pattern #1 107 4 team types (well, 3 + 1) grouping Image © 2019 Matthew Skelton and Manuel Pais. Used with permission.
101. Each team type (or grouping) has specific expected behaviors 108
102. Each team type (or grouping) has a specific relation to flow and team cognitive load 109
103. TT pattern #2 110 3 team interaction modes Image © 2019 Matthew Skelton and Manuel Pais. Used with permission.
104. The constraints on interactions provide signals to tell us when boundaries are not good for fast flow 111
105. The constraints on interactions provide signals to tell us about intent/mission, capabilities, skills, strategy, and lots more… 112
106. TT pattern #3 113 fast flow
107. Organizing for fast flow means we are happy with: duplication, (a few) different versions, async + eventual consistency, ‘internal marketplace’, etc. 114
108. TT pattern #4 115 team cognitive load
109. Using team cognitive load as a key architectural and design principle means we have a humane, compassionate, and realistic workplace 116
110. TT pattern #5 117 thinnest viable platform (TVP)
111. TVP avoids ‘platform bloat’ by focusing on enhancing flow and reducing team cognitive load - rather than technology 118
112. TT pattern #6 119 empower teams to adjust boundaries to enhance flow
113. Empowering teams to adjust boundaries for flow uses local knowledge for regular incremental gains, avoiding a dreaded ‘Re-org’ every 5 years 120
114. 121 “The work is delivered in many small changes that are uncoordinated to enable flow. … Management’s job is to provide context, prioritization and to coordinate across teams. Lending resources if needed across teams to unblock things. … It works well within a high trust culture.” Adrian Cockcroft https://mastodon.social/@adrianco/111174832280576410 Technology strategy advisor, Partner at OrionX.net (ex Amazon Sustainability, AWS, Battery Ventures, Netflix, eBay, Sun Microsystems, CCL)
115. 122 5 - Team Cognitive Load as a key design heuristic
116. 123 6 - Long-lived value streams, not short-lived projects
117. 124 Re-aligned architecture
118. 125 Fast feedback via deployment pipelines
119. 126 Good technical practices (TDD, …)
120. 127 Team ownership of software & services
121. 128 Configuration in version control (Git)
122. 129 Cloud-native: transparent in operation
123. 130 Cloud-native: designed for automation
124. 131 Continuous testing performance scanning deployment monitoring right-sizing integration
125. 132 Psychological safety
126. 133 Active diffusion of learning across team boundaries
127. 134 7 - Strong technical and social practices as a foundation
128. 10 years on: DOTs and SODOR The cost of tangled software Accelerate metrics + TT for flow Success with fast flow 135
129. Ten years after SODOR and DevOps Topologies, what is holding back lower-performing organizations from improving their IT delivery performance? 136
130. organizing for flow feels alien to many 👾 137
131. 138 limited mindset shifts
132. CxO concerns ignored 139
133. ‘silver bullet’ re-org 140
134. “structure” will fix it 141
135. tight coupling in time 142
136. limited diffuse learning 143
137. limited psych safety 144
138. 145 success factors
139. 146 0 - Address the dynamic interactions between teams and groups, not just static structure
140. 147 1 - Organizing for fast flow helps us to remove inter-team dependencies, improving financial efficiency and time-to-value
141. 148 2 - Evolving at speed requires a set of core principles and practices, with people trained up and engaged
142. 149 3 - Unblock, not coordinate.
143. 150 4 - Multiple, loosely-coupled flows of value, with significant automation & helper tooling.
144. 151 5 - Team Cognitive Load as a key design heuristic
145. 152 6 - Long-lived value streams, not short-lived projects
146. 153 7 - Strong technical and social practices as a foundation
147. Almost all decisions need to use the twin ‘lenses’ of fast flow and team cognitive load 👓 154
148. 155 What’s your perspective? Which aspects resonate? Which things feel incorrect?
149. 156 expert-led coaching and group learning for adopting fast flow and Team Topologies confluxhq.com
150. thank you confluxhq.com Copyright (c) 2017-2024 Conflux group of companies. All Rights Reserved. The name “Conflux” and the filled C device are Registered Trademarks ® in multiple jurisdictions.