Please, Don’t Just “Do” DevOps!

DevOps is currently very fashionable, and so I hear lots of people talking about how their IT organization will be doing DevOps over the next year or so. The trouble is, as soon as I hear this I cringe, because I can’t help thinking about all of the failed improvement projects these same IT organizations have run in the past. Their stories are remarkably similar and they go something like this…

”We Tried That and It Didn’t Work”

When ITIL was the new approach that everyone wanted to use, these organizations decided that they were going to “do ITIL.” This tended to involve devoting lots of resources to a huge, tool-based, monolithic project, with a team of hard working and technically expert consultants who spent many months – sometimes even years – buying tools, creating process documentation, and configuring the tools to match. The IT organization was then tasked with attempting to follow these new processes. All too often they had virtually no understanding of the reasoning that underpinned the new processes, very little focus on their customers, and even less focus on creating value. The results of these projects were predictable; lots of money was spent but no value was created. These organizations later said, “We tried ITIL a few years ago, and it didn’t work”.

Some of these same organizations next tried to implement COBIT. As you may know, COBIT is a framework for the governance of enterprise IT, and like all governance approaches it must be driven from the top down; to ensure that IT is aligned with the rest of the business, it is essential for governance to come from outside the IT organization. Unfortunately, these COBIT projects were often owned and managed by the IT department, and this again resulted in a technical focus that couldn’t deliver. “We tried COBIT and that didn’t work either.”

Now some of these same organizations tell me that they are going to “do DevOps” and I know that in a year or two they will be telling me: “We tried DevOps and it didn’t work.”  And they will certainly be right about it not working, but not because there’s something wrong with DevOps.

How You Should Adopt DevOps

What’s wrong is the approach these organizations take to planning improvements. You should never implement a best practice, a framework, or a standard as an end in itself. Things like ITIL, COBIT, and DevOps are resources. They are sources of excellent ideas that you can use to help improve how you deliver service to your customers. But until you understand that the entire purpose of an improvement project is to increase the value of whatever it is you deliver to your customers, your project is bound to fail. A new practice may be fashionable but it’s the way you implement it that decides whether or not it delivers value.  And any new practice that doesn’t deliver new, improved or additional value is not worth the effort you expended on it.

So, if you are thinking about whether DevOps is right for you, you should start by thinking about your customers, and how you create value for them. Some of the questions you might think about are:

• How long does it take us to respond when our customers ask for new services or new features?
• How quickly can we test and release software in an emergency, e.g. for a security patch or a regulatory requirement?
• How often do our changes go wrong, either taking too long, costing too much, causing incidents, or simply failing to deliver the expected business value?

If the answers to these questions show that you need to make improvements, then sit down with your customers to talk about what they need. Get a feel for what they would really like from IT if you could deliver everything they dream about. Then agree on a vision, and share it with all your stakeholders.

Once you’ve done that, it’s time to have a look at some of the great DevOps ideas to see how they could fit into your environment and help you deliver what you have agreed you want to achieve.   You’ll almost certainly find many ideas you’ll want to use. But don’t try to change everything at once. Think about incremental improvements you can make that will take you towards your vision. Maybe you can automate testing for some of your services, to reduce errors and increase change throughput. Or maybe you can improve collaboration between your developers and your operations teams, so there is less conflict and more success during handover. You should certainly attend some DevOps conferences to get a feeling for what other people are doing, and see if there are any ideas that you could adopt. You should also read this blog about how the service desk can help you succeed with DevOps.

Just remember that even if your vision is to have a completely integrated set of tools that will automate your entire software delivery pipeline, these tools are not the goal. Don’t be distracted by the shiny toys and forget about value creation and customer experience. And, please, don’t just “do” DevOps!