As a DevOps Lead for Equal Experts, I split my time between working hands-on within a team on a specific delivery and visiting our other teams on various engagements.

That means I have a broad view of how DevOps can help – or hinder – our ability to deliver valuable software for our clients.

At a recent review of our DevOps work, our co-founder Thomas summarised the current state of DevOps in the industry:

“Not everyone agrees on what DevOps means, who does it, or how it’s done. There are many ways to do it depending on the context. People sometimes forget that DevOps is part of something bigger called Continuous Delivery”

My own recent experience showed this to be the case, when at the end of 2016 I signed up to work on an engagement abroad. The client had specifically asked for a DevOps Lead to work on the project as part of the original bidding process.

I was soon on a plane heading for the engagement, and duly started work. But as I became more familiar with the project, I didn’t feel a DevOps Lead was the right fit for the challenges we faced. I thought that a developer experienced in release engineering would be a better fit, and suggested as much. However, the client firmly believed DevOps was necessary to the project’s success.

Over the next few days we talked with the client about their delivery needs, and we identified a DevOps consultant who could coach a developer in release engineering. This was a positive outcome, and the team soon began to deliver new features on a regular basis.

Nevertheless, the episode identified three problems that tie into Thomas’ comments above:

1. Clients have been led to believe they must “do DevOps”
2. It’s hard to find good DevOps practitioners
3. There are different views on what DevOps actually is

So, how did we get here?

A brief history of DevOps

I started out in IT as a developer, but I’ve always been interested in operations and was super-excited when Patrick Debois announced the first DevOpsDays conference and coined the term #devops in 2009. I bought into the idea of a cultural movement that emphasised collaboration between development and operations teams.

By the time The Phoenix Project (Gene Kim, Kevin Behr, George Spafford, 2013) was published , I was working in operations and pairing with developers on different clients. When The DevOps Handbook  (Gene Kim, Jez Humble, Patrick Debois, John Willis) was published in 2016 I was in my current role with Equal Experts, and encouraging the DevOps principles and practices mentioned in The DevOps Handbook.

The DevOps Handbook is an awesome book, and I highly recommend it… but the seven years between the start of the practise and the arrival of the DevOps Handbook is an awfully long time. Unfortunately the IT industry is now full of roles such as “DevOps Engineer” and “DevOps Team”; it’s gone in a completely different direction to the recommendations made in the book.

DevOps is a constraint

At Equal Experts we’ve come to realise that DevOps has become a constraint on our ability to deliver software to our clients, due to the problems I mentioned above. A quick reminder:

1. Clients have been led to believe they must “do DevOps”
2. It’s hard to find good DevOps practitioners
3. There are different views on what DevOps actually is

Together, these problems form a constraint on our Sales team, our People team, and our delivery teams.

While a Request For Proposal (RFP) from a prospective client may ask for DevOps upfront, as the example I’ve mentioned shows, a preoccupation with a particular role can slow the team down once we’re onsite.

To battle this constraint we try to recruit DevOps consultants as a specialist position (though it can be a challenge to find people with the necessary skills, experience and focus on client delivery). We also encourage a shared understanding of DevOps across all our client engagements. But it’s all too easy to get caught up in wasteful debates on what DevOps is and how to do it. This is not a sustainable situation.

So where next for DevOps?

At Equal Experts we’ve always taken pride in thinking differently about how to deliver the best possible solutions for our clients. Now it’s time for us to think differently about DevOps.

We want to go beyond the DevOps buzzword, and use the best parts of the DevOps philosophy to improve how we work with our clients. In other words we want to turn our DevOps constraint into an opportunity – for Equal Experts and our clients.

This is the first article in a new multi-author series “Beyond DevOps”, which aims to explore DevOps and Continuous Delivery – and how they affect our culture and work. In the next part, we’ll be looking into Operability – the aspect of the DevOps philosophy we see as a vital enabler of Continuous Delivery. Keep an eye on the blog or follow us on Twitter for the latest updates.

 

1.  DevOps as a Constraint (you are here!)
2. The value of Operability 
3. DevOps is just a conversation starter
4. Looking for DevOps/Operability Engineers
5. Operability for a Platform-as-a-Service