DevOps – What does it really mean? And when are you “DevOps ready?”

You soon get the impression that DevOps is the big thing in the modern IT world. That it is a “must have” in order to be successful. That there is a concrete way to “do” DevOps. But once you dig deeper, the definitions of what DevOps actually is and how it is adopted are usually rather vague.

In order to understand why, first you have to realise that DevOps is not a procedure with fixed instructions, norms or plans. DevOps is a culture or a collection of best practices. So you can’t just “do” DevOps.

It is a corporate culture that builds on many already known and sometimes familiar components, uniting them to improve the efficiency of the software development process and the entire company. As a result, it is not enough merely to introduce new tools, fill individual positions in the company with “DevOps people” or for managers to declare that their team is “ready for DevOps”. Rather, the introduction of DevOps is an ongoing process that questions the previously lived culture of a company or department and tries to break up and optimise existing processes. Thus, DevOps is a process improvement approach!

So why “DevOps”?

Changes in corporate cultures are actually always met with resistance. “Things have always been like this and have worked fine so far. Why change them now? And anyway, we are already agile.”

This or something like it could be the initial response if you want to start introducing DevOps in your own company or at the customer’s. Most of us no doubt learned during our training that IT consists of three specialist disciplines (silos): software development, testing and operation. And that each of these areas plays its own role and pursues its own goals:

• Software development takes care of the implementation of or changes to software requested or ordered by the customer.
• Quality assurance is caught in the middle, as this job depends on the results from software development and on the test systems provided by the company.
• The company rolls out the software and takes care of stability and continuity. It knows the systems on which the software is supposed to run and/or builds them.

Even if each individual department does a good job, the result is often ultimately suboptimal. The reasons for this can often be traced back to a lack of communication between the individual specialist departments. To make matters worse, the fourth area, management, often only communicates directly with one of the three IT areas.

Poor communication inevitably creates the frictions that are inherent in most software projects. The main goal of DevOps is therefore to reduce this friction. In the language of DevOps, to remove the “wall of confusion”.

“Devs are from Venus, Ops are from Mars.(1) … Testers are probably from one of the moons of Jupiter and management is something else entirely.”

Let’s leave out testing and management for the moment and first consider the “wall of confusion” between the departments from which the name DevOps is derived: software development (Dev) and operations (Ops).

As long as each group works in its own silo and only has its own goals in mind, friction is inevitable. The company’s employees are unhappy because software may have to be introduced that requires changes to the existing systems and, in the worst case, results in downtimes due to incompatibilities and queries. Those in software development are unhappy because the new features that have been developed cannot be rolled out in a timely manner, or it only becomes clear that the operating infrastructure is not compatible with the new developments during the rollout. Incompatible frameworks, tools and procedures play their part, too. Communication does not usually take place directly, but via tickets, e-mails or third parties, which increases the effort and stress. Both sides perceive the  “other’s” actions as a threat to achieving the goals by which management measures them. Bugs that occur are played back and forth like ping-pong between dev, ops and the customer, everyone insisting on having done “their” job and looking to blame the others.

However, the solution could be “relatively” simple: improved communication with each other and coordination and standardisation of the processes and tools used across the entire process chain. DevOps should help to improve communication and above all to promote understanding between the parties involved. Unfortunately, changing a communication culture is one of the more difficult challenges when introducing a new corporate culture.

Even if management and test silos do not feature in the name “DevOps”. Of course, the same goes for them. Everyone wants to do “their” job without feeling that they are being restricted by the other parties.

This is where one of the basic ideas behind DevOps comes into play. Improved communication between the silos increases the understanding of the needs of the other areas, and conflicts are minimised or can be recognised and avoided at an early stage. Instead of passing the software project “child”on from one “parent” to the other, joint custody is exercised from development through testing to deployment and operation.

This also creates new challenges for those involved. Instead of working in your own silo with your own  specialist knowledge, a further understanding of the processes, procedures and tools used in the other silos is now needed in order to be able to work together effectively. Rather than just plumbing one topic in depth as a specialist (I-shaped specialist), people who have a wide range of knowledge of the entire IT process on top of their specialist knowledge are now increasingly in demand. These T-shaped professionals are experts in their field. However, thanks to their wide-ranging knowledge, they can communicate more easily with others or, if necessary, take on other tasks.(3)

If you now bring several such people together, you can interact better with each other on the basis of your overlapping areas of knowledge. This results in“DevOps people”, whose knowledge is no longer separated in silos but rather is arranged in a comb shape.

The nice thing about it? Knowledge rubs off. A company doesn’t have to hire new employees or explicitly train them (although this certainly helps). By breaking up the silo structure of the individual teams and “mixing” the specialists in appropriate teams, knowledge is almost inevitably gained, as long as the prerequisites for open and direct communication are in place.

The way there is thus via an intermediate step: The “DevOps teams”, in which colleagues are grouped together for a project on an interdisciplinary basis, and communication can take place simply and directly. Possible barriers to communication that have nothing to do with knowledge should be eliminated from the start. Among these are spatial separation, different superiors or established communication channels via people outside the team. It’s a good idea to physically group these teams as closely together as possible and to let them work in a self-organised manner.

