Agile, Lean, Rugged - The Retrospective

Recapping some of my personal highlights from the recent GOTO London conference, together with a few thoughts of my own and some additional interesting papers...

Transcript

1. Agile, Lean, Rugged The Retrospective @adriancolyer
2. Some personal highlights and ramblings... • Agility ◦ quantifying the benefits ◦ busting some myths ◦ can we explain the disparity? ◦ fighting rigidity • Leanness ◦ the two flavours of lean ◦ value streams ◦ traffic jams • Ruggedness ◦ Rugged Software ◦ Continuous Security
3. Nicole Forsgren & the State of DevOps Survey 30x more frequent deploys 200x faster lead times
4. Correlation, not Contradiction! 60x the change success rate 168x faster MTTR (version control everything)
5. Widening Gap… why is this? • Two orders of magnitude faster feature delivery • The best are pulling away: 2014 2015 change success rate 3x 60x MTTR 48x 168x
6. Does the gap matter? 2x More likely to exceed profitability, market share, & productivity goals 50% Higher market cap growth over 3 years
7. Does the gap matter? [Barry O’Reilly] https://hbr.org/2015/08/productivity-is-soaring-at-top-firms-and-sluggish-everywhere-else
8. O-Ring Theory (Michael Kramer, 1993) • Production depends on completing a series of tasks • Failure of any one task reduces the value of the entire product • You can’t substitute quantity for quality ✓ ✓ ✓
9. The Economic Model • N process steps (workers) • Let q i ∈ [0,1] be the quality level of process step i • Output = N x (q 1 x q 2 x … q N ) N q Output 10 0.99 9.04 10 0.95 5.99 10 0.9 3.49
10. Consequences Source: Mercatus Center weakest link effect: suppose quality level is 0.5 on two steps, 0.99 everywhere else… 10 x 0.52 x 0.998 = 2.3! vs 10 x 0.9910 = 9.04
11. The O-Ring Theory of DevOps • Given a DevOps pipeline of n steps • Let the quality of process step i be: q i = α.%C&A i + β . world-class lead time i [ α + β = 1] lead-time i • Fix N = 100 E(p) = 100 . ᴨ i=1 q i n
12. Some consequences of O-Ring Theory • Small differences in task proficiency compound to significant differences in output • You need to be good (or great!) across the board - one or two weak links make an outsized impact • Proficiency levels tend to normalise across tasks within an org More on today’s #themorningpaper… (http://blog.acolyer.org)
13. Fighting Rigidity
14. Advice from the Robotics Community
15. API Agility “If you notice that a particular interface is starting to rival in complexity the components its connects, then either the interface needs to be rethought or the decomposition of the system needs redoing.”
16. Data Agility
17. Configuration Agility “agile configuration management enables agile software development…”
18. Leanness
19. Feedback cycles Get Inside!
20. Value Streams • Lead Time • Process Time • %Complete and Accurate (%C&A)
21. Phil Calçado http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html
22. Phil Calçado
23. Unique business value-adding activities? Source: http://nextbigfuture. com/2008/07/high-temperature- thermoelectric-at-zt.html
24. Blocked Pipes & Traffic Jams Trying to take on too much at once.
25. The Power of Focus [Karen Martin] • Before focusing: 24 deployments in one year • After focusing: 73 deployments in one year With: - No additional resources - Higher quality output - & less stress!
26. Ruggedness
27. Rugged Manifesto [Josh Corman] “… I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security. I recognize these things – and I choose to be rugged. I am rugged because I refuse to be a source of vulnerability or weakness…” https://www.ruggedsoftware.org/
28. Continuous Security [James Wickett] • Agile + DevOps + Continuous Delivery -> (Traditional) Security Fail! • Need to integrate security: Rugged DevOps / DevSecOps / … Pro tips from James: 1. Automate security tooling to run in testing 2. Put security testing in your CI system 3. Add application security telemetry to dev and ops 4. Add hardening and audit using config management hardening.io guantlt
29. Fail at Scale http://queue.acm.org/detail.cfm?id=2839461 Three easy ways to cause an incident: 1. Configuration changes 2. Hard dependencies on core services 3. Increased latency and resource exhaustion
30. What were your favourite moments? • Agility ◦ quantifying the benefits ◦ busting some myths ◦ can we explain the disparity? ◦ fighting rigidity • Leanness ◦ the two flavours of lean ◦ value streams ◦ traffic jams • Ruggedness ◦ Rugged Software ◦ Continuous Security