How to Get Unstuck in Your DevOps Transformation

Wercker is a Docker-Native CI/CD Automation platform for Kubernetes & Microservice Deployments

Brien Posey
Brien Posey
July 25, 2017

In today’s highly dynamic IT environments, DevOps transformations are all the rage. Yet DevOps transformations do not always go according to plan. Any number of things can completely derail a DevOps transformation. When issues occur, it’s important to take decisive action to get things back on track.

Below, I take a look at the hangups organizations commonly face when transitioning to a DevOps-centric workflow, then explain how to address the challenges.

 

The Transformation is Poorly Defined

One problem that commonly derails DevOps transformation is that the transformation itself is very poorly defined. How often have you heard a manager or an executive use a buzzword without knowing what that word really means? Unfortunately, this sometimes happens when it comes to DevOps transformations. The powers that be may decide that the organization needs a “transformation” without really understanding what a transformation entails, or why a DevOps transformation can be beneficial. Unfortunately, the end result may be endless meetings, and lots of floundering with no real progress. This situation sounds insidious, yet I have seen it happen.

The solution required for this sort of problem is to convince the powers that be to appoint someone from the DevOps team to oversee the transformation. Doing so helps the process to be less bureaucratic, and better defined.

 

There is a Reluctance to Reverse Poor Decisions

Another problem that can sometimes derail a DevOps transformation is a reluctance to reverse poor decisions. Sometimes business decisions don’t work out. That’s just a fact of life. Even so, there is sometimes a tendency to stick with a bad decision, even if it isn’t working, simply as a matter of personal pride, or because the company has invested too much already and is unwilling to cut its losses.

The important thing to remember is that modern IT must be dynamic. Part of being dynamic is changing directions when required. Any DevOps transformation project should be based around the use of quantifiable metrics. Baseline statistics should be gathered before the project begins. That way, it is easy to assess whether the transformation is having a positive or negative impact on the organization. If the metrics clearly indicate that transformative steps are making things worse, then it is important to take a step back and figure out what went wrong, rather than continue to move forward with a bad decision.

 

The Metrics Themselves Have Become a Stumbling Block

As important as quantifiable metrics are to a DevOps transformation, the metrics themselves can become a stumbling block. One of the problems that sometimes occurs is that the team that is responsible for gathering those metrics becomes a little bit overzealous. In such situations, the team may insist on collecting metrics that really don’t provide any meaningful value to the project. Similarly, the team might decide that the metrics that have been collected so far are inadequate, and that the metrics need to be collected over a longer period of time. While this is not necessarily a problem, it can become problematic if so much emphasis is placed on metric collection that the project can’t move beyond that.

Metrics are undeniably important to a DevOps transformation. Even so, metrics should be treated as a mechanism for gauging the progress and effectiveness of the transformation, not as a process that goes on indefinitely and stands in the way of progress. If metric collection has become an impediment to progress, then someone may need to step in and insist that it is time for the project to move forward, even if not everyone thinks that sufficient metrics have been collected.

 

The Approach is Overly Complex

Another problem that can stall a DevOps transformation is that too much is done too quickly. There is a certain learning curve associated with transformations, especially when the transformation requires the DevOps team to use new tools.

One of the keys to a successful transformation is to give the DevOps team time to adjust to major changes. Even though a more aggressive schedule may be preferred, a slow and steady transformation might ultimately yield better results than a transformation that is bound to a super-aggressive schedule.

 

You’re Not Listening to the Right People

One more thing that might derail a DevOps transformation is listening to the wrong people. Sometimes, decisions are made by executives who know nothing about IT. In other cases, the organization might bring in a high-priced consultant that knows all about DevOps transformations, but knows nothing about the business, or about the way that the DevOps team currently operates. The point is that the DevOps team not only needs to have a voice, they need to have the power of veto when a suggestion is made that clearly will not work for the organization.

 

About the Author

Brien Posey is a Microsoft MVP with over two decades of IT experience. Prior to becoming a freelance tech author, Posey was CIO for a national chain of hospitals and healthcare facilities. He also served as a network engineer for the United States Department of Defense at Fort Knox, and has worked as a network administrator for some of the largest insurance companies in America. In addition to Posey’s continued work in IT, he is in his third year of training as a commercial scientist-astronaut candidate.

 

Like Wercker?

We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.

As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag! 

 

Topics: Tutorials