A successful organizational transformation requires a culture that breaks down traditional silos separating the organization’s various teams. In the case of DevOps, we are looking to bring closer together, or even to merge, the teams responsible for development and for operations. The basic idea is fairly simple: it’s about encouraging communication and collaboration between all the people involved in delivering applications and systems, as well as focusing on the continuous improvement of processes and products. The goal is to be able to develop and deliver software more quickly, without sacrificing quality or security.

We want to strengthen the connection between two important areas of activity: development and operations. We want employees creating software to work in direct partnership with those taking care of delivery, integration and support. For example, developers and user interface experts work side by side with network specialists and database architects.

In theory, this will allow the IT department to significantly accelerate its deployment cycles. By merging or further connecting the two groups, new code can be monitored, analyzed and tested during development, allowing new versions to be released increasingly faster.

In practice, IT teams often have different interpretations. For example, for some teams, it is a way of tackling development and deployment as a whole, while for others, it is more a way of structuring teams and establishing practices and workflows.

Team structure

In a DevOps context, teams can have various configurations. One common form of organization is to structure teams around products rather than roles. Instead of having different teams working on a product, a single multidisciplinary team is dedicated to each product.

Another possible option is to have the development and operations teams collaborate continuously while remaining separate. Each team retains its responsibilities but works closely with the other to fix problems or improve the way they do things. This implies that teams are familiar with the others’ skill sets and are able to put themselves in the shoes of their collaborators to identify problems and overcome them.

DevOps workflows

A DevOps approach is related to Agile continuous delivery strategies and they usually share several characteristics. Even though there is no agreed-upon set of processes, some critical steps in software production can be identified:

  • Planning, during which requirements, case studies and metrics are identified
  • Creation, which simply involves programming the software
  • Verification, which includes testing and most of the quality assurance process
  • Configuration, when necessary infrastructure changes are made
  • Launch, when the software is deployed
  • Monitoring, during which we observe the user experience and overall performance of the application

The data collected during the last stage is used in planning the next deployment. DevOps also uses automated tools, virtualization and continuous integration to make the delivery process more fluid and continuous.

These steps can in many ways remind us of a traditional process, but the idea here is to repeat them constantly, at each iteration, and not only once for the whole project. The ability of the people involved to make the cycle as fluid as possible also depends on their ability to adapt and to learn from experience.

Continuously monitoring application environments in an iterative way improves processes and code. It also makes it possible to get constant feedback from users and integrators and to adjust accordingly. This provides us with a competitive advantage that’s essential in the software development field.

The importance of organizational culture

DevOps is more than an approach, it is a state of mind. Therefore, we strongly recommend revisiting the corporate culture to find ways of adapting it accordingly. Its compatibility with this way of approaching development and delivery jointly is undeniably important. In the same way that it is difficult to adopt Scrum in a team without working on its environment and culture, it is at least as hard to rally development and operations without decisively influencing the existing culture.

The organization’s management must especially not underestimate the influence of internal culture. Despite being intangible, it can be responsible for the success or failure of an initiative to move toward a DevOps culture. The choice of managers and their degree of involvement and flexibility will have a clear influence on the team’s ability to welcome change.

We especially recommend implementing mechanisms that allow people to understand and absorb what is expected of them. Unfortunately, there is no such thing as magical thinking: people do not instantly start communicating and collaborating better because they are told to. We need to take time to coach them and to keep them informed and empowered.

In conclusion

DevOps culture tries to make sure we are always offering users an exceptional experience. After all, they are the ones we are trying to satisfy and they should always remain the focus of our concerns. On the other hand, we must keep in mind that there are many other operational and financial factors to take into account. Beyond customer satisfaction, business feasibility and viability are obviously key.

Like Agility, DevOps is not an end in itself. It is more about learning and continuously improving. We confront a complex problem. It is not as simple as delivering more software products, we need to deliver better-quality software faster, without compromising reliability or stability. To do so, it is essential to make cultural changes so teams are no longer divided and so they share the same fundamental objectives and can collaborate freely.

gabriel bélanger

Previous post

Keeping people engaged and motivated!

Next post

Top 3 Impediments to Product Agility

No Comment

Leave a reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.