Showing results for 
Search instead for 
Did you mean: 
Create Post

Why Is My DevOps So Slow?

Level 9

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!


None of my Devs have any chance of being able to figure out Ops - so this will almost certainly never happen for me.



Nice post

I see what you did there, Cool Hand Luke.

I'd bet anytime your DevOps is slow, you can find the root cause in one or more people.  Folks not accepting the changes, not up to the challenges, perhaps simply not trained enough to be part of the solution, so they have become part of the problem.

Level 15

I'd bet anytime your DevOps is slow, you can find the root cause in one or more people.  Folks not accepting the changes, not up to the challenges, perhaps simply not trained enough to be part of the solution, so they have become part of the problem.(2)

Level 15

You're completely wrigth.

Level 13

Cool Hand!!!!!!!!!!!!!!!!!

Level 14

Good luck getting developers and operators communicating. 

Level 17

Some men, you just can't reach.

But wait--that's the whole core of DevOps, its very definition!


Level 7

Peter, the reason is well described. It was so important to read for me. Great article thanks and keep posting things like this! 

Communication really is key.


Level 14

I totally agree that communications is key.  It's just that developers and operators generally don't get on and don't want to talk.  I spend a lot of time trying to get people to understand that we are all on the same side and it is the users who ultimately decide if we get paid.

Level 9

Agree here Peter.  I've seen several organizations try to get into DevOps and ultimately fail because they couldn't get the communications going.  Unfortunately, without a LOT of pressure from management (and that requires buy in from all management) the communications channels never get properly established and it ends in failure with everyone that didn't want to communicate saying, "See, this crap doesn't work".

Blame Infrastructure. It is always Infrastructure's fault. Go ahead! Scapegoat them. It's their fault that the resources cannot be limitless. How foolish of anyone to think that developers be responsible with their available resources. 😉

Level 20

I agree it's probably better to take things in steps and not try to put everything in one big release!  I'm still not 100% sure I get what's new about DevOps.  New name... I seem to remember Kanban and continuous improvement long long before anyone said anything about DevOps.  The Japanese were doing this long before anyone in America was with their manufacturing processes... we have now emulated that at most factories in the USA.

Level 21

Communication between our Operations and DevOps team was definitely a problem at first, there was basically no communicator and DevOps was off working in a silo and Operations had no way to submit requirements into DevOps.  There have recently been some changes in our organization that I am hoping will help with that.  The lack of communication has definitely cause some frustrations for both sides.


So much of the industry is about "fast." Personally, I think DevOps should (often, not always) slow down a bit. The better the communications and understanding on the part of all parties the more likely that there will be success in the end. It will also reduce errors and downtimes.

Level 14

Yes, I'd rather have slow and correct than fast and wrong.

Level 9

I would normally agree, but sometimes slow does not equal correct.  In preparation for this series of posts, I spoke with some folks who both succeeded at and failed at transitioning to DevOps.  Of the ones that failed I got comments like "by the time the code is released, the version of software that it's supposed to work with is no longer deployed in our environment".  So there's a balance to it.  Slow and correct is only good if it is still fast enough to meet business requirements.  If it's not, then it can go from slow and correct to slow and wrong (because of changing environment) pretty fast.

Level 9

Exactly.  That's why I put the first part in there about validating if it is actually slow or if expectations are just out of line.  Everyone wants things to be faster, but it has to be realistic.  And part of that reality is "can we knock this code out correctly in the time that this is expected to be completed in.

Level 21

Maybe you forgot to push the Turbo button on your DevOps?


Oh Yeah Baby!


I saw this one sentence and smirked loudly (is that even possible?  Certainly the guy across the room noticed it!): 

"Sometimes, employees simply won't buy into DevOps."

To which Management's ultimate response may be:  "DevOps isn't anything new; it's just a word.  It means 'The right way to know what to do to fill our customers' needs.'  If you choose not to buy into DevOps . . . well, the door is that way.  Don't let it hit you on your way to the unemployment line."