Skip to content
Microsoft Industry Blogs - United Kingdom

An illustration depicting a modern workplace, next to an illustration of Bit the Raccoon.

As a follow-up from the original list, there are so many more pitfalls and problems that you can find yourself into when approaching DevOps. The first list summarised the most common issues and misconceptions faced when a team or an organisation starts the journey, however these are common mistakes teams do when already up to speed.

“We are doing DevSecOps now!”

What happened to DevOps? There is no need to add a Sec label to DevOps. Implementing security practices should happen in the fabric of the organisation, not just tacking on a few tools in your CI/CD pipelines. Adding a code scanner or a SAST toolkit will not automatically provide extra value, but rather create unexpected impediments for established teams.

The right way of approaching this complex problem is by analysing how the security best practices you want to implement can be translated in the actual development process, building a common buy-in. Once a shared direction is agreed you will be able to reap benefits very quickly because the team would be prepared for the ongoing change.

“Pull Requests are just for developers”

Wrong! Simply put, Pull Requests are one of the earliest enforceable quality gates you can have. Remember, the sooner you can find a bug the cheaper it is to fix – a PR is not only a review, but also a place where only code considered “ready” should land.

“There is no planning in DevOps, everyone just keep moving”

This is a big red flag in my view. If you are already part of a modern development team, you would have noticed that planning doesn’t strictly apply to a practice that strives by the word “automation”. However you could say that planning in DevOps is continuous, because it stems from Agile practices where you are continuously planning and re-planning work. You will never be in a position where things are unplanned.

“In order to start doing DevOps at company-scale we need a centre of excellence”

Why would you need a CoE if you are already practicing what you want to scale out? A CoE is a great support, but it’s not strictly a prerequisite of enterprise-grade adoption. The easiest way to get this effort going would be to align and involve multiple interested teams so that they can see first-hand the value generated and delivered by DevOps.

The next step is cultural adoption, and you can use a similar approach to the first one for the ongoing evolution. Remember to keep transparency and accessibility at the top of the priorities so things will never be stuck due to communication issues.

 

Learn more

Join the conversation

Leave a reply

Your email address will not be published. Required fields are marked *

Loading comments...