So what is DevOps anyway?

Those of you in software development probably already know the answer to this. I thought I did too. Then I found out I was wrong. [blog.mindrocketnow.com]

First the academic answer: according to https://aws.amazon.com/devops/what-is-devops/ 

DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity

So far so vague. Deliveroo also has a high velocity delivery service. Perhaps a better description of DevOps behaviours is from https://tnw.to/gT0J2  

DevOps aims to close the gap between what the client ordered and what the development team has delivered. There is an emphasis on short release cycles, iterative approach to design, and automation of repetitive steps. 

Which sounds a lot like Agile, doesn’t it? Like many, I thought that Agile was a way of aligning Product and Engineering together into one happily productive team, and DevOps extended this to include Validation and Operations. The promise of DevOps is by having one bigger happy team of Product Owners, Developers, Testers and Infrastructure Operations Engineers, we can get to safely deploying every minute, instantly measuring how much delight we’re giving our customers in real-time.

I have yet to see this harmony in my experience. Instead, I’ve seen that Agile Transformation turns out to be a power struggle between Product and Engineering, and DevOps extends the blast radius to include Operations. I’ve always thought that the conflict arises from a fundamental conflation of people’s roles as contributors to an outcome (“squads”) versus their role as being a subject matter expert (“tribes”). The former is how to build your MacGuffin as best as you can to address the market need, whereas the latter deals with ensuring your resources are what you need. 

Moreover, organisations are normally oriented around the latter, as only senior people are allowed to spend money = hiring and authorising budgets. Delivery teams are formed as a “matrix” with no line management accountability, and executives who should be resource managers instead become points of escalation for the products, because that’s where the action is. This will only work if there’s a strong common vision of what good likes. If not, you have people up and down the food chain trying to balance what’s good for the product versus what’s good for their line management within their own heads, which inevitably causes cognitive dissonance. 

The closest I experienced a true alignment between the organisation functions was when I was running both an ops and an engineering team concurrently, and I myself represented the product (an ops tool for assuring content through the media supply chain). It was a small team, but it achieved remarkable results. Looking back, I think it was effective because the close collaboration between Product, Engineering, Testing and Operations got us to the point that we had a very short distance between defining changes in theory and measuring success in the market (and using the learnings to define the next set of changes).

DevOps defines how that close collaborative culture should work. It’s a mindset, not a toolset. It’s not about deploying automation, but understanding how automation shortens the distance from change to market. It’s not about the Head of Product owning everything, but the product team empowered to own everything. So here’s my current definition:

DevOps is a codified culture of collaboration between Market, Product, Engineering, Testing and Operations.

I’ll continue working on this definition as I continue living it. 

What are your experiences of living the DevOps culture? Write to me in the comments.