DevOps is something companies like Amazon and Google were doing even before the term coined. What matters is whether the process gives any result. And that is what I liked about your presentation. You didn’t get into the definitions and theory. Instead, you focussed on what needs to be done and how it impacts. Thank you.
I got the above feedback after I gave my talk to a bunch of senior people at a well-known enterprise. The idea was to “pitch” DevOps, highlighting the need and importance, without going too much into the details about “how” to do it. The assumption here is that, once the team knows something needs a change, they will figure out how to do it.
Here is the summary of the talk.
DevOps Research and Assessment (DORA), by Dr Nicole Forsgren, Jez Humble and Gene Kim, analysed the software delivery performance on two factors:
The research categorised the respondents to three groups, High, Medium and Low. The elite group is a subset of High performers.
High performers have failures too. The difference is the faster identification of issues and deploying fixes.
The research then analysed the factors influence high performers. It is not the people. It is mostly the practices and process that they followed made the difference:
- Lean product development
- Small batches
- Gathering and implementing customer feedback
- Continuous Delivery practices
- Loosely coupled architecture
- Continuous testing, monitoring, observability
- Managing databases in a low-risk manner
- Experimentation culture
Any software team faces broadly two kinds of problems:
- Building something nobody wants
- Not able to release when business demands
Shipping matters, delivering continuously taking customer feedback. Any business should be able to build something sustainable by consistent shipping. And DevOps is about improving fluency in shipping.
Watch Jez Humble speaking about the research here: