If you have a DevOps team, you're doing it RIGHT!

If we are not careful, throwing out the phrase ‘you’re doing it wrong’ is going to drive away the audience we have tried so hard to cultivate.

DevOps Teams - a rather touchy subject in the land of DevOps. Just mentioning this to any of many DevOps enthusiasts will get you a reaction, and probably not the one you were looking for.

I’m a DevOps enthusiast, practitioner, and supporter. I first encountered DevOps in 2005, working for a young company in Amsterdam, and working here was different. The people were different, the culture was different, their way of getting things done I was not used to. The phrase ‘DevOps’ did not even exist, yet this is exactly how they were working. Instead of layers of management, they had in place a great team of extremely bright people. People who were, for the most part, all “full stack”. All working together, communicating openly, trying new things, automating wherever possible and always looking to improve upon what was done. I’ve been working DevOps ever since.

Back in 2012 some old friends and ex-colleagues began working on something that would soon become known as DevOpsDays Amsterdam. DevOpsDays is a worldwide series of technical conferences covering topics of software development, IT infrastructure operations, and the intersection between them. Each event is run by volunteers from the local area.

I’ve been attending the DevOpsDays event in Amsterdam since its inception almost 8 years ago, and I keep a keen eye on other conferences around the world (Twitter is your friend). Lately I’ve noticed a less than positive trend which I firmly believe is doing more harm than good. Its a trend that leans towards negativity and telling people that they’re wrong. At a lot of these gatherings, there is the powerpoint slide which inevitably ends up on the screen proclaiming something like:

A quick Google search will reward you with a wealth of opinion pieces on how you are doing something in DevOps wrong, and most of these like to pick on the DevOps Teams angle. (the other half focuses on the No DevOps Engineers angle, which is also false in my opinion). It’s as if the writer has read the DevOps specification manual and is now qualified to instruct you on exactly how to do things. Fortunately, such a specification manual does not exist, so I’m not sure where they are getting their information from.

At the majority of conferences that I attend or follow, more than 50% of the audience are first-time attendees. This relates to my preference for community-driven discussions as opposed to the commercially-driven variant (more on this another time). The attendees at DevOpsDays are involved in DevOps in one way or another. They are in development or operations, or they are a project manager or a UX designer. Their company is starting a DevOps transformation, or they have been put together on a project. A good chunk has been doing DevOps for some years. The common thread between them all is that they attend to learn, to understand, to bring their experiences, to ask questions and hopefully get some answers.

Responding to their questions with ‘You’re doing it wrong’ is quite a negative thing to take away. After listening to the speakers and talking to people and enjoying being part of the community, they return to their place of work with a primary thought in their head - OMG, we’re doing it wrong.

From my point of view, these types of statements are the ‘doing it wrong’ component. DevOps has never been prescriptive, nor will it ever be. There is no specification on ‘How to Devops.’ There is no rule book. There certainly aren’t multi-day certification requirements that cost thousands of Euros to become a ‘Devops Master.’

“Imagine DevOps would have been prescriptive - we’d have all these discussions like ‘You are not following the DevOps specification…”

God bless Patrick Dubois, who recently picked up on a post on Twitter stating precisely the above. Pro tip - If you are not familiar with Patrick, and you’re getting into DevOps, you should make yourself familiar with him. You can find him here.

His reply to the post went like this:

“Statements like ‘if you have a DevOps team, you’re doing it wrong’ are not very helpful, even rude; At the very least, it’s not the best conversation starter….#devopsIsHereToHelpNotJudge."

And Patrick has hit the nail right on the head here. There are many companies where it is simply impossible to turn the entire organization on a dime. Failure is not an acceptable outcome, yet failure is supposed to be a feature in DevOps. Transforming into a DevOps shop can take considerable time, considerable experimentation, some learning (and un-learning) and a lot of change. For a lot of people, this is a scary experience - DevOps is moving their cheese, and they don’t like that. Adapting to a new culture and way of working is a massive undertaking. But they try. Let them try and fail and learn from their mistakes and try again.

Doing things differently is not necessarily doing them wrong. As an example, during a recent project that I worked on, the DevOps Team took the conscious decision to drop story pointing during sprint planning. I can hear the Agile perfectionists already. Why did we do this? Because it consumed too much valuable time. This team had been together for more than a year, and they were all ‘Agile Experienced.’ We knew how much we could put into a sprint, we knew what was necessary, and we knew we would maintain our velocity. The story points went out the window. Does this mean we were doing Agile wrong? I don’t believe so.

Many definitions of DevOps exist, which generally follow the theme of culture, transformation and the building of high-velocity organizations. My favourite is this one. I’m not sure where I picked it up, and it should be attributed to someone, but I honestly cannot remember where I got it from:

“DevOps is nothing more nor less than unifying the making of things with the running of things….and not doing it alone.”

(Update: appears I may have gleaned this from a Twitter post from Jeff Sussna back in 2019. But I’m going to continue to use it.)

Does that sound something like a team to you? It does to me. But again, if you are worried about what the definition of DevOps is, then you probably have more significant problems.

I do agree that there are organizations that use DevOps as a throw-away term. It helps them appear trendy, and HR departments need to hit those essential quarterly recruitment targets. There are also clear fouls that should be caught and straightened out, like implementing a DevOps Team which sole purpose in life is to be a new middle silo between the existing Dev and Ops silos in an attempt to make DevOps happen. Guess what, it’s not going to happen.

What exactly is wrong with a company dipping a toe in the water and putting together a Devops Team? The answer is, of course, absolutely nothing. Naturally, the outcome we want to see is a truly cross-functional team with end-to-end responsibility for the service(s) that they are building. So why not try encouraging them, and helping them with their exploration. For many, this is their first step in their DevOps journey. But if we continue to knock them down and tell them that they are doing it all wrong - it may very well be their last step….