Slide 1

Slide 1 text

TeamTopologies.com @TeamTopologies Frozen DevOps? The not-so-technical Last Mile Manuel Pais co-author of Team Topologies 11 Apr 2024 @manupaisable

Slide 2

Slide 2 text

Team Topologies 5 Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press, 2019 teamtopologies.com/book

Slide 3

Slide 3 text

Remote Team Interactions Workbook 7 Using Team Topologies Patterns for Remote Working Matthew Skelton & Manuel Pais IT Revolution Press, 2022 teamtopologies.com/workbook

Slide 4

Slide 4 text

“Team Topologies provides a practical set of templates for addressing the key DevOps question that others leave as an exercise for the student” - Jeff Sussna 8

Slide 5

Slide 5 text

9 DevOps

Slide 6

Slide 6 text

10 2018 → Early Majority 2019 → Late Majority 2020 → Late Majority 2021 → Late Majority 2022 → Late Majority InfoQ Trends - “General DevOps”

Slide 7

Slide 7 text

11 https://puppet.com/resources/report/2021-state-of-devops-report

Slide 8

Slide 8 text

12 “Success at scale requires optimizing not for the individual, and not for the team, but for the wider organization - the “team of teams”. Highly evolved organizations have discovered the patterns that work well for a fast flow of change”

Slide 9

Slide 9 text

13 Low performing orgs 2018 = 11% 2019 = 7% 2020 = 5% 2021 = 4%

Slide 10

Slide 10 text

14 High performing orgs 2018 = 10% 2019 = 14% 2020 = 16% 2021 = 18%

Slide 11

Slide 11 text

15 Mid performing orgs 2018 = 79% 2019 = 79% 2020 = 79% 2021 = 78%

Slide 12

Slide 12 text

16 Mid perf 2018 = 79% 2019 = 79% 2020 = 79% 2021 = 78%

Slide 13

Slide 13 text

17

Slide 14

Slide 14 text

Why are so many organizations frozen in the DevOps middle? 21

Slide 15

Slide 15 text

22 We have Cloud, CI/CD, SRE & Observability Mid perf

Slide 16

Slide 16 text

23 “Organizations should not expect to become highly evolved just because they use cloud and automation… They are held back by organizational structure and dynamics”

Slide 17

Slide 17 text

⏳ ⏳ Blocking Non- Blocking Cloud Infra Deploy

Slide 18

Slide 18 text

25

Slide 19

Slide 19 text

“Devops was always as much about org structure and incentives as any of the technical details.” - Andrew Clay Shafer 26

Slide 20

Slide 20 text

27 Organizations where teams have strong identities that are well understood, with clearly defined responsibilities, are far more likely to be higher performing

Slide 21

Slide 21 text

29 We have Cloud, CI/CD, SRE & Observability Mid perf

Slide 22

Slide 22 text

We have teams with a clear mission and purpose that is understood by other teams 30 High perf

Slide 23

Slide 23 text

31 Everyone collaborates with everyone else Mid perf

Slide 24

Slide 24 text

32 “Collaboration is expensive [for real-time work]… it’s not scalable or repeatable. ”

Slide 25

Slide 25 text

33

Slide 26

Slide 26 text

34

Slide 27

Slide 27 text

35 Slow feedback loop (weeks/months)

Slide 28

Slide 28 text

36

Slide 29

Slide 29 text

37 “if you simply adopt the team types, you’re missing one of the key takeaways... which is paying attention and being deliberate about teams’ setup and their desired interaction”

Slide 30

Slide 30 text

Team API 38 ● Services & software owned by the team ● Wiki and documentation ● Practices and principles ● Communication: tools, channels, patterns ● Roadmap & priorities

Slide 31

Slide 31 text

39 https://github.com/TeamTopologies/Team-API-template

Slide 32

Slide 32 text

Team API 40 ● Services & software owned by the team ● Wiki and documentation ● Practices and principles ● Communication: tools, channels, patterns ● Roadmap & priorities ● Current and future team interactions

Slide 33

Slide 33 text

Team A 41 Teams we currently interact with: Team Name Interaction Mode Purpose Duration Test Automation Enabling team Facilitating Understand test automation and data mgmt examples for iOS 2 months (from Mar 30 to May 29, 1 day per week) Monitoring & Telemetry Platform team Collaboration Store and visualize data on product features usage 3 weeks (from Apr 13 to Apr 30, 2h per day)

Slide 34

Slide 34 text

“Collaboration” might be masking blocking dependencies 42 🤯

Slide 35

Slide 35 text

Team A 43 Teams we expect to interact with soon: Team Name Interaction Mode Purpose Duration Infrastructure team Collaboration Change and test AWS modules to support our new AI backend service 1 week ?? (May??? June???)

Slide 36

Slide 36 text

Team A 44 Teams we expect to interact with soon: Team Name Interaction Mode Purpose Duration Infrastructure team Collaboration Change and test AWS modules to support our new AI backend service 1 week ?? (May??? June???)

Slide 37

Slide 37 text

Team A 45 Teams we expect to interact with soon: Team Name Interaction Mode Purpose Duration Infrastructure team Collaboration Be able to change Terraform AWS modules for backend services 3 half days (from May 6 to May 8, 9am-1pm CET)

Slide 38

Slide 38 text

Team A 46 Teams we expect to interact with soon: Team Name Interaction Mode Purpose Duration Infrastructure team Facilitating Understand internal Terraform structure & naming conventions 1 half day (on May 6) Infrastructure team Collaboration Be able to change Terraform AWS modules for backend services 3 half days (from May 13 to May 15, 9am-1pm CET)

Slide 39

Slide 39 text

Team dependencies tracking 47 https://github.com/TeamTopologies/Team-Dependencies-Tracking

