While many companies are starting to reap the benefits of DevOps, there are also a number of pitfalls companies might step in resulting in a lack of business outcome. 

Before digging into the mistakes we tend to see in the market, I want to give you a small primer.

A Primer

At the core of DevOps lies the principles of Three Ways, which, putting it briefly, consist of: 

 Systems Thinking: Emphasis on the entire system rather than a specific department or division

1. Amplify Feedback Loop: Close the loop from your business to the customer and back again.
2. Culture of Continual Experimentation and Learning: A culture of experimentation, learning and repetition.

 The CALMS principles are a beneficial bedrock in addressing DevOps because they expand on the Three Ways. Behind the letters you find:

 Culture: Focus on learning, experimentation, and an outcome focus

• Automation: Focus on reducing manual tedious tasks with automated solutions
• Lean: Reduction of waste and focus on flow
• Measurements: Building insights across the whole value stream
• Sharing: Creating an open-minded and sharing culture.

 Anyone considering implementing DevOps should spend some time understanding and transferring those principles to their own context.

Below is a list of mistakes that will set your back severely. Read through them, relate to them, and consider how to mitigate or avoid them in your DevOps implementation.

DevOps Ends at IT Operations?

The word DevOps is a concatenation of Development and Operations. For many, that translates into Plan-Build-Run organizations typical department split-up.

It’s a mistake to only correlate the “Ops” part to IT Operations. Looking at the first principle of the Three Ways, the DevOps definition of operations is actually much more. While one of the challenges many companies face is the trench between Development and IT Operations staff, it’s just one of the internal hurdles that must be conquered.

The concept builds on bridging all aspects of your business and creating a coherent value stream, and extends to collecting knowledge and learning from actual user interactions when your product is in operations.

As DevOps is often launched from inside IT departments, it’s my recommendation that you also begin implementation at higher levels in the organization. In doing so, bridging the “silos” becomes easier, and let’s face it, as IT professionals, we rarely possess the capability to cover all of the steps in the value chain.

A further consequence of failing to address the full value chain is suboptimization, essentially meaning that the Development effort comes out of alignment with the rest of the organization.

On a side note, we often see this where Agile is introduced. Companies find it hard to identify Product Owners who can bridge development and operations. End result is “agile” IT is still working within the confines of the rest of the company, seriously retarding the results of the agile implementation.

Let’s Buy a Tool Chain!

There are so many compelling tools and opportunities out there to improve your team’s performance. And no doubt, tools do really improve your performance and ability to deliver working products to your customer and consumers.

 But as I mild-heartedly like to put it: A fool with a tool is still a fool.

Tools are to be adopted and used by your staff. This requires thorough consideration and attention. Unfortunately, we often come by companies that have been enticed to buy tools, but for good reasons failed to implement them. Here are a few example considerations to make when deciding on tools:

 Can Our Organization Adopt this Tooling Now?

The more complex a tool is, the more time it requires to implement in the organization, and the more likely the answer is no.

 What is the Impact on Our Ways of Working?

• A severe change such as a Concurrent Version Control (CVS) systems may cause fundamental changes in how everyone creates and delivers code. Instead of doing large scale replacement, an incremental approach where teams are migrated one by one.

• Can This be Done Simpler Without a Tool?

As mentioned, tools can severely complicate your ways of working. At times it’s the better option to step back and revisit if we are solving the right problem. Just because some vendor provides a tool, doesn’t mean it’s the best solution to your problem.

 A typical case I see is that companies want to increase quality and buy products to do this. Often, the real problem is that task definitions are void of quality steps, and solving this through a simple template can yield much larger results than an expensive tool.

Automate Everything!

This is a statement we see in many places and the train of thought is compelling. However, automation at its current state is still limited in many ways.

Most of the frameworks have algorithms that can auto-generate some of the automation, but there is still some way to go before it is easy to automate everything. The drawback of automation is that you have to maintain it, making your system even more complex providing your automation capability. Here are some examples of automation drawbacks:

• Full Unit Test Coverage of All Code
  This leads to a duplication of your codebase and significantly increases maintenance. While some tools help you with the skeleton, the effort required to implement and maintain the tests is still massive. We recommend deciding on the necessary level of unit test coverage based market feedback and developer experience.
• UI Automation
  While tooling improves, this is still a problematic area to automate. Creating workflow-based UI tests is doable and a good way to go. However, changes in product graphics and layout are prone to invalidating tests and potentially require maintenance.
• Automating Steps Requiring Human Interaction
  While you might be able to push code from developers to customers automatically, it can be necessary to have human gates as there might be market feedback or considerations required before releasing new software. This is also emphasized in agile where delivering potentially shippable products is the goal, but releases are determined by the product owner.

But don’t let the examples above hold you back. We recommend starting by easy implementation and high potential automations.

In terms of order for DevOps to get your automation in place, the first you should look at is CI/CD. If you want to dive a bit more into CI/CD there are many great sources such as Atlassian’s article. (We are not sponsored or recommend any products.)

After getting your build and delivery automated, ensuring consistency, our recommendation is to dive into the QA parts. The final step is to ensure feedback is continuously fed into the development pipeline and made part of the deliveries to the market.

If you have the option of going greenfield we strongly recommend choosing a platform with a high degree of automation built-in from scratch.

DevOps is Not the Goal—It is the Means

Right now, the trend in many companies is that Agile and DevOps are the solutions to many of their problems. Surely many companies are in need of change, however, at times we see companies putting DevOps and Agile front and center in their agendas. And surely both models are sets of healthy principles, but let us be honest—many of your consumers don’t care that much!

They care about the problem your product solves.

While customers don’t care too much about your choice of methods, here are some other challenges you may run into:

• Hyper-Frequent Releases Cause Customer Problems

Your customer provides the product to end-consumers who might require assistance to adopt the software.

• Releasing Software Early and Often Can Pose Problems for Customers

Some customers may have significant transition costs when new software is released, especially if releases introduce new features or change core workflows. While changes might be engineering wise easy and the release process highly automated, the customer impact can be quite severe.

• Out of Sync with Customer Process

Many companies have critical phases like end-of-year accounting. Releasing new software in the middle of those periods might cause severe frustration. Staff under pressure will have to change ways of working and changes might introduce new issues blocking their work.

• Over-Engineering Your Product

We are strong proponents of craftsmanship and creating the best possible product and code, but it can be taken too far. The cost of adding quality increases exponentially and your final price of the product might exceed customers’ willingness to pay for it.

 While this might seem odd, it’s important to understand that quality is defined by the customer’s perception and not what lengths you go through to build the perfect product. It’s important that product quality is linked to customer feedback in operations to achieve the right level of assurance.

 For that reason, when setting out on your DevOps implementation always keep the end-in-mind: providing your customers with the value they expect and deserve.

Hopefully, we all make mistakes—I’ve surely made my share!

However, the most important lesson is that not trying is failing is the biggest mistake of all. Only through experimentation, observation, and understanding what went wrong can we progress and grow as an industry.

 If you want to share your advice or discuss what we have shared, then please feel free to reach out!

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach