how to make it
work for you

DevOps: how to make it work for you

Dec 1, 2021
Dmitry Chuyko

The concept of DevOps dates back to 2009, yet it remains a hot topic. Everybody wants a DevOps engineer in their company. People talk about DevOps practices and implement them into their processes. Still, many developers, when engaged in private conversation, say that DevOps does not work, does not help, and makes their job more complicated and even annoying.

Is there a reason why DevOps keeps proving its efficiency in some companies, while becoming a nuisance in others? Let’s dive into the issue and find out.


  1. What makes DevOps tick
  2. Top 10 common mistakes of practicing DevOps
    1. Using Scrum as the micromanaging tool
    2. Not using the united runtime environment
    3. Testing only “the happy path” and “the clean data”
    4. Overtesting
    5. Making the DevOps engineer a bottleneck
    6. Introducing “DevOps” without implementing Agile
    7. Ignoring the security
    8. Making your teams work on different goals
    9. Working with the generic tools only
    10. Making DevOps a routine without a purpose
  3. The biggest mistake - not utilizing DevOps

What makes DevOps tick

To discover why DevOps does work, let us explore the cases where it does not. It is easy to find many opinions about DevOps inefficiency, including these:

This is what developers and even DevOps engineers say about DevOps

When you read these opinions, you always find one common point: “What we work with is not DevOps, but an imitation.” This often happens when managers treat DevOps as a universal guide or even a ritual with no substance, rather than the philosophy or set of practices needed to be adjusted for different tasks.

Every story about failed DevOps implementation usually involves decisions, where management does not really know what DevOps is or its goals before they start introducing it to the company’s software development workflow.

This means we need a clear understanding of what DevOps is before finding out why it does not work in some cases. In BellSoft, we like the definition of Donovan Brown, a Partner program manager at the Azure CTO incubations team at Microsoft and a speaker at our own JRush conference. Donovan says that DevOps is the union of people, processes, and products to enable a continuous delivery of value to end-users. And the emphasis on “continuous” and “value” is the essential part.

When working on implementing DevOps practices, managers sometimes forget the end goal, which is to deliver a valuable product. It all goes downhill from there. Developers lose themselves in the endless cycle of updates and software releases that do not make the customers happy. With every new version, the product devolves.

So if there is one thing you take away from this article, it should be this 一 remember the end goal and implement the practices with this goal in mind! There is no single universal approach to DevOps that will work for every company. Invent your own processes, do not stick to the formal guidelines. Be creative, and always remember to bring a valuable product to your customers.

Let us discuss the common mistakes developers still make in 2021 when implementing DevOps. Or contact our engineers and let them share their experience of DevOps in the world of Java development.

Top 10 common mistakes of practicing DevOps

Using Scrum as the micromanaging tool

Scrum is an excellent practice for automation, one of the most important aspects of a successful DevOps routine. And yet, administrators tend to use it as the micromanaging tool, implementing only some values of Scrum while ignoring the others. Remember these values are not only Commitment and Focus, but also Openness, Respect, and Courage, and they only work together!

If your Daily Scrum (which should be a 15 minute event) turns into an hour-long meeting, you are doing something wrong. If someone outside the Dev team decides who should work on which tasks, it is not Scrum. If Sprint reviews do not lead to future adaptations, then they are useless.

If you only utilize Scrum to put your team into time brackets, you better avoid working with it at all.

Not using the united runtime environment

“It worked on my computer” is a phrase no one wants to hear, and to avoid hearing it, consider utilizing a JRush page to listen to full presentations.

Subcribe to our newsletter


Read the industry news, receive solutions to your problems, and find the ways to save money.

Further reading