DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog Twelve DevOps Anti-Patterns

Twelve DevOps Anti-Patterns

So you wanna do DevOps? Okay, but before you start, let’s have a look at some of the things you shouldn’t do.

In the good old days, we just called them “bad ideas”, but along came diplomacy and political correctness, out went the “brain storm” and in came the “idea shower” and with it came the “anti-pattern”.

If the “pattern” is the right way, then inherently the “anti-pattern” is the wrong – and so to stop you going wrong, we’ve compiled this list (with a little help from the DevOps community).

1. DevOps is a process

Not exactly. It’s a philosophy. It’s a way of thinking. DevOps is supported by process and tools.

DevOps according to Gene Kim, is underpinned by 3 core principles known as the “Three Ways”.

The First Way emphasizes the performance of the entire system – the value stream.

The Second Way is about shorting and amplifying feedback loops.

The Third Way is about creating a culture that fosters continual learning and understanding.

2. Agile equals DevOps?

If you’re asking this question, then you’re probably running some agile process. That’s good. You’ve got a software development process that compliments DevOps, but Agile doesn’t mean you’ve adopted DevOps.

DevOps is an agile enabler allowing operations to collaborate supporting a more continuous flow of work into IT Operations and out into production where customers can realize its value.

3. Rebrand your ops/dev/any team as the DevOps

CIO: “I want to embrace DevOps over the coming year.”

MGR: “Already ready done, we changed the department signage this morning. We are so awesome we now have two DevOps teams.”

Yeah great. And I bet you now have lots of “DevOps” engineers walking round too. If you’re lucky they may sit next to each other at lunch.

4. Start a separate DevOps group

Go on. I dare you. Done it? Well done. You’ve implemented DevOps. Actually what you just did is create yet another silo. Now you’ve got yourself another team you’ve got to try and integrate. Another team with walls to breakdown. Maybe you could go back and rebrand (see AP: x) and create 3 DevOps teams then you’d be super awesome.

DevOps is not about cherry picking some developers and some IT Operations people and silo’ing them off. You’ve got to embrace and embed.

Collapse the development team into the ops team or vice-versa. You need to fully break down the barriers / walls / guards between the teams and mould them into a single unit with shared goals and responsibilities.

5. The hostile takeover

DevOps. So that’s a word that starts with “Dev”. That means development lead, because development comes first…… Problem?

DevMgr – “Er, we’re now doing DevOps. My guys need to learn the production systems.”

OpsMgr – “Er….ok. So who’s going to be developing the code?”

The word DevOps is clever. It’s a portmanteau. This means the combination of two words, to form a new word, which gives a new meaning. It even delivers some efficiency. It doesn’t mean we took the word operations and replaced it with the word development. So why would you try and adopt DevOps in that manner?

DevOps requires both groups to recognise their key skills. Share what needs to be shared to collaborate. Learn what needs to be learnt to improve. It does not mean retraining. It does not mean cross-skilling (however, this may be a welcome side-effect). It does mean providing feedback and visibility to improve.

6. DevOps is a buzzword

If you think DevOps is a buzzword, then you’ve probably been using “The Cloud” as a misnomer too. DevOps is a word, you got that right. Actually, it’s a portmanteau of Development and IT Operations (I’ll collect my gold star from teacher later).

DevOps is more than just a cool buzz word. It’s a state of mind. You must embrace its values, you must help others embrace its values and you must continually improve yourself and help others to improve for it to be successful. Once you throw away the BS and start collaborating you might get people to think your catchy new word “DevOps” might actually be cool.

7. Sell DevOps as a silver bullet

DevOps is voodoo. You basically get your Development team and your IT Operations team together. They smoke some peyote and then sacrifice a chicken. Once you’ve done that your organisation will be revolutionised.

You’ll be able to ship software faster than ever before. Configuration will be self-managing. Your deployment tools will become self-aware. Your development and IT Operations teams will have a new found harmony.

Get this….. DevOps is hard work! For most, it requires Culture Change! That’s one of the hardest things you’ll ever attempt. For seasoned development and IT Operations teams you’re about to try and turn their world up-side-down. Don’t try and do it overnight or you will fail.

8. DevOps means Developers Managing Production

No. Hell No and No again. I’m so incensed you’ll just have to read this….

9. DevOps is Development-driven release management

Let me get 2 things clear;

  1. DevOps is not development driven.
  2. DevOps is not IT Operations driven.

If you want a developer-driven environment, fine, go create one. Just don’t call it DevOps. It’s not.

Take a look at this article for example.

“Within DevOps, programmers are programmers.” – Right on!

“Equally, within DevOps, operations staff are operations staff.” – We’re cooking now!

“Traditionally, getting software out to production can be either the responsibility of operations or of the development team.”

Hang on……

“IT operations teams will have established and trusted deployment strategies in place that minimise downtime and ensure stability at the expense of agility and speed of response.”

Yep, we’re back on track…… and then bam!

“Development-driven release management” – What? It gets worse
“Development-driven release management goes the other way and looks at how deployment can be carried out as often and easily as possible.

