Key Takeaways from Continuous Discussions (#c9d9) Episode 73 – The 2017 State of DevOps Report
In a special edition of our Continuous Discussions (#c9d9) video podcast, we were joined by expert panelists to discuss the 2017 State of DevOps Report findings . Our panel included: Topo Pal, director and platform engineering fellow at Capital One; Mark Imbriaco , DevOps strategist at Pivotal; Nicole Forsgren, CEO and chief scientist at DORA; and, our very own Anders Wallgren and Sam Fell . During the episode, Pal, Imbriaco, Fell and Wallgren asked Forsgren, one of the 2017 State of DevOps Report authors, questions about the report findings and discussed some of their favorite takeaways. Continue reading for their full insights!
Transformational Leadership, Automation and Regulation
It turns out if you are in bottom 1/3 for transformational leadership, you are less likely to be a high performer - @markimbriaco #c9d9 pic.twitter.com/gDqKcQi3My
— CloudBees (@electriccloud) July 12, 2017
Leaders don't do the transformation themselves, but they have an amplification effect of all #tech & tooling @nicolefv #c9d9 #StateofDevOps pic.twitter.com/94zIFWOGJi
— CloudBees (@electriccloud) July 12, 2017
Transformational leaders have an amplification effect on the positive processes, culture and tooling in a high-performing organization, per Forsgren : “Leaders aren't the ones doing the work, but they can inspire their teams. They amplify the effects of all of the tooling, technology and automation.”
Imbriaco on one of the findings he found most compelling: “The whole notion that you can be successful with these DevOps transformations starting at the bottom and working up is not necessarily true. You can, but it turns out if you're in the bottom third for transformational leadership you're less than half as likely to have high IT performance.”
You need a different strategy for DevOps, advises Wallgren : “You're not going to get very far if you just want to have your DevOps strategy the way you had your cloud strategy and all the other strategies that you need.”
Forsgren on a key differentiator of innovative companies: “The very best, most innovative companies always want to be benchmarked against the entire industry. Those companies don't make excuses, they just get better. They take a look at key outcomes, variables and capabilities, and they find creative ways to pivot.”
It becomes easier to find bottlenecks once you start doing automation, says Fell : “As you start to get things more automated and you start to look at the value stream, things that take a week or even a day are sore thumbs once you start to get a little bit of automation going.”
We started doing DevOps so that we could get fast, explains Imbriaco : “We started doing DevOps in the first place because we got better at building apps and we couldn't deploy them fast enough. As you unpack that workflow even more and you get better at everything else, the places that are struggling get attention.”
Speed and Stability
Low performers are having to make trade-offs so they are pushing the speed boundary, and it's not going well @nicolefv #c9d9 #StateofDevOps pic.twitter.com/SKxJDiDqmi
— CloudBees (@electriccloud) July 12, 2017
If we can deliver high speed, #MTTR goes down - what @TopoPal sees going on | #c9d9 #StateofDevOps #DevOps pic.twitter.com/cgaXDVYt9E
— CloudBees (@electriccloud) July 12, 2017
People get excited w/ a few quick wins, then they hit product architecture which is the ski slope you have to walk up @anders_wallgren #c9d9 pic.twitter.com/LaHrDpnZtf
— CloudBees (@electriccloud) July 12, 2017
Low performers are sacrificing stability for speed, explains Forsgren : “We see a decrease in the comparison value for high performers versus low performers because the low performers are finally catching up a little bit in speed, but we're seeing an increase in that comparison value for the stability metrics because the low performers just can't keep up. They're not coming to DevOps.”
An interesting State of DevOps Report finding from Imbriaco : “One of the things that struck me when I was reading the report was that medium performers and low performers deploy at roughly the same kind of rate. It's weekly to monthly. But medium performers actually do worse in terms of the amount of manual work that they do compared to low performers.”
Pal on the correlation between speed and Mean Time to Recovery (MTTR): “What we have seen is that if we can deliver at high speed, your MTTR actually goes down because if there's a bug you can roll back faster. That's your MTTR in an automated fashion.”
Forsgren notes the five main things you should be doing: “There's a core foundation of things that you need be doing: virtual control, test automation, deployment automation, shifting left on security and having an automated change control process.”
Wallgren : “At some point, there's going to be some sort of a backlash against DevOps. We're going to see enough people fail or at least get stalled, and then turn around and blame DevOps for the problem rather than themselves.”
Both high and low performers will need to focus on improving the automation of their change control processes, per Imbriaco : “High performers report 52 of their change control processes is automated, that's it, 52. Low performers, 41. The gap is not particularly wide there.”
De-Coupling, Lean and Organizational Design
"You can't be doing #DevOps without Ops" @nicolefv #c9d9 #StateofDevOps pic.twitter.com/1RaRIYdShY
— CloudBees (@electriccloud) July 12, 2017
Enablement teams are huge and is one of the gaps between high performers vs. low performers @markimbriaco #c9d9 #StateofDevOps #DevOps pic.twitter.com/VvKUz8ZdGw
— CloudBees (@electriccloud) July 12, 2017
Wallgren on how to get a DevOps transformation to uptick in a large organization: “We're seeing lots of success working closely with product teams. Once you get that win, once you get a couple teams on board, the pace picks up and the adoption of this internal product grows. If it doesn't grow pretty quickly then it usually will wither on the vine because it's not providing any value to people.”
Forsgren details findings on the benefits of loosely coupled architecture: “What we found is that when we have a loosely coupled architecture, teams can easily deploy a service. You don't have to coordinate with 10 different groups or get permission from outside the team. It really drives your ability to practice continuous delivery.”
Having an enablement team brings a lot of value to an organization, says Imbriaco : “There's a lot value in having a team that's focused on enablement across the org and that can work with these teams and bring back patterns and codify those patterns across the organization.”
Advice from Forsgren : “You need to trust your teams to be making their own decisions, and then supporting their own decisions.”
Imbriaco comments on one of the report findings on empowered teams: “’Empowered teams that make their own tool decisions and implementations contribute to better IT performance. It's the implementation part of it that I struggled with a little bit. I can believe it over a short timescale, but if teams continually make their own decisions and go off the beaten path without a really strong reason, they build themselves a mountain of additional code and services that they have to maintain.”
Watch the full episode:
Want more Continuous Discussions (#c9d9)?
We hold our #c9d9 podcast every other Tuesday at 10 a.m. PST. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.