Understanding the people aspect of DevOps

Simply implementing DevOps practices in a continuous workflow is insufficient to fully unlock its potential; a cultural component is also necessary. Implementing DevOps methodologies delivers better results in a culture that promotes communication, collaboration, and shared responsibility among the members of development and operations teams. However, for many organizations (particularly larger ones), this proves to be the most difficult aspect of embracing DevOps since it involves a change in mindset and company culture, which can challenge established policies and procedures that have yielded positive results thus far.

The importance of a collaborative culture

To realize the full potential of DevOps, an organization must embrace a collaborative culture! By this, we mean a culture that breaks down team silos and allows developers, operations engineers, and other stakeholders to work together to achieve the shared goal of continuously delivering high-quality software to customers. This can be achieved by creating cross-functional teams or vertical teams.

Traditionally, large organizations have organized their teams in a horizontal structure based on particular skill sets or functional areas such as development, testing, or operations (as shown in Figure 1.5). Each team concentrates on their area of expertise and only handles tasks within that domain. The teams are separated by a boundary (as illustrated in Figure 1.6.) and are measured using different performance metrics, which frequently results in conflicts.

Figure 1.5 – Team boundaries in software development

On the other hand, DevOps advocates for and flourishes in teams that are organized vertically around particular products or services, also known as cross-functional teams. This structure brings together individuals from diverse functional areas to collaborate on a common objective of delivering a specific product or service. Each team member possesses a wide range of skills and is responsible for contributing to the delivery of that product or service. The teams are also measured using a shared set of performance metrics, which encourages team members to leverage each other’s skills and expertise to achieve shared goals. For example, a vertical team may be composed of developers, testers, and operations engineers collaborating to deliver a specific application or service, as shown in the following figure:

Figure 1.6 – Vertical team boundaries

It is crucial to note that while the composition of teams is vital, the presence of a guiding figure, often a servant-leader type, is equally important. Teams require clear direction and leadership to function optimally. This leader ensures that the team remains aligned with its goals, facilitates collaboration, and provides the necessary support to address challenges.

There are other cultural components of DevOps, such as fostering a culture of continuous learning and experimentation, ownership, and accountability. However, we recommend reading The Phoenix Project by Gene Kim for a more detailed understanding of these components.

Staying clear of DevOps anti-types

When implementing a DevOps culture, it is important to be aware of potential anti-patterns and anti-types. These are ineffective and sometimes counterproductive approaches that can hinder the successful implementation of DevOps.

For example, in an effort to implement DevOps, a manager or executive may create a separate DevOps team, which can further divide development and operations teams (Figure 1.7). The only time this separation may make sense is when the team is temporary, with a clear mandate to bring the teams closer together:

Figure 1.7 – Anti-type pattern 1

Another common anti-type is when developers or development managers assume they can do without operational skills and activities (Figure 1.8). This misconception is often rooted in a misguided understanding of cloud computing, which assumes that the self-service nature of cloud computing makes operational skills obsolete. However, this perspective grossly underestimates the complexities and significance of operational skills and results in avoidable operational mistakes:

Figure 1.8 – Anti-type pattern 2

Yet another anti-type is when organizations simply rename their operations team as a DevOps or site reliability engineering (SRE) team without making any real change to their processes or silos (refer to Figure 1.9). This approach fails to understand or appreciate the importance of bringing individuals of different expertise together to work collaboratively towards shared goals:

Figure 1.9 – Anti-type pattern 3

SRE is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goal of an SRE team is to create scalable and highly reliable software systems. While SRE aligns closely with the DevOps philosophy, merely renaming an operations team to SRE without adopting its principles or practices can be considered an anti-pattern. It is not just about the title but about embracing the methodologies, practices, and culture that both DevOps and SRE advocate for.

Important note

For a more detailed analysis of DevOps anti-types and patterns, please refer to the book Team Topologies by Matthew Skelton and Manuel Pais.