Culture DevOps Ops

Another bloomin’ opinion on DevOps

At the time, to me, it seemed that a lot of talk was about automation and developers not needing to speak to Ops about logging onto production systems. Tools like Puppet and Chef were being discussed, and documentation as code seemed to be a big thing. But no one was really talking about how “DevOps” would look in businesses.

A few years later, with the power of hindsight, it’s clear that you don’t just “Do DevOps” just like you don’t just “Do ITIL”.

DevOps should be an enabler for your engineering department. It should add business value and break down barriers between teams. So “doing DevOps” should be about identifying pain points in your engineering department, and resolving them with the goal of delivering business value.

Here are some of the things I think you will see as a result of implementing a more collaborative approach.

  1. Teams speaking to each other
    This is so SIMPLE. Sit Operations engineers and your Development teams together, et voila! They talk! No more “Them vs Us”.
    Hello solving things as a team, goodbye throwing issues over “The Wall”.
  2. Quicker implementation of solutions
    In the past, your Developers might want to try a new piece of infrastructure that was not supported by the Operations team. Getting the Operations team to buy into this new thing might have been painful, or hard to do. When teams are working together, to solve issues, to investigate solutions to problems, the issue of needing “buy-in” isn’t there, because both teams have got to the solution together.
    Hello better technology adoption, goodbye “but we’ve always worked ‘x’ way”
  3. Less manual, repeat tasks
    Now that you’re teams are talking, they’re going to be sharing any pain they might have with software that is difficult to either release or maintain (Or maybe even both, unlucky). This frustration should lead to automation of tasks that are manual or possibly re-visiting deploy jobs which are slow and take too much time.
    Hello more efficient builds and deploys, goodbye frustrated Dev/Ops engineers!
  4. Delivering software faster
    Once your teams are solving problems together and automating where they need to (where it adds value), you should see your ability to ship products to the front line increase. Things you should be measuring are the flight time for changes and delivery time for your projects.
    Hello, new products (and increased business value), goodbye slow, long-running delivery projects!
    Okay, don’t roll your eyes. I know I always come back to incidents. But, this is true.
    Automation and communication should lead to identifying incidents earlier, as well as less human error. We’ll be discovering defects in our code earlier (in our labs before they get to production.
    Hello, happier customers, goodbye sad customers because we messed up!
zoojar: London grind

In conclusion, “doing DevOps” simply means enabling your developers to deliver their software faster, by having them work closely with your Ops team. DevOps is about delivering business value. It’s not about a specific tool or forcing your teams to follow a specific process. It’s about breaking down barriers between teams, having them work on the things they should be working on (delivering value), and not having to react to incidents or repeat tasks over and over again.