Post "Accelerate": Why are we still failing at adopting DevOps in the Enterprise?

Opening keynote for GoTech World Developer's Stage 11 November 2025.

Reflecting on decades of experience working with the largest enterprises around Europe I try to give you my take on why we fail to change anything in the enterprise and give you my take on what to do about it.

https://www.gotech.world/agenda-developers-stage-day1

Transcript

1. Rasmus Lystrøm, GoTech World, 11 November 2025 Post “Accelerate” Why are we still failing at adopting DevOps in the Enterprise?
2. 2018: DevOps works
3. Why does DevOps fail in the Enterprise? Agile Change Digital Transformation Cloud Adoption
4. Melvin Conway: How Do Committees Invent?, 1967 “Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”
5. CEO CFO COO CHRO CMO CIO
6. Heidi Waterhouse: The Devil’s DevOps silo /ˈsaɪ loʊ / noun : a[n enterprise-grade] security device to prevent the accidental transfer of knowledge from one department to another.
7. CEO CFO CHRO COO CMO CIO CTO CISO CCO CQO CTO CIO CDO CSO CDO DevOps Team The C-Suite 2.0
8. “Siloed DevOps”
9. DevOps Department
10. Cloud Center of Excellence (CCoE)
11. Platform Engineering
12. Platform Engineering
13. 80 %
14. The platform is 80% ready for everything
15. Christin Gorman: Why are you making a new platform?, Copenhagen DevFest 2023 “A platform is a set of tools an IT organization makes for itself”
16. me “Platform engineering is not an evolution of DevOps, it’s the consequence of failed DevOps in failed organizations”
17. Meanwhile in platform engineering…
18. Platform Engineering or CCoE exempting themselves from liability “We have a culture [in development] of ‘you build it, you run it’”
19. typeof(Plumbing) != typeof(Carpentry)
20. typeof(Dev) != typeof(Ops)
21. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
24. Scrum Scaled Agile Framework (SAFe®) PRINCE2 Agile® Agile Project Management Project-based funding ITSM and ITIL and Tickets Change Advisory Boards Architecture Review Boards
25. Kerry Buckley: Manifesto for Half-Arsed Agile Software Development We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value: Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact Working software over comprehensive documentation as long as that software is comprehensively documented Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.
26. Andy Hunt, 1/17 Agile “Agile now means, we do half of Scrum poorly and use Jira.”
27. Loose coupling and micro services
28. Prompt: Photo of 10 grumpy old men sitting around a table with enterprise architecture diagrams on boards all around
31. https://www.pexels.com/photo/ fl are-of- fi re-on-wood-with-black-smokes-57461/
32. Help!
33. Interjection
34. https://www.publicdomainpictures.net/en/view-image.php?image=88978&picture=kryptonite
35. Talking about change Planning change Meetings about change Status reports about change Reviews about change Documentation about change Seminars about change Post-it®s about change Everything which is about change but not the actual change
36. Bryan Howard: Not another initiative
37. Take action
38. The bottom-up approach (aka what you can do)
39. Craig Larman: Larman’s Laws of Organizational Behavior “1. Organizations are implicitly optimized to avoid changing the status quo middle- and fi rst-level manager and “specialist” positions & power structures.”
40. powerOf(Forgiveness) > powerOf(Permission)
41. How do we succeed at DevOps?
42. What is DevOps?
43. Donovan Brown, Microsoft “DevOps is the union of people, processes, and products to enable continuous delivery of value to our end users.” DevOps is anything which does that… Patrick Debois, The Godfather of DevOps
44. DevOps is not a tool. DevOps is not a team. DevOps is not a person. DevOps is not a department. DevOps is not someone else.
45. DevOps is an evolution of Agile
46. Principles behind the Agile Manifesto Principle no. 1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
47. Principles behind the Agile Manifesto Principle no. 2: “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
48. Principles behind the Agile Manifesto Principle no. 3: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Several times a day
49. Ask yourself “What is the fi rst thing we need to change to deliver more value sooner?”
50. Ask yourself “Where is the bottleneck?”
52. Eliyahu M. Goldratt as quoted in The Phoenix Project “Any improvements made anywhere besides the bottleneck are an illusion.”
54. Continuous Delivery
55. Implies Continuous Integration
56. Observation from team “Branches live for weeks and code reviews take forever”
57. Who’s doing Scrum (or similar)?
58. Gather
59. Scatter
60. Gather
61. Scatter
62. Integrate
63. Code review request outcome (a)
64. Code review request outcome (b)
65. Blame and fi nger pointing and frowns and it’s all your fault
66. How to fi x Scrum
67. https://store.epicgames.com/es-ES/p/kill-it-with- fi re
68. Continuous Integration -> Trunk Based Development -> Short lived branches (or no branches) -> Automated testing -> Short review cycles -> Pair programming -> Mob (ensemble) programming
69. Mobbing: Four people working to solve a problem One of them is taking notes on a computer Because taking notes is boring, we swap every 15 minutes
70. Mobbing: no more standups, no more scrum masters, no more backlog re fi nement, no more code reviews, no more pull requests 😀
71. Mobbing: Continuous integration Continuous delivery Fever defects Much shorter MTTR Working on what matters Developer productivity Developer happiness 😀 Mobbing implies TDD or BDD
72. Allen Holub, YOW! 2024 Getting Buy-In: Overcoming Larman’s Law
73. Observation from team “All changes requires involvement from multiple teams working on separate backlogs in multiple repositories”
74. Dependency management at scale
75. Requires coordination and testing and meetings
77. Inner source
78. Monorepo
79. ~6,000 developers Johan Abildskov and Jeppe Brønsted: The Secret (Code) of Uber (Engineering) DevOps Days Aarhus 2025
80. ~6,000 microservices Johan Abildskov and Jeppe Brønsted: The Secret (Code) of Uber (Engineering) DevOps Days Aarhus 2025
81. One Git Repository Johan Abildskov and Jeppe Brønsted: The Secret (Code) of Uber (Engineering) DevOps Days Aarhus 2025
82. Huh?
83. Monorepo Demo
84. Monorepo: Code Reusability Easier Collaboration Streamlined Dependency Management Atomic Commits and Releases Improved Testing
85. Observation from team “The build takes 30 minutes (2 hours if we include integration tests”
86. All CI pipelines < 10 minutes or else…
87. All CI pipelines < 5 minutes or else…
88. Daniel Raniz Raneland, DevOps Days Zürich 2025 Pipeline Patterns and Antipatterns - Things your Pipeline Should (Not) Do
89. Observation from team “We spend forever discussing estimates and planning details which always end up being wrong”
90. Estimates are waste https://www.pexels.com/da-dk/foto/128421/ #NoEstimates
91. Observation from team “But management says…”
93. https://www.freepik.com/free-photo/purple-cylinder-podium-pedestal-stage-product-display-background-3d-illustration-empty-display-showroom-presentation-product-placement_38565994.htm
94. Building a platform [to build a product] before you build a product is premature optimization
95. Donald Knuth, 1974 “Premature optimization is the root of all evil.”
96. You’re all di ff erent
97. Focus on the product There are no commonalities No gains from a platform fi rst approach
98. There is a platform already
99. Principles behind the Agile Manifesto Principle no. 10: “Simplicity — the art of maximizing the amount of work not done — is essential.”
100. Build your product in small increments
101. Bottom up total
102. Call to action: Try mob programming for at least a week Move all your code to a monorepo Make builds fast! Stop estimating Build products not platforms
103. The top-down approach (what the CEO and CFO can do)
104. https://commons.wikimedia.org/wiki/File:Elephant%27s_tea_party,_Robur_Tea_Room,_Sydney,_24_March_1939_-_Sam_Hood_(3529604677).jpg
105. AI
106. #nosilverbullet https://indonesian-recipes.com/download/2030-version.html
107. AI is not going to fi x anything!
108. AI chatbots have had no signi fi cant impact on earnings or recorded hours in any occupation. Users report average time savings of 2.8% of work hours. (~100 seconds/hour) https://www.nber.org/papers/w33777
109. Workslop: “AI generated work content that masquerades as good work but lacks the substance to meaningfully advance a given task.” https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity
110. Agile did not fi x anything
111. Digital Transformation did not fi x anything
112. Organizational problem Cultural challenge
113. Peter Drucker, Management consultant, educator, author “Culture eats strategy for breakfast.”
116. Psychological safety does change things!
117. Principles behind the Agile Manifesto Principle no. 5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
118. Stop project-based funding
119. John Gall: General Systemantics – How Systems Work and Especially How They Fail, 1975 “A complex system that works is invariably found to have evolved from a simple system that worked […]” Gall’s Law
120. John Gall: General Systemantics – How Systems Work and Especially How They Fail, 1975 “[…] The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” Gall’s Law
121. Enforce a culture where we: Build small things that work and get them to production. Then extend with more stuff
122. about:siloes
123. High impact requires risk and sacri fi ce and blood and guts and money
124. Principles behind the Agile Manifesto Principle no. 4: “Business people and developers must work together daily throughout the project.”
125. Principles behind the Agile Manifesto Principle no. 6: “The most ef fi cient and effective method of conveying information to and within a development team is face-to-face conversation.”
126. Principles behind the Agile Manifesto Principle no. 11: “The best architectures, requirements, and designs emerge from self-organizing teams.”
127. We must take the fi ght to the CEO
128. Joe Peppard, Professor and Academic Director, Michael Smur fi t Graduate Business School, UCD “It’s Time to Get Rid of the IT Department”
129. Evolve the organization
130. IT Operations / SRE Platform Engineering Development Testing Enterprise Architecture Business Size of siloes not to scale Security
131. Self-managed feature team Bring people together
132. Business Unit A Business Unit B Business Unit C
133. Risky and uncomfortable
134. Robert L. Martin: The Big Lie of Strategic Planning “If you are entirely comfortable with your strategy, there’s a strong chance it isn’t very good.”
135. Rasmus Lystrøm, The Chief Disruptor Chief Cloud Of fi cer at
136. Thank you Blog, slides, SoMe