There is no "I" in team.
We have all heard it, and it likely triggers an involuntary eye roll. And, let’s be honest, we have all had bad team experiences. Often, it seems, we would be better off going alone. But, the reality is, we can’t do what we do alone. Software is the product of teams. DevOps is about making teams more effective. Teams make what we do possible, and better teams make better software.
Teams - like software - perform better when they are designed better. This is the crux of Matthew Skelton’s (@matthewpskelton) talk, How and Why to Design Your Teams for Modern Software Systems, at the 2017 All Day DevOps conference.
Matthew's talk is worth revisiting as we anticipate the next All Day DevOps conference this fall.
Matthew defines what a team is: “A team is more than a group of people with the same manager. Team is a single unit of delivery that is highly effective and works well together and has been given the time to develop as a single unit.” He also emphasizes that the usual assumption is that a team is stable, slowly changing, and long-lived. If a project finishes, you bring in a new project to the same team.
Matthew’s goal in his talk is to spur us to rethink how we build and use teams.
Matthew’s first piece of advice is to structure your team to take advantage of the inherent ways teams interact. Specifically, he talks about Conway’s law, the idea that “a product’s architecture tends to mirror the structure of the organization in which it is developed.”
For example, consider this team structure. A group of front-end developers talk to the back-end developers, who talk to the person who is the database administrator/architect, who talks to operations. The software models this with UI talking to the application which is talking to the core database.
This might be fine if we want a shared database, but it is a problem if we don’t.
Yawnoc, the Reverse Conway
The Reverse Conway acknowledges that communication patterns of groups and individuals will influence the shape of their solutions. Therefore, the design of a system will influence the de facto workings of an organization. (The shorthand is "Yawnoc" -- Conway spelled backwards.)
So, in the example above, you anticipate this and build your teamwork to your advantage. By changing communication structure you will influence the software design, depicted below. Here, individual contributors produce a software design that uses multiple databases.
Anticipate Cognitive Loads
Next, Matthew says we need to manage the cognitive load for teams. Cognitive load includes things that are:
Intrinsic - Things that are fundamental to how systems works - disks, CPU, memory, etc.
Extraneous - Steps or processes that don’t add anything useful. For example, remembering to do a series of extra steps before deploying.
Germane - Specific parts of a solution process, for example, capturing the transaction flow for online banking.
He emphasizes that if we give the team too much cognitive load, they dissolve back into individuals in an attempt to solve problems. So you must consider the team's cognitive load and manage it effectively.
Next, Matthew lays out some topologies for DevOps teams, starting with anti-types. There are seven in total. The typical two silos for Dev and Ops, for example. Another shows Dev and Ops silos with a third silo for DevOps, which is effectively just a rebranded system administrator operating between two separate groups (see image below).
There is also a team structure where Ops is embedded into Dev. This might sound good at first glance, but is really a lack of appreciation for the IT skill set. All of these anti-types hinder DevOps.
Counter to these team topologies are ten structures that are effective. Consider your goals for your organization and specific projects to determine which team structure is a good fit. They range from the traditional DevOps model with Dev and Ops overlapping to a DevOps Evangelist model to the DevOps as a Service model (see below).
You can read about all of them at devopstopologies.com.
Matthew also discusses teams focused on collaboration versus teams building "X-as-a-service". He also discusses and the pros and cons of each and the evolution of team topologies. He emphasizes that team topologies evolve for different parts of the organization to match the team purpose and context.
The bottom line: design the organization that helps produce the right software architecture. Remember that if cognitive load is too high, you won’t have an effective or efficient team. Also, a caution: team topologies alone will not magically produce effective software systems. This is about pointing teams in the right direction so you move forward, together.
Matthew’s presentation can be seen here.
photo: Negative Space