The astonishing value of speed

This slide deck discusses the potential advantages of accelerating the cycle times of the IT value chain (from a business idea until the user sees it in the respective application and can provide feedback) and the deployment frequency to production.

First, it clarifies what "going fast" in terms of accelerating IT means - that it does not mean running the widespread rat race faster, but shortening cycle times which is a completely different story and has significantly different effects.

Then, it discusses why this kind of delivery speed is essential in post-industrial markets. Afterwards, more advantages relating human wellbeing, stress reduction, options for process and organization simplification, creating more value with less effort, tackling the shortage of IT talent and more are discussed - which are also relevant if not living in a post-industrial market.

Finally, the advantages and options not being available without short cycle times are summarized.

As always the voice track is missing. Still, I hope that the deck contains some interesting ideas for you ...

Transcript

1. The astonishing value of speed Why you cannot afford not to go fast in IT Uwe Friedrichsen – codecentric AG – 2013-2021
2. Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/blog/value_of_speed/
3. Going fast
4. What do you mean with “going fast”? How fast is “fast”?
5. What do you mean with “going fast”? How fast is “fast”?
6. Features / Unit of time
7. Cycle times * Deployment frequency * Time from a new idea until the customer experiences its implementation and can provide feedback
8. With “fast” I refer to cycle times Deployment frequency simply must not compromise cycle times
9. What do you mean with “going fast”? How fast is “fast”?
10. With “fast” I mean the delivery speed (and quality) of the elite performers of the State of DevOps (*) report (*) https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
11. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 18
12. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 20
13. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 21
14. We don’t need it
15. What about post-industrial markets?
16. Post-what?
17. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamic high dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t 1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. The “bathtub” curve Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
18. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamic high dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t 1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Pre-industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Tailor-made solutions Mastery is key to success
19. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamic high dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t 1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Cost-efficiently scale production Getting more done with less people is key to success
20. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamic high dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t 1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Post-industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Continuously respond to changing demands Continuous market adaption is key to success
21. Industrial Post-industrial Dictated by Supplier Driven by Consumer Market development Demand >> Supply Supply >> Demand Demand-Supply Ratio High Low Success certainty Long Short Refinancing period Market characteristics Wide, sluggish Narrow, fast Cost-efficiency & scale Fast feedback & adaptability Preferred strategy
22. In post-industrial markets not those survive who produce as cost-efficiently as possible, but those who adapt to the ever-changing needs and demands of the customers faster than their competitors. This requires fast feedback loops with your customers.
23. What does that have to do with IT?
24. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (Business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT
25. IT has changed a lot over the decades ...
26. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (Business processes) Highly complex (Business nervous system) Software crisis PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT Software engineering ... but still we strive to control our IT of today ... ... based on the concepts we developed for an IT almost 50 years ago
27. Formal part of value creation Solution: machine Dynamic part of value creation Solution: man sluggishness/low dynamic high dynamic high dynamic The historical course of market dynamics and the recent rise of highly dynamic and complex markets The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact. t 1970/80 today Age of crafts manu- facturing Age of tayloristic industry Age of global markets 1850/1900 Spacious markets, little competition Local markets, high customi- zation Outperformers exercise market pressure over conventional companies We call the graph shown here the “Taylor Bathtub”. Remember the “bathtub” curve? Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
28. 1960 1970 1980 1990 2000 2010 2020 Complicated (Business functions) Complex (Business processes) Highly complex (Business nervous system) Software crisis Software engineering PC LAN Internet Business Support of IT Selective Holistic Complicated Complex “Moore’s law” Mobile IoT Also the business we support with IT today ... ... is very different from the business we supported back then
29. The role of IT today
30. The role of IT • Nervous system of the business • Enabler of (disruptive) new business models • Integral part of the business model (“digital transformation”) • Medium for the continuous customer communication
31. You cannot change anything in your business without touching IT. IT delimits how fast you can get feedback from your customers.
32. Today, business and IT are the same side of the the same coin. The other side is the market.
33. But my market is not post-industrial
34. There is still huge value
35. Higher organizational performance https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 5
36. Better work/life balance, reductions in burnout https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 6
37. Improves stability, reduces burnout https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 6
38. Shorter cycle times do not lead to more stress and chaos, but on the contrary to less stress and higher performance. This alone should be worth aiming for short cycle times.
39. Still not convinced …
40. There are even more advantages
41. Cutting off manual tasks • Short lead times require high degree of automation • Additional effects of rigorous automation • Less errors happen • People are happier • More capacity for valuable work • Get more done with the same – happier – people • Saves money, improves productivity and robustness
42. Simplifying tasks • Aiming for short cycle times ruthlessly points out waste • Makes visible if a task has become an end in itself, e.g. • Bloated requirements validation processes • Complex design rules from the ivory tower • Documentation without a reader • … • Shows the degree of autopoiesis * * In its sociological interpretation by Niklas Luhmann
43. Valueless routines, ends in themselves, bloated procedures and alike do not mix with short cycle times
44. Simplifying tasks • Focus on cycle times means focus on value • Simpler processes • Less useless procedures • Focus on purpose and value, not on routines and habits • Saves money, reduces stress, improves productivity
45. Configuration frenzy • Most applications contain lots of configuration options • Multiple execution paths • Complex decision logic • Additional configuration option management frontends • Additional configuration option storage • Additional logic to access configuration at runtime • Sometimes up to 50% of overall solution complexity
46. Configuration frenzy • Added complexity comes at a price • Code harder to read • Code harder to understand • Code harder to test • Code harder to debug • Changes becomes slower and more expensive • More bugs creep in • Robustness in operations goes down
47. Most configuration options are only needed due to long lead times
48. t Timespan available for delivering change Timespan needed by IT to deliver change Change via configuration options needed due to this time gap Change need detected Change delivery needed at the latest Earliest delivery date via software change
49. What if lead times were shorter than needed change delivery timespan?
50. t Change delivery needed at the latest Timespan available for delivering change Timespan needed by IT to deliver change Configuration options not needed for change delivery Change need detected Delivery date via software change
51. Configuration frenzy • With intraday lead times, most configurations not needed * • Saves time and money, improves robustness * You will not get rid of all configuration options, but you may not need quite a lot of them anymore
52. Project overheads • Long lead times lead to a huge backlog • Requests pile up while organization is busy processing current batch of projects • Simple queue not sufficient to manage amount of requests • Instead, more complex organization needed
53. Project overheads • Requests are bundled in projects to manage backlog • Projects must be defined • Projects must be budgeted • Projects must be prioritized and approved • Projects must be set up and staffed • Projects must be implemented, controlled and readjusted • Huge additional effort • Requires minimum project size • Often reinforcing loop
54. What if you could implement requests so fast that you do not need to manage a huge request backlog?
55. Project overheads • Intraday lead times would dramatically reduce backlog • Much simpler organization would be sufficient • Imagine a big Kanban board for all requests * • Project overheads would disappear • Regular organization sufficient to handle all requests • Business and IT owners would be more relaxed • Stable teams are possible * Usually not that simple, but still simple solutions possible
56. Project overheads • Saves money, makes you faster, reduces stress
57. No “emergency taskforces” needed • Widespread separation between “project” and “maintenance” • “Project” implements new functionality • “Project” typically is organized in long-running projects • “Maintenance” takes care of bugs and small changes • “Maintenance” usually uses a flow-style process • Most experienced engineers usually assigned to “project”
58. Project A Project B Project C Maintenance Senior Engineer Junior Engineer Ops Expert
59. Now a serious production error occurs …
60. Project A Project B Project C Maintenance Senior Engineer Junior Engineer Ops Expert Hey, we’ve got a serious production problem here!
61. Project A Project B Project C Maintenance Senior Engineer Junior Engineer Ops Expert Oh, that’s intricate. We don’t know how to fix it.
62. Thus, an “emergency task force” is set up
63. Project A Project B Project C Maintenance Senior Engineer Junior Engineer Ops Expert Emergency Task Force That’s intricate, indeed. But we can fix it. Coordination & management
64. Meanwhile …
65. Project A Project B Project C Maintenance Senior Engineer Junior Engineer Ops Expert Emergency Task Force Coordination & management Crippled (significantly reduced progress) Crippled (significantly reduced progress) Mostly standing still Mostly standing still Additional overheads
66. Often, these “emergency task forces” run for days and need to be formed on a quite regular base. This means a significant productivity loss, not to mention the stress for all people involved.
67. Now, assume an IT organization with intraday cycle times
68. Senior Engineer Junior Engineer Ops Expert Capability Team 1 Capability Team 2 Capability Team 3 Capability Team 4 Capability Team 6 Capability Team 5 Capability Team 7 Note: This is one possible organization supporting short cycle times. There are a lot more ways to implement an effective organization supporting short cycle times.
69. Now a serious production error occurs …
70. Senior Engineer Junior Engineer Ops Expert Capability Team 1 Capability Team 2 Capability Team 3 Capability Team 4 Capability Team 6 Capability Team 5 Capability Team 7 Whoa, something blew up in production!
71. Senior Engineer Junior Engineer Ops Expert Capability Team 1 Capability Team 2 Capability Team 3 Capability Team 4 Capability Team 6 Capability Team 5 Capability Team 7 Yeah, we need to look into it asap!
72. Senior Engineer Junior Engineer Ops Expert Capability Team 1 Capability Team 2 Capability Team 3 Capability Team 4 Capability Team 6 Capability Team 5 Capability Team 7 Swarming on production issue
73. Meanwhile …
74. Senior Engineer Junior Engineer Ops Expert Capability Team 1 Capability Team 2 Capability Team 3 Capability Team 4 Capability Team 6 Capability Team 5 Capability Team 7 Swarming on production issue No exceptional procedures required. Can be handled using standard process. No exceptional ad hoc organization required. Can be handle by regular organization. Rest of organization not crippled. No exceptional coordination overheads needed.
75. No “emergency taskforces” needed • With intraday lead times, production errors become “just another task” (with a high priority of course) • Saves money, reduces stress, improves productivity
76. Less worthless work • With long lead times, most code is not used * • ~20% frequently used • ~30% rarely used • ~50% not used (often disliked by users) * see, e.g., https://www.martinfowler.com/articles/xp2002.html#BuildOnlyTheFeaturesYouNeed
77. t Specify the new system!
78. t What could be needed for the new system? ? ? ? ? ? ?
79. t I think we need <X> I want <Y> Wait. I’ll do some market research In the future, we might need <Z> Let me ask some more stakeholders
80. t Do you really have everything in it? Remember: We only have that one shot!
81. t
82. t Budgeting
83. t Approval
84. t Implementation
85. t Deployment
86. t That’s not what I need!
87. Now, assume an organization with intraday cycle times
88. < 1d
89. < 1d
90. Less worthless work • Intraday lead times enable fast feedback from users • Allows identifying and cutting off non-successful features • Allows creating more value with a smaller team • Enables outsmarting demographic change • Saves money, makes you faster, increases revenue
91. More flexibility • Companies often aim for better “business agility” without understanding the effects of digital transformation • Business and IT have become inseparable • Business and IT are the same side of the same coin – the other side is the market • IT delimits speed and thus flexibility of your business • Intraday lead times allow for great “business agility” • Improves flexibility, enables increased revenue
92. Do you still think you do not need it?
93. Is there really a different path worth following?
94. Hmm … I’ll think about it
95. Summing up
96. Effects of going fast 1/2 • Essential for highly dynamic, post-industrial markets • Significant cost savings • Simpler, more effective organizations • Higher productivity • Increased robustness of the IT landscape
97. Effects of going fast 2/2 • Higher employee satisfaction (with all its positive effects) • Increased company resilience • Improved business agility • Higher user/customer satisfaction if played right • Relief for the omnipresent shortage of IT experts • …
98. There is no sensible alternative to going fast
99. What are you waiting for?
100. Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/blog/value_of_speed/