Slide 40

Slide 40 text

48 Everyone collaborates with everyone else Mid perf

Slide 41

Slide 41 text

We welcome purposeful interactions that have clear goals and duration 49 High perf

Slide 42

Slide 42 text

Case Study 50 “DevOps Over Coffee - Adidas”

Slide 43

Slide 43 text

Case Study 51

Slide 44

Slide 44 text

52 We have fully autonomous “build & run” teams Mid perf

Slide 45

Slide 45 text

53 “If cognitive load is left “unbounded” then… performance metrics will be negatively affected, preventing teams from evolving to higher levels”

Slide 46

Slide 46 text

54

Slide 47

Slide 47 text

55 https://www.thoughtworks.com/radar Apr 2021

Slide 48

Slide 48 text

57 Adopt: Platform engineering product teams “We consider platform engineering product teams to be a standard approach and a significant enabler for high-performing IT.” -- ThoughtWorks Tech Radar, Vol.24, p.9

Slide 49

Slide 49 text

60 A valuable platform reduces the cognitive load of stream-aligned teams.

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

“Cognitive load is the total amount of mental effort being used in the working memory” - John Sweller 62

Slide 52

Slide 52 text

Intrinsic (skills) Extraneous (mechanism) Germane (domain focus) 63

Slide 53

Slide 53 text

Intrinsic Extraneous Germane 64 “How do I deploy this app to K8s, again?”

Slide 54

Slide 54 text

(Intrinsic) ] Extraneous [ Germane 65

Slide 55

Slide 55 text

66 extraneous cognitive load for stream-aligned teams germane cognitive load for platform teams →

Slide 56

Slide 56 text

67

Slide 57

Slide 57 text

68

Slide 58

Slide 58 text

69 “Highly evolved firms use a combination of stream-aligned and platform teams as the most effective way to manage cognitive load at scale”

Slide 59

Slide 59 text

teamperature.com 70

Slide 60

Slide 60 text

71

Slide 61

Slide 61 text

72

Slide 62

Slide 62 text

73 We have fully autonomous “build & run” teams Mid perf

Slide 63

Slide 63 text

We have an ecosystem of loosely coupled teams that promotes fast flow & manageable cognitive load 74 High perf

Slide 64

Slide 64 text

Case Study 75 teamtopologies.com/examples

Slide 65

Slide 65 text

76 Flow of change

Slide 66

Slide 66 text

77 Flow of change

Slide 67

Slide 67 text

78 Flow of change

Slide 68

Slide 68 text

79

Slide 69

Slide 69 text

80 We have a platform team that solves common problems for teams Mid perf

Slide 70

Slide 70 text

81 “the existence of a platform team does not inherently unlock higher evolution DevOps”

Slide 71

Slide 71 text

“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.” – Evan Bottcher, 2018 82 Source: https://martinfowler.com/articles/talk-about-platforms.html

Slide 72

Slide 72 text

83 “Successful platform teams treat their platform as a product. They strive to create a compelling value proposition for application teams”

Slide 73

Slide 73 text

But what is “Platform as a Product”? 84

Slide 74

Slide 74 text

85 A (platform as a) product is optional to use - no team is forced to use it

Slide 75

Slide 75 text

“Any time standards, practices, processes, frameworks, or architectures become a mandate, I’ve seen little to no adoption.” - Courtney Kissler 86

Slide 76

Slide 76 text

87 A (platform as a) product is carefully designed and curated for its customers

Slide 77

Slide 77 text

88 A (platform as a) product evolves to take advantage of technology changes

Slide 78

Slide 78 text

89 A (platform as a) product uses modern product management & follows the adoption lifecycle

Slide 79

Slide 79 text

90 Happier users (engineers) No technology bloat Designed for cognitive load

Slide 80

Slide 80 text

91 “[Highly evolved platform teams] understand their internal customers and offer a curated set of technologies for infrastructure and development capabilities”

Slide 81

Slide 81 text

92

Slide 82

Slide 82 text

93 Platform engineering is not replacing DevOps, but rather enabling its goals

Slide 83

Slide 83 text

94 We have a platform team that solves common problems for teams Mid perf

Slide 84

Slide 84 text

We treat the platform as a product, a curated experience for our users 97 High perf

Slide 85

Slide 85 text

Platform as a Product is hard work! 98 ● Metrics are stacked against you ● Customer-centricity mindset takes time ● Trust is hard to gain (esp in remote context) ● Adoption lifecycle = “you’re never done” ● Shared services legacy that doesn’t go away

Slide 86

Slide 86 text

Case Study 99

Slide 87

Slide 87 text

100 “the key to escaping the middle phase is a successful platform team approach, which makes sense given the fact that implementing a platform approach well requires well-defined team responsibilities and interactions”

Slide 88

Slide 88 text

Resources 101 teamtopologies.com/resources (links, slides, video) teamtopologies.com/examples (uSwitch, WealthWizards & more)

Slide 89

Slide 89 text

academy.teamtopologies.com

Slide 90

Slide 90 text

○ Platform Value ○ Platform Customers ○ Platform Experience ○ Platform Adoption Cycle TT25 - Platform as a Product 103

Slide 91

Slide 91 text

Platform Bundle (15% OFF)

Slide 92

Slide 92 text

105 1-day training for platform decision makers “fantastic course with large amounts of insight” “an eye opener on the importance of trust in high performing teams”

Slide 93

Slide 93 text

107 Manuel Pais FlowOnRails Twitter: @manupaisable LinkedIn: manuelpais Matthew Skelton Conflux Twitter: @matthewpskelton LinkedIn: matthewskelton Copyright © Team Topologies Ltd and FlowOnRails 2018-2024. All rights reserved. teamtopologies.com