Why Is My DevOps So Slow?

You’ve made the leap and have implemented a DevOps strategy in your organization. If everything is going just great, this post may not be for you. But if you haven’t implemented DevOps, or you have and things just don’t seem to be progressing as quickly as you had hoped, let’s discuss some of the reasons why your DevOps might be slow.

But First…

Before we get too far along into why your DevOps initiative might be slow, let’s first ask: Is it really slow?  If DevOps is new to your company, there may be some period of adjustment as the teams get used to communicating with each other. Additionally, it’s possible that your expectations of how fast things should be might be out of alignment with how they really are. It’s easy to think that by transitioning to DevOps, everything will be all unicorns and rainbows and instantly churning out code to make your lives better. However, depending on where you start to focus, there could be some time before you start to see benefits.

What We Have Here is a Failure to Communicate

If you’ve been following the previous three posts in this blog series, it should come as no surprise that one of the key factors that could slow down your DevOps projects is communication. Do you have a process set up to interface the developers and operations personnel so that everyone agrees on the best way to communicate back and forth? Are your developers getting the information they need from operations in a timely manner?  Can operations communicate feature requests, issues, and operations specific information to developers efficiently? If the answers to any of these questions are no, then you’ve started down the path of identifying your issue.

Keep in mind that just because you have a process in place to establish communication channels between the developers and operations personnel, you may still encounter issues. Just because a process has been established doesn’t mean it is the right process, or that people are following it. When evaluating, make sure that you don’t assume that the processes are appropriate for your company.

I’m Not Buying That

Sometimes, employees simply won't buy into DevOps. Maybe they think that they can get things done faster without user input and as a result, they ditch all processes that were in place to help facilitate developer-operator communications. As mentioned in DevOps Pitfalls, culture is a huge contributing factor to the success or failure of any DevOps initiative. The process becomes behavior which, in turn, becomes culture. If the process is being ignored, your organization needs to come up with a way of dealing with employees who choose not to follow it. This gets into a whole HR policy discussion which is way outside the scope of this blog.

I Used to Be a Developer, Now I’m a Developer Times Two!

Before you started doing DevOps, it’s likely you already had developers, and they already had a job writing code for some projects. Whether it’s because you are increasing automation or building software for a software-defined data center, the projects that you are considering the lead into DevOps are not the only projects that your developers are working on. When you make the choice to implement DevOps processes, carefully review your developers' current workloads. Based on your findings, you may need to hire more developers to help ensure that the project rolls out smoothly and in a reasonable time frame.

Size Matters

It doesn’t matter if you are developing a new software tool or deploying a new phone system, there is a tendency for a lot of people to want to get everything rolled into one big release. By doing so, users get to see the full glory of your project and you can sit back and enjoy being completely done with something.

The issue with this approach is that this could take a lot more time than users are expecting. It would be better to have some clear communication up front to identify the features that are time-critical for users to have, and build and release those first with a schedule to release the remaining features. By using this approach, developers and operators get an early win to address the critical issue. This is then followed up by additional wins as new functionality gets rolled into the software in future, short-timeline releases.

Wrap Up

As you can see, reasons for a slow DevOps process are varied but can be largely attributed to the communications that are in place between developers and operators. What other issues have you seen that have slowed down a DevOps process?

In the next and final post in this series, we'll wrap up some of what has been discussed in the series, and also address some of the comments and questions that have cropped up along the way. Finally, I’ll leave you with some DevOps resources to give you more information than I can possibly provide in five blog posts!