The problem is with scale comes complexity
A team of one is the most efficient team to get data work done, but only if that one person is an expert in every step of that data work and has enough time to complete all the work on their own. Unfortunately these people are as rare as unicorn poo and stakeholders and information consumers are getting more and more impatient.
And so we hit the problem of scaling. Rather than descaling the work to be done, or the way we do the work we do the opposite, we add more. We add more people and as a result we add more lines of communication and as a result we add more processes, and as a result we add more complexity.
As we scale from 1 person to 2, from teams of 2 to the mythical two pizza team of 4- 9 people, then from one team of 7 to five teams of 7, each of these scaling points brings complexity.
One complexity pattern is as we add more people we add more lines of communication. Communication between team members, between teams and between team members, customers and stakeholders.
<<<< Add reference to source of diagram or find different referenceable diagram >>>
As we add more people we find it harder to coordinate the work that is being done. To compensate we add more process
<<find diagram>
As we add more people we add more diversity. Diversity of language, diversity of where and when we work, diversity of opinions, diversity in the ways we think we should work.
As we add more people the culture will change, we cannot control this change, and nor should we try to. But this change in culture if not curated may lead to conflict and toxicity.
<<<find reference to pattern of how many people it takes to change a culture>>.
As we add more people our leaders end up with too many people to lead effectively. We tend to create hierarchies to solve this problem, but hierarchies are an anti-pattern to the pattern of self-organisaing teams.
<<<find reference to pattern of how many people a leader can effectively lead>.
Overall, adding more often results in doing less.
<<<find referenceable quote for this>.
If we decide to add more with the hope of achieving more in the same timeframe, then we need to inspect and adapt our ways of working and introduce different patterns as we add more. We need to be conscious about our team design, to ensure we get the benefit we desire from scaling.
The Concept of Team Design
Team designs are patterns for grouping people into teams that are optimised for delivery. They provide guidance on how to structure teams based on the type of work they are performing. The goal of team design is to create cross-functional, autonomous teams that are able to adapt to changing requirements and deliver quickly, efficiently and with a high level of quality.
Teams, Squads, Pods, Crews, Cabal ….
When we start off with a small group of people with a clear boundary, terminology for the group is easy, or is it?
We will often use the term “team” to describe a small group of people with what we believe is a clear boundary. But often the boundary is not that clear.
We have a policy for Rugby teams of 15 players on the field, but what about the players on the bench are they part of the team or not? What about the players who have not been selected from that game, are they still members of the team?
We have a policy for Football/Soccer teams of 11 players on the field at the same time, but have the same problem describing the people on the bench.
With Rugby and Football we tend to swap players out when a player on the field is injured, or near the end of the game when we need players who are fresher.
But what happens when we swap players on and off the playing area on a regular basis.
In Basketball we can have five players on the court at any one time, but again a group of people on the bench who we regularly swap in and out of the game of play. The same with American Football / GridIron.
The NBA official 2022-2023 rule book Rule No. 3 states:
“Each team shall consist of five players.” “No team may be reduced to less than five players”
But when we look for the rules that state whether the players not on the court are part of the team, then things get murky. Nothing is stated in the rule book about the number of players that can be swapped in and out. But there is a policy on how many people can be made available to swap out.
“The NBA’s Board of Governeors is providing teams with an extra measure to help counter shorthanded situations due to the COVID-19 pandemic.
On Thursday, the board approved a plan to give teams the ability to expand their active roster on game nights from 13 to 15 for the 2020-21 season — a move being made in anticipation of the likelihood that teams will be missing players from time to time.
In prior seasons, teams were permitted to carry 15 total players, but only 13 could be active for game nights. An additional pair of roster spots for players on “two-way” contracts — usually designated for prospects that spend much of the season with G League affiliate teams — remain available as well.”
https://www.nba.com/news/teams-allowed-to-carry-15-players-on-active-roster-for-2020-21-season
So if you’re on the court you are a player on the team, if you’re on the bench you are a player on the roster but not on the team. As you move between the two physical locations, off the court vs on the court, you go from being a roster member to a team member and then back again.
The point of this example is to highlight how flawed language can often be.
Another example, but this time relating to animals.
A group of ducks is often called a “flock” or a “team”. But when the activity they are doing is different the group name changes:
- A group of ducks swimming together is called a “raft” or a “paddling” of ducks.
- A group of ducks on land or in a field is called a “brace” or a “safe” of ducks.
- A group of ducks in the water, diving for food is called a “dunk” of ducks.
- A group of baby ducks is called a “brood” or “clutch” of ducks.
And for horses:
- A group of horses that live together as a social unit is called a “herd” of horses.
- A group of horses that are being ridden or used for work is called a “team” of horses.
- A group of horses that are racing together is called a “field” of horses.
- A group of horses that are being shown or judged in competition is called a “string” of horses.
- A group of horses that are owned by a single individual or stable is sometimes called a “stable” of horses.
And as it is in sports or the animal domain, in the agile, product and data domains the term for a group of people is just as varied.
Terms we have seen used for a group of people in these domain:
- Team
- Pod
- Squad, Tribe, Chapter, Guild – Spotify
- Crew – unFix
- Cabal – Valve Corporation
We did not want to use every variation of terms throughout this book, we did actually experiment with using team/squad/pod/crew and as well as being onerous and looking funny then we came across “cabal”. We did a small and very unscientific survey in LinkedIn , the results being:
So for the purposes of this book we will use the term “Team” to describe a group of people.
The concept of Conway’s Law
Conway’s Law is a pattern which states the structure of a software system will tend to mirror the communication structure of the organisation that creates it. In other words, the way that teams and departments are organised will have a direct impact on the architecture and design of the software system they produce.
Conway’s Law was first proposed by computer programmer Melvin Conway in 1968. The principle has since been validated by numerous studies and has become an important consideration in software engineering and organisational design.
For example, if a software development team is structured into two separate teams that are responsible for different components of the software system, then the resulting software system may have clear separation between those two components, even if that separation is not optimal from a design perspective. Similarly, if an organisation has poor communication between different teams or departments, then the resulting software system may be fragmented and difficult to integrate.
Conway’s Law highlights the importance of considering organisational structure when designing or data team topologies. It indicates we should strive to create a communication structure that supports the goals of the data and information the AgileData teams are creating, in order to ensure a more coherent and effective result.
<<
In fixed mindset organisations who have implemented fixed and hierarchical organisation wide team structures then no matter what team topology pattern you implement, the team topology will always bounce back to mirror that organisational structure.
We need to keep this pattern in mind when designing the AgileData team design.
The concept of Brooks Law
Brooks’ Law is a pattern which states that adding people to work that is already late makes it later. It is named after Frederick P. Brooks, who first introduced this concept in his 1975 book “The Mythical Man-Month.”
The idea behind Brooks’ Law is that when more people are added to work that is already delayed, it can actually slow down the delivery of the outcome even further instead of speeding it up as one might intuitively expect. This counterintuitive result occurs due to several factors, including increased communication overhead, onboarding and training of new team members, and the complexities of dividing and integrating tasks among a larger team.
<<
As the number of team members increases, the number of communication channels grows exponentially, which makes it more challenging and time-consuming to coordinate tasks and share information. New team members also need time to become familiar with the project, its goals, and its technology, and this process takes time and effort, potentially distracting existing team members from their tasks. Furthermore, dividing tasks among a larger team and integrating their individual work can be complex, especially in software development, where tasks are often interdependent, leading to additional delays and potential conflicts.
We need to keep this pattern in mind when designing the AgileData team design.
The concept of Organisational Design
Organisational design is the process of structuring an organisation to achieve its goals. It involves creating a way of working for how work is organised, how decisions are made, and how resources are allocated. Organisational design is a critical aspect of management and can have a significant impact on an organisation’s performance.
The goal of organisational design is to create a structure that is aligned with the organisation’s goals and objectives, and that is flexible and adaptable to changing conditions. Organisational design involves a range of activities, including:
- Defining the organisation’s mission, vision, and goals.
- Developing a structure for how work is organised, including departments, teams, and roles and responsibilities.
- Determining the optimal size and shape of the organisation.
- Establishing processes for decision-making, communication, and collaboration.
- Defining the skills, knowledge, and competencies required for success within the organisation.
- Establishing systems for measuring and monitoring performance, and for making continuous improvements.
The AgileData Way of Working combines patterns from team topology, organisational design and other team design patterns in a way that is specifically targeted at the unique challenges encountered by data and analytics teams and is defined based on the unique context of the organisation the teams work in. This approach can help ensure that teams are aligned with the organisation’s goals, that communication and collaboration are optimised, and that the teams are able to adapt to changing conditions and requirements.