However, these deployments aren’t necessarily into production……………

From a process standpoint, continuous delivery has two big requirements: first, the process itself has to be solid beyond development. This means that it has to be as solid as any process that a traditional IT operations team might put into place.”

No. Non. Nej. Na. Nee. Nein.

Development-driven anything may be a process. It’s just not DevOps.

Replacing your IT Operations team with an automated deployment process is nonsense. Please don’t try this at home folks!

10. We can’t do DevOps – We’re Unique

Yes you are, you little beauty you! But you’re not special enough that you can’t adopt DevOps. I bet you’re the best developer out there; you code quicker than lighting, and deliver the sort of code that makes grown men cry with joy. No? Okay, so you’re the most awesome Ops Guy on planet. If Chuck Norris were an IT Operations Engineer he’d be want to be you.

However, you and your organisation don’t have some unique factor that won’t allow you to adopt DevOps. So give it a go!

Jesse Robbins from OpsCode has some good advice for getting started;

  • Start Small – Build Trust
  • Create Champions
  • Build Confidence
  • Celebrate Success
  • Exploit Circumstance

11. We can’t do DevOps – We’ve got the wrong people

Well why did you hire them? That’s right – they’re awesome! If you don’t think that, then you need to take a long hard look at yourself, then go and discover the real hidden talents in your team.

Someone told me recently that they couldn’t do DevOps because “they have the wrong developers or the wrong ops people…”. So they have developers who can’t code? I thought to myself, “my organisation has the wrong developers, people who can’t code, they run HR and Marketing!”

DevOps fosters a collaborative working relationship between Development and IT Operations. This collaboration can extend right through the organisation further enhancing working relationships between teams.

You don’t have the wrong people. You have the wrong thought process. Deal with it.

12. Collaboration when things go pear-shaped

Ok genius. You messed up. So what? We all do it. But now you want your IT Operations guys out of bed at 2am to clean-up something they know nothing about. They are IT Operations engineers – not the “fixer” like Michael Clayton. Waiting until an error occurs during a deployment for Development and IT Operations to collaborate sucks.

It’s too late for this problem….. but maybe not for the next. You have your Development team and your IT Operations team talking (or swearing at 2am) with each other, but at least they are talking. Keep the dialogue going. Get a retrospective review of what happened and how you can fix it going forward. If you have encountered this situation, then try and keep the dialogue going with between your teams. Open the communication channels with Development and IT Operations early. There’s hope for you yet!

— TheDevMgr

Looking for some help on your DevOps transformation? Have a look at the services we offer.

16 thoughts on “Twelve DevOps Anti-Patterns

  1. I agree there are hidden talents to be found in every team, however it’s a bit naïve to think that everyone in the organisation is going to want to go along on the DevOps journey. Some people, particularly in organisations using legacy technology, may even fight to keep the walls up so that the teams remain in their safe little compartments.
    Though the role of DevOps Champion is perhaps best served by a technician, management play a vital role in ensuring the harmony of the team as it goes through the growing pains of becoming a more integrated unit. Sometimes that can mean making some hard decisions about people.

  2. Thankyou – now I understand the term DevOps. Its appears to be the new buzzword and silver bullet for a lot of organisations, yet I think this is the nearest I’ve got to an accurate description of it. I’ve recently written a piece which talks about the anti-performant patterns which is relevant to this article (Now need to update with some of the points I’ve taken from this).

    1. Thanks for you pingback/comment. We’ve translated into English with Google Translate and apologize if there are any “lost in translation” mistakes.
      Translated Text
      “Continuing the series of translations of DevOps, this time I want to talk about how to do. We have seen this, every time something new comes, such as agile. There are a cargo cult, to hear a speech that we are special and we all wrong and so on. So let’s try to avoid that in the case of DevOps.”

      1. A really good point on “that we are special and we all wrong and so on”.
        In the early days of the agile movement, some upset was caused because the approach taken was too dogmatic. We knew things could be done better, but no one wanted to hear that everything they were doing was wrong and always had been.
        At the core of Agile, Lean, DevOps and so many other philosophies is the acknowledgement that learning is continual. Let’s hope the DevOps movement can learn from its predecessors and take a sensitive and pragmatic approach to education and culture change.
        — TheDevMgr

  3. I think this sums up a lot of what’s wrong with all the fakers out there using the DevOps phraseology for talent aquisition and branding purposes. No wonder we didn’t come up with a name for it for all these years!
    – Asher Bond

  4. The funny thing that now there is a flashy new name, aka DevOps, for something we’re doing aready for a couple of years. Not to the last point, but we’re getting there. I think DevOps is too hip and that’s keeping people away.

  5. Good Article and I also liked the thought process for DevOps. I believe DevOps is CALMS
    C – Culture (One Team – One Goal)
    A – Automation (wherever it is applicable)
    L – Learning based on experiments
    M – Measurement (approach and realistic metrics)
    S – Sharing ( Shared Delivery Process between Dev and Ops to achieve the common goal together)

Leave a Reply

Your email address will not be published.