Communication between the teams should also be facilitated so that emerging new processes, tools, procedures and findings can be coordinated with one another. This coordination allows a DevOps approach to gradually be developed which is specially tailored to the respective company.

The basic goal of the software development process is to develop an “us against the competition”, in other words a “we’re in this together” feeling. To maintain levels of staff satisfaction, it is also important not communicate DevOps as an order from above but as an opportunity to change and improve the existing processes.

But hold on a minute, DevOps is all about tools and automation and CI/CD and defined processes, and so on.

This is one of the misconceptions about the subject. A company cannot be geared towards DevOps just by “prescribing” the “best” tools and processes from above. Such an approach will inevitably lead to resistance from employees. On the one hand, it destroys the “we feeling” and DevOps is no longer perceived as an opportunity but as an obligation; on the other hand, these instructions may sidestep the needs of the project or the employees.

The best tools and automations do not lead to good results if the underlying processes are not designed to support them. However, if the employees develop the necessary processes together and in coordination with one another, they can then jointly decide on the tools they need or want to use in order to achieve their goal and derive the appropriate automation steps for this. The tools that team A uses to achieve success in their project are not necessarily the same tools that will lead team B to success.

Nevertheless, higher-level communication is also required in order to achieve company-wide coordination. Are there any tool sets and procedures that other teams have successfully used? Or are there specifications regarding acquisition and costs? Does it make sense to buy, implement and operate a new solution, including the necessary know-how development? Or is there an existing solution with the same functionalities?

These are questions that should be clarified comprehensively in the event of doubt. Over time, and due to the fact that the teams can be reconvened time and again for individual projects, a company-specific set of tools is developed. However, this should always be open to discussions or improvements.

The same goes for processes that are being developed. These should also be used across the board as far as possible. The corresponding automations can then be derived and implemented from such cleanly modulated processes.

Automation and tools mean that valuable time is freed up for the employees in the teams, which they can then use to share knowledge and achieve their project goals. It is therefore also in the interest of the teams to share knowledge and to find a basis for achieving the common goal.

Without successful communication, any tool or approach to automation is worthless!

The added value of DevOps

But how do the organisation, management and employees benefit when DevOps is introduced? After all, the basic idea of DevOps breaks with many long-established traditions in companies. The separation between the IT departments is largely eliminated, teams are responsible for their product and largely organise themselves and employees are expected to share their knowledge and thus their exclusivity. So why not leave things as they are and play it safe?

The answer is: Innovation and satisfaction!

For the customer

Due to the improved communication and the resulting better internal processes, DevOps leads to faster releases of the required functionalities, with higher quality software, since many sources of bugs can be eliminated in advance. Closer integration of the testers into the software development process and direct feedback to the entire team mean that debugging can take place faster. The release cycles are shortened and the customer sees results faster. This is reflected in higher customer satisfaction.

For the employee

DevOps supports innovation and new ideas, as well as knowledge generation among employees. In addition, the employees in the teams act independently and see the result of their work directly with the customer. Automation and tools eliminate as far as possible time-consuming activities that are perceived to be unnecessary and creates more time for ideas to be adopted. The horizontal part of the T-shape makes technical communication between colleagues easier and, in the event of doubt, more resources are available to help out individual colleagues. The sense of being solely responsible for a project cedes to a sense of togetherness. Ultimately, this also contributes to an increase in employee satisfaction.

For management

Instead of being the mediator between the silos when problems arise and having to direct communications, management can concentrate on a higher-level perspective. Since the teams largely organise themselves to implement projects, management has more space to act as an innovator for changes and to prepare the next projects. Due to increasing automation and the use of appropriate tools, the number of available key figures for reporting and the measurability of efficiency increases.

For the company

Due to the improved responsiveness, as well as the automation available and the more flexible teams, new product ideas can be tried out faster and their marketability validated. Rapid implementation of ideas and delivery of prototypes creates a clear competitive advantage. The productivity of the company increases due to employee motivation and the elimination of unnecessary process delays. A higher level of customer satisfaction improves the company’s reputation. The KPIs obtained from the tools and automations can be used to further optimise and streamline the existing processes, which further intensifies the effect. (6)

Conclusion

DevOps is definitely more than just a buzzword. However, neither is it a panacea that superiors can prescribe to win an “agile” sticker. “We are now agile and we are now doing DevOps!” (7) does not work if the employees are not involved.

If you want to take advantage of DevOps, first of all you have to be aware that DevOps is an idea and not a dogma. You cannot expect a 1:1 solution that is perfectly tailored to your own organisation. Rather, you have to work this out individually, with the collaboration of all stakeholders. So DevOps is more of a guideline for best practices.

Even if setting up DevOps in an organisation requires open communication, a certain willingness to take risks and to learn from failures, the advantages demonstrated in those businesses which have successfully done so cannot be dismissed out of hand. Companies such as Amazon, Netflix and NASA have already successfully completed the transformation.

DevOps is therefore an opportunity to position yourself prominently in the market and to be one step ahead of your competitors through greater innovation, improved customer loyalty and higher employee satisfaction.

This article was originally posted by frobese GmbH – read the original article here!