3 Common DevOps Transformation Mistakes and How to Fix Them

Let’s say you’ve been involved in one or more software development projects. Maybe they even went well and you have more work lined up, but you’ve noticed that there are a bunch of other seemingly inferior teams out there that are doing much better in the market. Because of this, you might turn toward a different approach such as Agile development or DevOps.

 If you’re contemplating a DevOps approach, or have recently adopted it and you’re still wondering how exactly it can help, there are multiple benefits to performing a successful DevOps transformation.

Radical transparency doesn’t always manifest in the same way when applied. Organizational values and goals differ from one organization to another, so it is crucial to understand the underlying principles of radical transparency to ensure that you remain on the right track. These include:

Improved Collaboration

When teams work in silos, the result can be a less comprehensive product whose strengths are only in one or two features. Every contributing team may have tunnel vision and look at their role as the more important one or the only one worth getting right.

 In contrast, if you bring development and operations teams together, you’re likely to get more wholesome and balanced input. Additionally, when a member of one team benefits from contributions from another team’s members, they can grow to trust each other more. This is very important if you’re to have unity in an organization.

Establishing Boundaries

An organization should establish some limits to transparency. For example, some sections of an organization may be working on proprietary technology, making it difficult for them to share some information because of legal restrictions. 

In other cases, radical transparency may have a short-term adverse effect on productivity, especially when a team is trying to deal with an emergency. It is crucial to scrutinize the organization’s work processes to identify areas where increased transparency may not yield the desired results.

Faster Outcome

With DevOps, you’ll have more situations where most or all of the concerned parties are made aware of any eventualities as quickly as possible. You’ll also have fewer scenarios where a problem is identified and it takes weeks before everyone who can assist has been informed and had the issue thoroughly explained.

 Therefore, DevOps methods enable team members to not only react faster but also have the most suitable solution, or something very close to it, available. Subsequently, teams applying DevOps methods will release deliverables more often with a considerable level of stability. According to a 2019 State of DevOps Report from DORA, DevOps performers can achieve up to 106x faster lead time from committing to deployment.

Better Response to Emergencies

The software development journey may seem straightforward when you have your plans well laid out on paper, but the theory is different from reality. From unforeseen errors to new research revealing changes in customer behavior, there are plenty of curveballs that can come your way.

 A DevOps approach can get teams accustomed to faster iterations and equip them with the necessary skills to tackle emergencies with composure, ingenuity, and adequate speed. Whether it’s downtime with remote resources or a need to expand or contract a product feature, DevOps practitioners can anticipate potential hurdles and have a response strategy on standby.

Increased Employee Engagement

A DevOps methodology puts several teams in a constant state of improvement while reducing restrictions on where help can come from. When employees are faced with new challenges frequently rather than doing the same monotonous tasks, they are more likely to look forward to work and come up with new solutions regularly.

 Automation also tends to make its way into DevOps methodologies, helping team members to spend less time on repetitive tasks and indulge in their creativity. An earlier Puppet report indicated that promoters in high-performing DevOps organizations were 2.2x more likely to recommend their organization to a friend as a good place to work.

However, even with all these potential benefits, many organizations still struggle with their DevOps transformation. Here are a few common mistakes and what you can do to fix them.

Failure to Embed Culture

Project managers tend to focus on the tools and other resources needed for a DevOps transformation, convincing themselves that once they are made available, everything will work smoothly. What they forget is that fusing Dev and Ops isn’t something done overnight. Mandates like delivering weekly or daily code may require fundamental changes in how team members divide their time amongst various tasks.  

DevOps concepts also push for deeper collaboration, which may require team bonding exercises to help previously isolated coworkers cultivate relationships with each other. It is imperative to have an orientation period where team members can get first-hand experience with the tools and processes to be used in DevOps initiatives. This transition should happen in an environment that simulates the atmosphere they will be operating in, emphasizing the high-stakes nature of some tasks while still giving employees a chance to learn.

