Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The astonishing value of speed

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 discusses what "going fast" in terms of accelerating IT means. Then, it discusses why this kind of delivery speed is essential in post-industrial markets. Afterwards, more advantages are discussed that are also relevant if not living in a post-industrial market. Finally, the advantages are summarized.

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

E698a765c9d04ae52d5e1815b2007cfe?s=128

Uwe Friedrichsen

May 04, 2021
Tweet

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. Cycle times * Deployment frequency * Time from a new

    idea until the customer experiences its implementation and can provide feedback
  7. With “fast” I refer to cycle times Deployment frequency simply

    must not compromise cycle times
  8. What do you mean with “going fast”? How fast is

    “fast”?
  9. 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
  10. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 18

  11. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 20

  12. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 21

  13. We don’t need it

  14. What about post-industrial markets?

  15. Post-what?

  16. 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
  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”. Pre-industrial era Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13 Tailor-made solutions Mastery is key to success
  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”. 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
  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”. 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
  20. 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
  21. 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.
  22. What does that have to do with IT?

  23. 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
  24. The role of IT today

  25. 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
  26. You cannot change anything in your business without touching IT.

    IT delimits how fast you can get feedback from your customers.
  27. Today, business and IT are the same side of the

    the same coin. The other side is the market.
  28. But my market is not post-industrial

  29. There is still huge value

  30. Higher organizational performance https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 5

  31. Better work/life balance, reductions in burnout https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 6

  32. Improves stability, reduces burnout https://services.google.com/fh/files/misc/state-of-devops-2019.pdf, p. 6

  33. 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.
  34. Still not convinced …

  35. There are even more advantages

  36. 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
  37. 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
  38. Valueless routines, ends in themselves, bloated procedures and alike do

    not mix with short cycle times
  39. 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
  40. 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
  41. 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
  42. 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
  43. Most configuration options are only needed due to long lead

    times
  44. What if lead times were shorter than needed change delivery

    timespan?
  45. 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
  46. 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
  47. 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
  48. 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
  49. What if you could implement requests so fast that you

    do not need to manage a huge request backlog?
  50. 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
  51. Project overheads • Saves money, makes you faster, reduces stress

  52. 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”
  53. Project A Project B Project C Maintenance Senior Engineer Junior

    Engineer Ops Expert
  54. Now a serious production error occurs …

  55. Project A Project B Project C Maintenance Senior Engineer Junior

    Engineer Ops Expert Hey, we’ve got a serious production problem here!
  56. 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.
  57. Thus, an “emergency task force” is set up

  58. 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
  59. Meanwhile …

  60. 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
  61. 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.
  62. Now, assume an IT organization with intraday cycle times

  63. 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.
  64. Now a serious production error occurs …

  65. 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!
  66. 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!
  67. 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
  68. Meanwhile …

  69. 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.
  70. 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
  71. 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
  72. t Specify the new system!

  73. t What could be needed for the new system? ?

    ? ? ? ? ?
  74. 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
  75. t Do you really have everything in it? Remember: We

    only have that one shot!
  76. t

  77. t Budgeting

  78. t Approval

  79. t Implementation

  80. t Deployment

  81. t That’s not what I need!

  82. Now, assume an organization with intraday cycle times

  83. < 1d

  84. < 1d

  85. 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
  86. 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
  87. Do you still think you do not need it?

  88. Is there really a different path worth following?

  89. Summing up

  90. 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
  91. 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 • …
  92. There is no sensible alternative to going fast

  93. What are you waiting for?

  94. Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/blog/value_of_speed/