Team Architecture (1): The boundaries of effective agile teams
Teams — and with them, their size and ways of communication — evolve during software projects.
At some point of growth, the way teams have been collaborating until then will slow the development process down and hinder the fast delivery of value.
This article describes the setup and sizing boundaries of effective agile teams.
Team
What is a team? What components does a team consist of? Is it always the same?
The broad definition of a team will most likely be similar to the following:
A group of developers and managers responsible for the actual production and building of the given product or service.
This is relatively generic, but it describes some requirements for what comprises a team:
- “A group of developers and managers […]” — Whatever their specific role will be (we’ll come to that later). A team requires some management capabilities to gather and distribute information about what to do and when to do it. Of course, we also need people that do it then.
- “[…] responsible for the actual production and building of the given product or service.” — Every team needs a boundary of their responsibility. The responsibility should not end after the product or service has been built, but rather allow for continuous maintenance and improvements if needed.
This article will focus more on the second aspect of this definition.
Taking responsibility
Responsibility needs some room for autonomous judgment. If responsibility should be assigned to a person or team, this person or team needs to have the freedom to make decisions independently within certain boundaries.
This sort of independence requires decoupling from other instances (being other teams and top-down management) to actually move fast and respond quickly to things like bug reports or user/customer feedback.
Especially in bigger companies, multiple teams will work on one single large product.
These teams will have points of interaction and it gets harder to define teams working on the same software. — Mostly in scaling phases teams tend to grow too big and will become slower or more chaotic.
Also, teams working too close to each other often result in communication overhead and will slow the team down or make it nearly impossible to measure the performance of an individual team (e.g with the DORA metrics). This often happens if the responsibilities and boundaries of each team are not clearly defined and if there is no consistent decoupling mechanism (interaction pattern) in place between the teams.
Having too much responsibility
Every person has a limit on how much information can be kept in their brain at any given moment. This is referred to as the cognitive capacity of an individual.
The same also applies to teams, by simply adding up the cognitive capacities of all team members.
We often don’t consider cognitive load when assigning responsibilities or software parts to a team (maybe because cognitive capacities are hard to quantify).
When teams are set up without considering their cognitive capacity, they often get assigned too large of a domain or too many responsibilities.
These teams then lack the bandwidth to cover their tasks and are held back by continuous context switches between the different responsibilities and domains, leading to a decrease in the overall performance of the team.
⚠️ ☝️ This can bring harm to the business itself (by slower reaction time) as well as the individuals in the team (by feeling overworked and exhausted). Ignoring the limits of cognitive load is a psychological risk and could lead to burnout for example.
Having too big teams
Any software component that exceeds the cognitive capacity of any one team needs to be broken down into smaller components with clear decoupling mechanisms. This technique enables multiple teams to take care of the software component without overcommunicating.
One might ask if it wouldn’t be possible to just put more people on the team to increase its cognitive capacity.
This is a problem in two ways:
- The cognitive load of the team would be increased, but if the software component covers multiple domains or responsibilities, the amount of context switches an individual member of the team has to take is not decreased. Each time a context switch happens, it reserves some cognitive capacity of the individual member, which will slow the team member down for each context the team is caring about.
- It exceeds the recommended size limit of an agile team.
The recommended size limit of an agile team
An effective agile team in most organizations has a size of around 7–9 people.
Amazon for instance is known for the “2 pizza team” statement. They state that one team can be fed by 2 (American) pizzas.
This limit is also recommended by popular project management frameworks such as SCRUM and derives from evolutionary limits of group recognition and trust according to the research of Robin Dunbar (also referred to as Dunbar’s number).
Dunbar’s number
According to the research of Dunbar, the limit of individuals one person can trust is 15.
From those, around 5 people are known and trusted closely. These are usually our closest friends and supporters, who do not necessarily have to be related to the company we work at.
Research shows that there are natural restrictions for effective groupings within any organization. With increased size, the dynamics between team members will change. Rules and behaviors that may have worked for a smaller-sized group might not work for larger groups (even if the sizes just differ by a few people).
Exceeding the magic number of 7–9 people on a team will therefore decrease the amount of trust between each team member.
Trust across a team is needed to deliver software rapidly. Trust enables a team to innovate and experiment with ideas.
If trust is reduced due to a larger group of people, speed and safety of delivery will suffer
— “Team Topologies” by Matthew Skelton and Manuel Pais
These restrictions are also applied and proven to work by older performant organizations requiring high trust among individuals such as militaries with “Squads” (6–10 Soldiers), “Platoons”, “Companies”, “Battalions”, “Brigades”, “Divisions”, “Corps”, each grouping multiple units of the next lower size together.
Getting the fracture planes (boundaries) right
A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts
— “Team Topologies” by Matthew Skelton and Manuel Pais
Fracture planes of the organizational structure can be drawn in different ways:
Bounded context of a business domain: As said, this is probably the most common way of structuring. A bounded context frames the boundaries of a product area and could be assigned to a single team to align the technology with the business.
Change cadence: Monolithic systems move as fast as their slowest part. Splitting software parts (vertically) according to how frequently they change and assigning each part to a different smaller team could be a good step towards team autonomy and delivery acceleration.
Compliance: Systems sometimes need to fulfill specific regulations to be able to be delivered (for example in the finance sector). Still, some parts of the software underly stronger regulations and compliance checks than others. — It could sometimes be beneficial to isolate things under strong regulation and dedicate them to a separate team to reduce cognitive load and accelerate the delivery of softer regulated parts of the system.
Risk: Similar to the fracture plane of compliance, some components of the software system have a different risk profile for the company than others. Isolating the parts of high risk could benefit the company because cognitive loads, as well as deployments, can be separated.
Performance: Another fracture plane could be the performance requirements of some system components. Dedicating a team to a software component whose performance is crucial would improve the performance while being cost-effective and a step towards the direction of autonomously scaling this specific software component.
Technology: An obvious fracture plane in software systems is different technology being used. This could happen for example in the separation of mobile development vs. web or IoT.
User personas: Different user personas might require different feature sets. Having the same team caring about multiple user personas could lead to increased cognitive load in the respective team. — Splitting teams by user personas might be sufficient for smaller organizations. In larger organizations, tribes of multiple teams are often dedicated to a single user persona.
Conclusion
Dividing an organization into teams is difficult but an absolute necessity to avoid overloading the individuals.
It is important to assign clear boundaries to teams in which they can move independently, take ownership of the responsibilities within that boundary, and are free to make fast decisions.
Teams should be split according to the constant value streams of the organization's products. This keeps the team stable so the individuals don’t have to maintain too many relationships and can establish a high level of trust between members of the team.
Small teams enable fast decision-making, and agility, and also contribute to low coupling between software systems if the teams are split according to fracture planes with conway’s law in mind. — There will be a follow-up article about conway’s law.
