In our blog post “DevOps: Nobody intends to build a wall of confusion”, we described all the things that can go wrong even though you are supposedly working according to DevOps principles. Problems can manifest themselves in various symptoms. Starting with the length of time it takes to bring new developments into production and thus create real added value for the customer. Right through to a Dev and an Ops team confronting each other with accusations and a system landscape that is only patched up and no longer developed further.

In this blog post, we want to describe the major adjustments that can be made to establish a successful DevOps culture.

Divide and conquer … or not?

Well, as anyone who has ever had anything to do with software development knows, software doesn’t just fall from the sky (at least not yet), it is developed by people and that’s where we have to start, of course.

The most important thing is communication between the people who develop the software and those who have to put it into operation. This means that everyone who comes into contact with development and operation should be aware of all processes and problems at all times and take them into account in their work.

But then both teams have to coordinate at least daily? – Exactly! But let’s remove this unnecessary organizational hurdle and turn both teams back into one team so that every team member automatically goes through the same meetings and everyone has a common understanding of what the problem is and what the plan is.

If everyone is playing in a team again, it is once again a joint responsibility to ensure that the software runs stably and that the development team makes a decisive contribution to this.

Into the vicious circle with workarounds

We can’t do that! We can’t bother our developers with operational issues while they are implementing the next game changer. – Eh … but we can. After all, what use is the next game changer if it never goes live or is delayed due to other problems?

Problems that block operations and, in most cases, development are referred to as “technical debt”. If technical debts are not settled promptly by fixing the problems, this usually quickly leads to “workarounds” being built. Workarounds increase the complexity of any software project, but also of any system landscape, as they involve specific knowledge about the system and the system suddenly no longer behaves as the user would expect. Each workaround creates new technical debt, which leads to a vicious circle that becomes increasingly difficult to break out of.

Light at the end of the DevOps tunnel

But then – a ray of hope. By merging the teams, the employees who were previously in the operations team were given permission and hopefully also the motivation to actively contribute to the system code. This means that there are now at least a few team members who can take on the operational issues on the development side. They have become actual DevOps engineers, as they have internalized the operation and development of a system and now consider both sides. They plan, build, test, deploy and monitor their changes and based on the experience they have gained in the last cycle, they can move on to the next planning phase and start again.

The aim should now be for everyone in the team to be interdisciplinary and equally responsible for ensuring that new features are developed, bugs are fixed and the changes they have made are also transferred to ongoing operations.

If this is successful, all team members follow the DevOps guiding principle: “You build it, you run it!”

Of course, many of the points in this example are a bit of a red herring, but we are sure that many developers (for Dev and Ops) have already found themselves in a similar situation. We ourselves also occasionally find ourselves in situations where we act exactly contrary to this DevOps philosophy. It is important to reflect on yourself and correct one or two decisions if necessary.

For us, DevOps primarily has nothing to do with tools such as CI/CD pipelines or the like. For us, it’s about each team member developing the mindset that the developed features can also be rolled out by him or her, the operation can be evaluated and the experiences can be included in the next planning.

Supporting techniques

In contrast to the development of new features, the regular deployment of a new version can of course very quickly become extremely monotonous. Super, monotonous tasks can be excellently automated, e.g. through a lively CI/CD pipeline. This saves errors when rolling out manually and, of course, saves a lot of time so that the team can concentrate more on other areas, such as the development of a system. Appropriate automation standardizes the team’s approach and makes project progress more transparent for all developers involved, as well as for project managers and customers. Things like a CI/CD pipeline therefore promote the DevOps cycle, but you don’t automatically become “DevOps” just because you have set up a CI/CD pipeline.

To summarize, we would like to give you the following tips:

• DevOps is first and foremost a work ethic
• Software development and operations are in symbiosis with each other and should not be separated in terms of discipline and culture (e.g. by two teams)
• Methods such as CI/CD pipelines or functioning release management promote the DevOps culture as they define automated standards for working methods, but do not necessarily lead to DevOps being implemented
• Not only the development of software, but also the development of automated operation is fun

We hope that we have been able to present our view of the somewhat outdated but still topical subject of DevOps in this blog post.