DevOops, some common anti-patterns

So you want to support your organisation’s products and services. You want to deliver software faster. You want the software to be successful, fast moving, and to work well. You want to do DevOps. Here’s some common pitfalls of what happens next.

1 — Implement DevOps and a Toolchain in the Dev team, away from that Ops team over there

We’re the best team here. We don’t need Ops. The hierarchy of egos between Dev, Test and Ops is unhelpful and unfortunately encouraged by some. In the digital, fast moving world, where software is king, the drag that creates on delivering value and sustaining capabilities cost effectively isn’t good for anyone. Starting a DevOps initiative from within a Dev team could be well intentioned, but unless you bring the whole IT organisation with you, recognising this is IT transformation and needs to be supported at all levels, you’ll at best have to intervene and rework things, and at worst may have alienated some. And a toolchain implemented in the Dev world alone is unlikely to be deploying anything to Production….

2 — Implement Devops and a Toolchain in the Ops team, away from that Dev team over there

No we’re the best team here. We’re the one’s who get Production — production is the real deal, everything else is blue sky. Besides, we do scripting, are the best placed to implement CICD toolchains, and we do development ourselves for small changes on a host of legacy and recently deployed applications. Nothing’s stopping us from doing bigger changes either with some Business Analysis and Solution Architect support. We’re AgileOps and DevOps, the dev team needs to join us or leave. Another grass roots movement. Also could be well intentioned, partly, but also missing the trick that no-one can do this effectively in isolation, and that this is an IT, if not a Digital Transformation that your organisation needs.

3 — Hire DevOps Engineers

This is a tricky one, and I can see why firms do what they do. Advertise for Ops people and you get a certain type of person apply, and possibly put software engineering-minded people off. Advertise for Dev people and you get a different type of person apply, and they may not be bought into the new world. So you advertise for a DevOps Engineer (I’ve been guilty of this), looking for those T shaped people who can specialise in one area but have a wider appreciation for other aspects — to support autonomous multi-disciplined teams — almost right in principle, but this results in DevOps Engineers on business cards (sorry) and at worse another silo. Worse still, hire DevOps Engineers to implement infrastructure platforms and tools alone, as that’s all DevOps is right?

4 — Thinking, you build it, you run it, will work in the long term

You build it you support it is a sound idea and I support it, to an extent, but I need convincing that this strategy isn’t fundamentally flawed in the long term. Why? Because eventually the Developer is full up. No developer can support everything they’ve ever built. Developers move on, join a start up, leave the company, take on a new full time role in another part of the organisation. Even if they stay in that Product team for ever, it only takes so many developer years before the percentage of support work grows and eats up too much of their time. Finally, developers and operations people have a different mindset — creating versus problem solving, and bar those Lionel Messi’s at the centre of the Dev/Support/Infrastructure Venn Diagram, you will always have (and need) pure play specialist developers and operations people.

5 — Implement Ansible, Puppet, Chef, Kubernetes, OpenShift, Terraform…

So many tools. An amazing eco-system. I love it as well. Finding your way through that eco-system, avoiding the toolchain tax, avoiding the proliferation of too many tools in each vertical of your Toolchain, moving with the times, etc etc. All important stuff. But if this remains your only focus, indeed your first focus, you’re in trouble.

6 — Assess your maturity and think you’re done when you’re a 4 or 5

A popular starting point. Especially to satisfy leadership teams that we know where we are, know where we’re going, and can measure the progress, from one score to the next. I’m fond of maturity and capability models as well, as a framework they can help you understand the categories along which you might want to progress (CAMS in DevOps terms — Culture, Automation, Measuring, Sharing). But there’s a danger, that you give yourself a score, 1 or 2, do some time bound work, then declare you’ve arrived, at the holy grail. One thing is for sure, the pace of change is faster than ever, improvement needs to be continual, so you need to guard carefully against declaring you’re done in DevOps or Lean delivery terms.

Gary Watts

Oops by Cripi on Pixabay

I hope you enjoyed this article. If you did this is the 2nd articles in a series:

1. I fell in love with Mabl — how to become DevOps compliant
2. DevOops, some common anti-patterns (this article)
3. Getting ahead with DevOps
4. DevOps was born in 1986

You can read more from me at https://hackernoon.com/@gary.sa.watts

DevOops, some common anti-patterns was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.