Have you decided to invest in DevOps, or are you looking to consolidate on the investments you’ve made?
Let’s look at some of the common pitfalls that often plague DevOps teams or organisations intending to embark on a cultural shift, adopting DevOps practices.

TL;DR

• Not leveraging the full potential of cloud capabilities
• Making wholesale changes - going all in
• Measuring the wrong metric
• Lack of support from leadership
• Ignoring other capabilities (DevOps is not just about CI/CD)
• Fear of failure (DevOps is all about CI/CD)
• Leaving it to the development teams

Some common pitfalls

1. Missing the point on cloud

How cloud are you? - That’s a question I ask teams when they say they are using cloud, or they have moved to the cloud.

Cloud computing, one of the 40+ practices/capabilities of DevOps, is a vital capability that many teams underestimate. Many businesses know the efficiency and value that cloud computing brings, but do not utilise this advantage to its fullest. Accelerate - a book I highly recommend for teams looking to become high performing tech orgs - re-iterates the meaning of cloud computing as defined by the NIST. If you say you are in the cloud, then all of the following must be true for your applications and systems:

1. On-demand self-service - I can consume or get requests fulfilled from the application/service unassisted.
2. Broad network access - It is available over the network in as much as your business and security rules permit.
3. Supports resource pooling - It sustainably shares or reuses resources based on demand to avoid waste.
4. Rapid elasticity - Your application/service can provision capabilities to scale rapidly to meet surge in demand, and release when it contracts.
5. Measured service - There’s transparency in the metering of usage and the customer has some control. You can also automatically control and optimise from your end.

2. Making wholesale changes

Due to the huge cost savings and efficiency that can be gained, many leaders are tempted to make wholesale changes too early in the adoption process. As mentioned before, DevOps is a continuous experimental journey, and change takes time. You don’t want to lose steam halfway through the journey. You also need to consolidate the gains. Most successful and impactful DevOps transformation programs (e.g. Microsoft, Target, Capital One, Mercedes-Benz) were carried out in small batches, one change at a time, few teams at a time.

3. Measuring the wrong metric

Are you in the bubble of measuring vanity metrics? Businesses often measure the wrong metrics or measure the right metrics wrongfully. As summarised by Dominica Degrandis (a protagonist of flow methods and making work visible), two important questions that should help identify if a metric is good for your business are:

• Does it matter to my customer?
• Does it help us make a decision that makes our business fitter?

For example, say you are measuring performance for Dev by the total number of lines of code written, or Ops by the total number of tickets assigned. What behaviour(s) are you encouraging? Will it encourage them to deliberately increase the number of lines they write, or choose low-hanging tickets so they can close more in the same timeframe? How does this help the customer or add value to the business?

“Tell me how you will measure me and I will tell you how I’ll behave”

The metrics with which you measure may push teams to game the system. Furthermore, it might also serve you to not only keep an eye on a single metric but rather, a holistic view along with other metrics.

🎥 Watch this video (20 minutes) of a presentation by Julia Wester and Troy Magennis at the DevOps Enterprise Summit in 2015, it really resonated with me.

4. Lack of support from leadership

Transformational Leadership has a powerful impact on results. How you inspire your team can affect productivity, efficiency, customer satisfaction, and even profit. DevOps transformation programs can fail if the leadership does not play a role or only pays lip service to sweet-talks the mission. Leadership is important to:

1. Remove silos across teams
2. Enable and reward the culture of experimentation and innovation
3. Create a high trust Westrum organisation (Generative)
4. Create a high-level business and technology strategy

Lacking these can significantly increase the risk of failure or wasted investment.

5. DevOps == CI/CD ?

DevOps is not just about CI/CD. Many teams tend to focus on the Continuous Integration (CI) and the Continuous Delivery/Deployment (CD) capabilities, but then neglect Continuous Monitoring (Observability), Continuous Feedback, Continuous Planning, Continuous Security (the security hat), and other capabilities and practices that ought to be injected in the value stream. You then end up with products that continually release new features, but are extremely poor in managing bugs, mitigating and recovering from security incidents and downtimes, supporting and listening to customers, architectural design and scalability, and bridging inter-team silos.

6. Not failing

I’ve heard many teams say, we are doing DevOps but we are not yet releasing to the production environment. DevOps cannot succeed if you don’t prepare to fail. The fear of breaking something in production has pushed some businesses to add more red tape in-between and elongate the lead time, or even exclude automated deployments to production entirely. Still, such businesses are not immune to the failures they tried to prevent. On top of that, they are not well-prepared to recover from them because they don’t deploy often and are less used to the rigours.

DevOps is all about CI/CD 🤔. I know this sounds contradictory to the previous point, but it is not. What I mean here is that CI and CD, together, are the bedrock of DevOps. Without them, you cannot really succeed. It is upon these two that many practices rest. You must implement CI/CD, but not only CI/CD. With CI/CD, you can implement intelligent failure, doing it more often until it becomes less painful.

7. Leaving it to the development teams

For DevOps to work, you need both the Dev and the Ops to work together. Historically, most DevOps initiatives begin with the development teams. Therefore over time, many businesses get carried away and forget to be inclusive. Operations functions such as infrastructure management, incident management, support, performance (system) management, and in some cases, finance and procurement, must all be part of the DevOps conversation, and all need some level of automation/handshake for DevOps to be successful.

I hope this post sheds some light on possible pitfalls to avoid in your DevOps journey. I have also provided some links below for additional reading that may be helpful.

Useful links

1. How they did it, 6 companies that scaled DevOps - Article on TechBeacon
2. Measure what matters - Forbes
3. Failing by design - Harvard Business Review
4. Learning Through Failure: The Strategy of Small Losses - Sitkin, Sim B.
5. How to improve digital and self-service effectiveness - Gartner