How to Implement DevOps via Team Topologies Approach

Many see DevOps as a set of practices to streamline and automate the software development processes to cut costs and shorten time-to-market. Yes, DevOps is about these improvements, but its underlying purpose is to boost the business’s worth for the customers. This main goal can only be reached by teams’ effective collaboration. This means every organization needs a particular team structure to secure teams’ productivity and powerful cooperation. Today we will discuss team topologies as an explicit and easy-to-implement approach to software delivery focusing on optimizing team interactions for the smoothest flow.

DevOps Team Patterns 

What team shape is good for DevOps to thrive? There is no magic, fit-all combination, however, it wouldn’t hurt if we described a couple of quite compelling types of team structures presented by software experts and counselors Matthew Skelton and Manuel Pais. With strong and weak points of these structures/topologies explored, IT leaders can identify which team organization might work best for their organization, considering Conway’s Law:

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” 

Tеam Pattern № 1: Dev and Ops Collaboration

The smoothest collaboration between Dev teams and IT Ops teams happens when each team is focusing on their assignments and interacting when and where needed. Clearly, this pattern requires quite a significant organizational switch to implement it properly. Dev and IT Ops should share a plainly disclosed and verifiably valid goal. Taking that Ops guys must feel cozy dealing with test-driven code writing and Devs must get serious about operational input and involve Ops specialists into logging operations, etc. — quite a severe change is required here, mostly cultural. 

Team Pattern № 2: Ops as Infrastructure-as-a-Service

IT businesses with classic IT Operations teams cannot perform cultural shifts quickly enough. With that, these organizations might treat the IT Ops as an Infrastructure-as-a-code provider, especially if we talk about running-on-public-cloud organization type. A DevOps team, in this case, functions as an operational quality (server provisioning, monitoring, troubleshooting, etc.) expert. It’s still a Dev team, plus specific practices like test-driven coding, CI, recurrent development, instructing, and others. Pattern № 2 clearly demonstrates some potential for easier enforcement especially compared to Topology Pattern № 1, which, by the way, can be implemented afterward. 

Team Pattern № 3:  DevOps Team with an Expiry Date

The DevOps Team with an Expiry Date performs as a separate team in its individual silo, but it has a transitory duty to improve collaboration between Devs and IT Ops and eventually vanish when the mission is complete. The members of the DevOps team with an expiry date will ‘mediate’ between Devs and Ops, introducing novelties like Kanban/Scrum for Ops teams, and dealing with details like network interface card operation, load-balancers, and so on for the developers. With that, it’s rather important not to give everlasting CI/CD responsibilities to the provisional team, otherwise, it will become a separate DevOps team, which is a team structure antipattern. 

Team Pattern № 4: DevOps as an External Service

Many IT organizations, especially SMBs and startups have small budgets and tough deadlines to build an in-house DevOps team or wait until the cultural reincarnation happens. More importantly, they lack experienced specialists skilled enough to provide professional operational maneuvers for the SDLC. In this case, IT leaders turn to a DevOps services provider to help them design and implement cost-effective and high-performing infrastructures, automate and optimize their existing environments, and give recommendations on all kinds of operational matters and beyond. 

Conway’s law or why teams go first 

According to Conway’s law, the teams’ configuration and the way they communicate within the organization can sustain the resulting growth. Teams ought to go FIRST! There are different angles to consider: team size, team life-expectancy, team connections, and others. Hierarchical groupings should follow Dunbar’s number, starting with 5-8 individuals, at the appropriate time expanding to around 15 individuals, then to 50 / 150 / 500, etc. Cognitive load (CL) stipulates, “The total amount of mental effort being used in the working memory.” It means you should restrict group obligations to coordinate with the most extreme group intellectual load. The accompanying three types of cognitive load are explained:

• Intrinsic CL – identifies with the task parts major to the issue
• Extraneous CL  – identifies with the climate wherein the assignment is performed
• Germane CL – identifies with task parts that need exceptional consideration.

So, basically, cognitive load is a kind of limiting factor for the team’s operation and performance. Teams need to be sized and engineered so they could cope with assignments never reaching cognitive overwhelm. 

4 Fundamental Team Topologies

The Team Topologies approach, also designed and presented by Matthew Skelton and Manuel Pais described in their “Team Topologies: organizing business and technology teams for fast flow” book, underlines the importance of teams for high-quality product delivery. Skeleton and Pais claim that the software development team should grow to the place where trust teams up with a high-performance boost. Here are 4 underlying team topologies that are expected to accommodate the high-geared capabilities at most. 

Stream-Aligned Team

“A ‘stream’ is the continuous flow of work aligned to a business domain or organizational capability. The continuous flow requires clarity of purpose and responsibility so that multiple teams can coexist, each with their own flow of work.”

It is a team lined up with the standard of business change, with a bunch of cross-practical skills. They are allowed to convey huge additions without wasting time waiting for another team to approve any of their steps. This team is obligated to convey product worth to customers as quickly as possible.

Platform team

“The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy.”

A stage/platform team is a team that runs on a base stage, keeping stream-aligned team flows in conveyance. The principal task for the stage team is to work on complex platform innovations and scale down tension and, consequently, the CL in the groups that utilize it.

Enabling team

“An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap.”

Enabling team is a team that helps other teams in improving software quality as part of an evolution or learning period. With this team avoiding delivery pressure, they can easily focus on product improvement and the capabilities required to upgrade innovation. So, basically, enabling team bonds with a stream-aligned team to research, try out some new trends, share info about innovative tooling, frameworks, etc. Their interaction style has mostly the recommendatory nature of counseling and support.

Complicated-Subsystem Team

“A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the sub-system.”

This is a team with special permissions for a subsystem that is too complex to be handled by a stream-aligned or platform team. Complicated-subsystem team existence is optional and only used when needed.

Team interaction modes

Team interaction should also be orchestrated well. Skelton and Pais identify three types of team interaction modes:

• Collaboration: uniting forces and closely working on the same/related assignments
• X-as-a-Service: Consuming or providing something (service) with minimal cooperation
• Facilitating: dealing with obstacles and helping other teams to overcome them. 

With these models on the table, we can clearly see that DevOps Team Pattern № 1 can be implemented through collaboration between a Stream-aligned team and a Platform team. Platform team implements DevOps Team Pattern № 2 (Ops-as-a-service) and Team Pattern № 3 (DevOps Team with an Expiry Date) is something that a Complicated-Subsystem Team does when assisting with complex tasks. 

Wrapping things up

The team topologies approach does not perform any magic. Each organization should consider team topologies’ disadvantages, which are how to share expertise between stream-aligned teams, how to build the platform team for it not to transform into another silo, how to ensure security, and the other weak points, before trying to implement these structures. If you lack experience, time, or skilled teams to deal with these rather complex challenges, you can always resort to Team Pattern № 4: DevOps as an External Service and turn to mature DevOps outsourcing companies for help.