Secrets and surprises of high performance: What the data says
•Download as PPTX, PDF•
6 likes•1,843 views
This document summarizes the key findings from a presentation on high performing DevOps teams. It discusses that while technology itself may not matter, factors like frequent deployment, cooperation between dev and ops, culture and processes are important. Data shows high performing teams deploy code 46x more frequently and have much faster lead times. These teams also have much higher reliability and lower failure rates. Adopting DevOps practices correlates with better meeting organizational goals, higher customer satisfaction, and improved employee satisfaction. The document cautions against relying on maturity models and argues that architecture is more important than the specific technology stack. It advocates for using data and science to continuously improve practices to better the work experience.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Secrets and surprises of high performance: What the data says
Similar to Secrets and surprises of high performance: What the data says (20)
More from Nicole Forsgren
More from Nicole Forsgren (7)
Recently uploaded
Recently uploaded (20)
Secrets and surprises of high performance: What the data says
- 1. @nicolefv Secrets and Surprises of High Performance: What the Data Says Nicole Forsgren, PhD
- 2. @nicolefv
- 3. @nicolefv
- 4. @nicolefv “IT doesn’t matter.” -- Nicholas Carr, 2003
- 5. @nicolefv “IT doesn’t matter.” -- Nicholas Carr, 2003
- 7. @nicolefv
- 8. @nicolefv You’re doing it wrong. There is no ”DevOps in a box”
- 9. @nicolefv 10 Deploys per day Dev & ops cooperation at Flickr John Allspaw & Paul Hammond Velocity 2009 @nicolefv
- 10. @nicolefv DevOps is Technical Practices and Lean Processes and Culture These drive performance outcomes @nicolefv https://www.flickr.com/photos/152950521@N07/37622864031
- 11. @nicolefv But intuition falls short So we need data @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 12. @nicolefv@nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/ DevOps is good for Technology Software delivery performance - Deploy frequency (when business demands) - Lead Time for Changes - Mean Time to Recover (MTTR) - Change Fail Rate
- 13. @nicolefv High Performing DevOps teams More agile More frequent Code deployments 46x That’s the difference between multiple times per day and once a week or less. Faster lead time from commit to deploy 440x That’s the difference between less than an hour and more than a week. @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 14. @nicolefv High Performing DevOps teams More reliable Faster mean time to recover from downtime 96x That means high performers recover in less than an hour instead of several days As likely that changes will fail 1/5x That means high performer’s changes fail 0-15% of the time, compared to 31-45% of the time. @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 15. @nicolefv DevOps is good for organizations @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 16. @nicolefv High Performing tech organizations are twice as likely to meet or exceed Commercial Goals • Productivity • Profitability • Market Share • # of customers 2x @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 17. @nicolefv High Performing tech organizations are twice as likely to meet or exceed Commercial Goals • Productivity • Profitability • Market Share • # of customers Non-commercial Goals • Quantity of products or services • Operating efficiency • Customer satisfaction • Quality of products or services • Achieving organizational or mission goals 2x @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 18. @nicolefv High Performing tech organizations are twice as likely to meet or exceed Commercial Goals • Productivity • Profitability • Market Share • # of customers Non-commercial Goals • Quantity of products or services • Operating efficiency • Customer satisfaction • Quality of products or services • Achieving organizational or mission goals 50% Higher market cap growth over 3 years 2x @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 19. @nicolefv Software Delivery Performance is comprised of throughput and stability, and both are possible without tradeoffs @nicolefv@nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 20. @nicolefv How do we get there? @nicolefv https://www.flickr.com/photos/fantascapes/4530372648
- 23. @nicolefv Maturity models are for CHUMPS @nicolefv
- 24. @nicolefv Maturity models are for CHUMPS @nicolefv
- 25. @nicolefv@nicolefv https://www.flickr.com/photos/nanpalmero/9313659376 Maturity models tell us we are done once we reach a certain destination… and then the world passes us by
- 26. @nicolefv Maturity models tell us (and leaders) to stop dedicating resources once we have arrived. @nicolefv https://www.flickr.com/photos/volvob12b/9988822123/
- 27. @nicolefv Maturity models tell us we all follow the same path to success @nicolefv https://www.flickr.com/photos/mortaupat/6410006785
- 28. @nicolefv Maturity models tell us technology is a checklist to be completed and not an exciting journey to continually explore and improve. @nicolefv https://www.flickr.com/photos/pebb/42467336382
- 30. @nicolefv Technology stack doesn’t matter •Low performers are more likely to: • be working with outsourced software • be working on a mainframe system BUT • Working on a mainframe system was not correlated with performance. • Working on greenfield or brownfield (or any other system) was not correlated with performance, either. @nicolefv https://www.flickr.com/photos/serenasoftware/3288275568
- 31. @nicolefv Architectural outcomes matter Can my team •Change the design of its system •Test the system •Deploy the system ... without communication and coordination with people outside the team? @nicolefv https://commons.wikimedia.org/wiki/File:BalticServers_data_center.jpg
- 32. @nicolefv Conway’s Law “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
- 33. @nicolefv We can make work better
- 34. @nicolefv
- 35. @nicolefv Smart investments in tech and practices make our work better •The work? •Less deployment pain •Less burnout •Higher employee Net Promoter Score @nicolefv https://www.flickr.com/photos/151876933@N04/38992268995/
- 36. @nicolefv Microsoft Engineering Thiago Almeida -- DevOps Days London, 2016 Work/Life Scores Before CD: 38% After CD: 75% https://vimeo.com/165184757
- 37. @nicolefv Employees in high performing organizations are 2.2 times more likely to recommend their organization as a great place to work @nicolefv https://www.flickr.com/photos/thomashawk/17383831292
- 38. @nicolefv Some of my other favorite misconceptions Some of my other favorite data findings!
- 39. @nicolefv Some of my other favorite misconceptions Some of my other favorite data findings! • Change advisory boards are useless* • Integration times and branch lifetimes lasting hours are better than days
- 41. @nicolefv Some of my other favorite misconceptions Intuition is good, but we need to confirm with data & science bit.ly/DORA-ASODR
- 42. @nicolefv TL;DR •Technology matters •Maturity models don’t work •Architecture > technology •We can make work better •You can help! bit.ly/DORA-ASODR
Editor's Notes
- I just wrote a book called Accelerate. It summarizes 4 years of research. But WHYYYYYY? I don’t like writing. I’d much rather sit around drinking Diet Coke.
- Our story begins with Harvard Business Review. BUT WHAT IS HARVARD BUSINESS REVIEW? HBR is a magazine that managers and executives read that presents research in an short, easy-to-read format. This is where management gets all of their ideas from.
- In the year of our lord 2003, Nicholar Carr wrote an article TITLED Who is Nicholas Carr? He is a Pulitzer Prize nominated writer. So his ideas count even more!
- Well, this idea can die in a fire. IT, and technology, DOES matter. But we need more than stories and intuition to tell us that. We need data. We need proof to tell management so that we can get our work and our initiatives funded.
- So let’s get started. After working in tech and building systems, I pivoted to research. I’ve been digging into data on tech impacts for a decade, and studying DevOps for four years.
- That whole “IT doesn’t matter” thing? Nicholas Carr had a point. He was making his case based on the way companies were doing tech in the 80s and 90s. …
- … but I don’t believe you OR … but I’m not going to invest in it. What good does it do for me? OR … why should I care?
- b/c if we don’t invest the right way, it’s a missed opportunity
- Data backs our intuition… it’s factual
- Okay… but “SO WHAT?”??”
- This is important, and something that we could only verify with data. Our intuition told us this was possible. But others have told us it wasn’t so. Who here works in highly regulated fields, or government? ITIL and groups in Europe have said for over a decade that we have to slow down to be safe and stable. Four years of data show that this isn’t the case at all. High performers… IN FACT.. It might be the opposite.
- But… how are we going to get there?
- Let me explain to you: Maturity Models. These are a rubric, invented by someone, that explain how to go from sucking at technology, to being amazing at technology.
- At one point, World of Warcraft came out and Level 60 was amazing and as high as you could go. A Level 60 mage or warlock was awesome and it was freaking HARD to get there. So this was a serious GOAL. So if you use a maturity model…. 40 is moderate, 50 is super high, 60 is epic. And once you achieve this, you are amazing and you are set. (go)
- OH WAIT. Except the world changed. The competition changed…. And now you can get to level 110. Suddenly being a Level 60 just isn't’ very cool anymore, and frankly, it isn’t good enough. Technology is the same way. And so is business. The best, most innovative companies know this. Their competition is getting better, the world is changing, and customers demand more. So instead of picking a destination, like in a maturity model, they point in a a direction, As engineers, we know that abstractions never fully map to the world.
- MORE fun things we found in the data that debunked myths!
- Change approvals OTHER – days of time to have branch active We can only do this with data. With math, we need a proof Intuition is great, but we need to know for sure. You’re a part of this thing
- We can only do this with data. With math, we need a proof Intuition is great, but we need to know for sure. You’re a part of this thing
- Change approvals OTHER – days of time to have branch active We can only do this with data. With math, we need a proof Intuition is great, but we need to know for sure. You’re a part of this thing