With adequate DevOps training, team members can start changing their behavior and settle into a new rhythm that will have them ready for the demands of a DevOps strategy. Generally speaking, organizations undergoing DevOps transformation ought to shift from bureaucratic and pathological cultures to generative cultures.

Lack of a Clear Message and Direction

In this era of rapid digital transformation, it is not rare for CIOs and other IT leaders to feel like their organizations are getting left behind. Consequently, some leaders opt to institute a DevOps transformation merely because they view it as the future, or even do so with no clear reason. 

Organization leaders then fail to ascertain whether the DevOps adoption is about faster software delivery, achieving cost-efficiency, improving security, or a combination of a number of objectives. While they may have a faint idea of why they are transforming, they still fail to establish the relationship between these different objectives, how they may compete with each other, and how they can pursue them concurrently and make them complement each other. 

What’s even worse is that once the DevOps transformation is underway, they barely conduct a thorough DevOps assessment to see how they are doing. With the objectives left to team members’ imaginations, a team as a whole will likely end up confused as various members have differing opinions on how DevOps concepts should help them. 

First, project directors should learn more about how each team operates and find out how DevOps can benefit them, then see what those teams can bring to the table once they are using DevOps methods. Project managers should then try to rank their DevOps goals and see which ones are more of secondary goals, and which goal stands out as the most relevant and common one amongst all teams. From here they can craft clear messages that send the teams in one direction.

Unchallenged Relationships Between Budgets and Roadmaps

In the earlier stages of an organization’s DevOps transformation, it can be hard to determine exactly how much the organization will need to spend. Keep in mind that the timing of delivery of funds and other resources greatly affects the release schedule for some work product that is dependent on these resources.

 The traditional approach of laying out detailed budgets covering long periods of time can bring a lot of rigidity in the execution of a roadmap. There are limits on how many resources can be deployed within a given time span and there’s a lot of bureaucracy when it comes to securing supplementary funds to cover unforeseen incidents.

 This in turn stifles any efforts to increase the speed at which deliverables are made available, which is the opposite of what a DevOps transformation would typically try to achieve. Project managers ought to go beyond budgeting and use techniques like rolling forecasts, and also set targets that are contingent on market events. This can help decentralize certain decision-making processes and realize a more adaptive management style that fosters DevOps success.

Other Common Mistakes

There are many other reasons why DevOps transformations may not be successful such as focusing too much on the tools, failing to be honest about your level of progress, minimal continuous improvement, bringing in an entirely new DevOps team instead of focusing on converging the existing Dev and Ops, etc. 

Some other lesser-known mistakes include miscommunication between technical and business teams, failure to consider third-party dependencies, neglecting the potential impact of a new application platform layer on existing structures, copying and pasting other organizations’ methods and technology stacks, among others.

For any person who has a hand in making decisions pertaining to DevOps transformation, there are some fundamental boxes to be checked if you’re to achieve substantial success.  

• Firstly, you need to have total buy-in from every stakeholder, be it on the business, technical, or management side. If there’s anyone this transformation affects even at the lowest level, say non-essential staff whose schedules could change slightly, it is crucial to get them onboard. Everything sounds great until you encounter your first major obstacle—that’s when you get resistance from finance, the engineers, and just about everyone else involved. 

• Secondly, you should have your goals clearly laid out with proper prioritization from the most important organization-wide goal to the smallest process-, tool- or personnel-related goal. Adopt an agile mindset by keeping tabs on any relevant macro factors and anticipating market events that could impose a sudden shift in your core objectives along the way. 

• Thirdly, focus on marginal gains. Pinpoint every area where you can make even the slightest improvement and set that as your bare minimum. Being soaked in hubris and trying to set records for the fastest deliveries may sound thrilling, but it can be one hell of a rollercoaster ride where many fail to get back up from the lows. 

Establishing the smallest possible improvement you can make and being consistent with it in various aspects of your transformation can build a steady momentum, with team members going on to make greater improvements further down the road.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach