Teams - Scaling Team Design
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.
<<<conways law diagram>>>
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.
<<<brooks law diagram>>>
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.
Team Design Patterns
Common Design Patterns
There are several common patterns for defining organisational and team design structures.
Functional Design, where the structure is based around specific functions, such as marketing, finance, or operations. Each function has its own team or department, and people are grouped by their area of expertise. This pattern is common in traditional organisations.
Geographic Design, where the structure is based around geographic locations. Each location has its own team or department, and people are grouped based on their physical location. This pattern is common in organisations with multiple offices or branches.
Product Design, where the structure is based around specific products or services. Each product or service has its own team or department, and people are grouped based on their contribution to that product or service. This pattern is common in organisations that focus on innovation and product development.
Role-Based Design, where the structure is based around specific roles or job functions. Each role has its own team or department, and people are grouped based on their job responsibilities. For example, an organisation might have separate teams for software developers, quality assurance analysts, and product managers.
Virtual Design, where the structure is based around people who work together remotely, often across different locations or time zones, using digital communication tools. Virtual teams are becoming increasingly common as more organisations adopt remote work policies.
Temporary Design, where the team is formed to achieve a specific objective within a defined timeline and with specific deliverables. These teams are temporary and are disbanded once the outcome has been delivered (or the estimated timeline is exceeded).
Cross-Functional Design, where the structure consists of individuals from different functional areas or areas of expertise who are grouped together and responsible for delivering specific outcomes. This pattern is common in agile organisations that focus on flexibility and adaptability.
Hierarchical Design, where the structure is based on a hierarchy, with clear lines of authority, decision-making power and a chain of command. Hierarchical teams are common in traditional, fixed mindset organisations.
Matrix Design, where the structure is based around combining several patterns. For example both functions and products, or functions and geography. People are grouped based on their expertise, but also work across different products or services. This pattern is common in large, complex organisations.
Flat Design, where the team structure is based on has minimal or zero hierarchical layers. Every person on the team has an equal say and role in the team. Flat team design is typically observed in startups or small organisations where agility, flexibility, and creativity are critical to success.
Self Forming Design, where the structure of the team is decided by a group of individuals who come together voluntarily to work on a particular outcome. In this type of team design, people themselves determine the team's structure, and are often also responsible for managing their own work and decision-making.
Fixed Mindset Team Design
There is no such thing as a fixed mindset team design.
A fixed mindset refers to a traditional mindset, where people stick to what they know best, opting for familiar paths rather than investigating new opportunities. A fixed mindset essentially means a predetermined view of the world and are unwilling to change it, whereas a growth mindset refers to an agile mindset, being open to new ideas and different ways of doing things. These mindsets can influence how people approach challenges and can have an impact on team dynamics and team topologies.
Organisations who operate under a fixed mindset organise their team topologies in a hierarchical manner. There is a clear chain of command with each level of management responsible for the team below them.
The top of the hierarchy is typically the executive or leadership team, followed by middle management, and then individual teams or departments. Within each team or department, there may be further levels of hierarchy depending on the size and complexity of the organisation.
In this type of organisational structure, decisions are often made at the top and trickle down through the levels of management to the individual teams. Communication is typically vertical, meaning that information flows up and down the chain of command.
While this traditional approach provides a clear structure and direction for the organisation, it can also be slow to adapt to changing circumstances and can result in a lack of autonomy and empowerment for individual team members.
There are some common anti-patterns used by fixed mindset organisations to structure their team topologies.
Command-and-control, based on hierarchical structures where senior managers make all the decisions and dictate how things should be done. Junior employees are expected to follow orders without question, and there is little room for creativity or innovation.
Silo centric, where different departments or teams operate independently and do not collaborate or share information with each other. This can lead to a lack of communication and coordination, and can prevent the organisation from achieving its goals.
A focus on rigid job roles, not skills, where people are assigned specific job roles and are expected to stick to them without deviation. There is little room for cross-training or development, which can limit peoples’ ability to learn new skills and grow within the organisation.
Fixed performance metrics that are defined a year in advance which discourages innovation and creativity, as people become hesitant in taking risks or iterating their ways of working or patterns as it means deviating from the established metrics.
These anti-patterns create a rigid, inflexible organisational team topologies and cultures that stifle experimentation and limit the organisation's ability to adapt to change.
Scaled Agile Framework (SaFE)
All I will say is if you are thinking of implementing the Scaled Agile Framework (SaFe) then my recommendation is don’t. Not really much more I want to say about that supposed Agile Methodology.
Growth Mindset Team Design
Growth mindset refers to an agile mindset, being open to new ideas and different ways of doing things. These mindsets can influence how people approach challenges and can have an impact on team dynamics and team design.
Just like there is no such thing as a fixed mindset team design, there is no growth mindset team design.
We can find team design patterns from organisations or patterns that are recognised as being founded on growth and agile mindsets and these patterns can help us create our own team design given our unique context.
Team of One
A "team of one" is a team design where there is effectively no team. A single person is responsible for handling multiple tasks and responsibilities typically assigned to a team. This can be common in small organisations or startups, where resources are limited, and people must wear multiple hats to get things done. In such cases, the person needs to be highly adaptable, self-organised, and skilled in various domains to complete the work.
A Team of One is characterised by a number of patterns:
Prioritisation, the person prioritises tasks based on their importance, urgency, and impact on the organisation. This helps ensure that the most critical work is done first.
Time management, efficient time management is essential for a "team of one" to prevent burnout and ensure productivity. The person should set realistic goals, allocate time for each task, and monitor progress to stay on track.
Skillset, the person must have a diverse skill set or be willing to learn new skills quickly. This might include technical skills, such as programming, design, or testing, as well as soft skills, like communication, problem-solving, and collaboration.
Tools and automation, to increase efficiency, a "team of one" should leverage appropriate tools and technologies for task management, communication, and collaboration. Automating repetitive tasks can also save time and reduce the likelihood of errors.
Continuous learning, the person should constantly be learning and improving, staying updated with industry trends, and adapting to new challenges.
Communication, effective communication is crucial for a "team of one" to keep stakeholders informed about progress, challenges, and any changes in priorities.
Seeking support: Even though it's a "team of one," the person should seek help, advice, or mentorship from colleagues, or peers.
A "team of one" team design does not typically survive as a long-term solution for an organisation. It can lead to burnout and may not be sustainable for complex data work. As the organisation grows, it becomes essential to design a team with diverse skills to scale the work done as the organisation scales.
Valve Flatland
Valve Corporation, a video game developer and digital distribution company, is known for its unique organisational structure, which has been described as a "flat" or "self-organising" team design. Rather than having a traditional hierarchy of managers and supervisors, Valve operates with a "flat" structure where every team member has a great deal of autonomy and decision-making power.
These teams or groups are referred to as "cabals".
“Cabals are really just multidisciplinary project teams. We’ve self-organized into these largely temporary groups since the early days of Valve. They exist to get a product or large feature shipped. Like any other group or effort at the company, they form organically. People decide to join the group based on their own belief that the group’s work is important enough for them to work on.”
Valve Handbook for New Employees https://www.valvesoftware.com/en/publications
Cabals are made up of individuals with different skills and expertise, and are self-organising and self-directed. Each Cabal has a high degree of autonomy and decision-making power, and is responsible for setting its own goals and priorities.
<<<For reference, read the article on cabals by Ken Birdwell. It describes where cabals came from and what they meant to us early on:
http://tinyurl.com/ygam86p.>>
The Valve team design pattern is characterised by a number of patterns:
Flat hierarchy, Valve operates with a non-hierarchical, flat organisational structure. This means that there are no formal job titles, and team members have the autonomy to choose the projects they work on.
Self-organisation, Valve team members are encouraged to work on projects that interest them and to form and reform teams as needed. There are no formal job titles or promotions, and individuals are free to move between teams and projects as they see fit.
Decentralised decision-making, rather than having managers make decisions, decisions are made through consensus-building and peer review. Any team member can propose an idea or project, and it will be evaluated by the other team members involved.
Open communication, Valve team members are encouraged to share information and collaborate with each other. There are no private offices or cubicles, and everyone works in a shared workspace.
Continuous feedback, feedback is encouraged and valued, with an emphasis on open and honest communication. Valve uses a 360-degree feedback system where team members receive feedback from their peers, subordinates, and superiors.
Scrum Team
Scrum is a set of agile patterns which include a team design pattern. The team design of a Scrum team is designed to be cross-functional and self-organising, which enables the team to adapt quickly to changing requirements and continuously improve their processes.
The Scrum team design pattern is characterised by a number of patterns:
Product Owner, the Product Owner is responsible for defining the product's vision, prioritising the product backlog, and making sure the team is working on the most valuable tasks. They are the primary stakeholder and represent the voice of the stakeholders and the customers.
Scrum Master, the Scrum Master is a servant-leader who helps the team follow the Scrum framework, coaches them on Scrum practices, and removes any obstacles or impediments that may hinder the team's progress. The Scrum Master is responsible for helping the team work in an agile way of working.
Development Team Members, the Development Team consists of people responsible for delivering a potentially releasable increment of the product at the end of each iteration. The team is cross-functional, which means it includes all the necessary skills (e.g., developers, testers, designers) to complete the work. The team is also self-organising, meaning they plan and manage their work without the need for external supervision.
This design pattern promotes collaboration, transparency, and adaptability, allowing the team to rapidly respond to changes in requirements and continuously deliver high-quality software.
The Development team members should be comprised of T-shaped skilled people <<<link to t-shaped skills chapter>>>
Amazon two pizza teams
The concept of the "2 pizza team" can be traced back to the early days of Amazon, when CEO Jeff Bezos implemented this approach as a way to encourage effective communication and collaboration within the company.
https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html
The idea behind the 2 pizza team is simple: teams should be small enough that they can be fed with just two pizzas. In other words, teams should be kept to a size where everyone can sit around a table and easily discuss and collaborate on their work.
Bezos believed that small teams were more agile and able to move quickly, and that larger teams were prone to communication breakdowns and inefficiencies. He implemented the 2 pizza team rule as a way to ensure that teams at Amazon were small enough to stay focused and effective.
Since its inception, the 2 pizza team concept has gained widespread popularity and has been adopted by many other organisations as a way to improve teamwork and collaboration. While the exact size of a 2 pizza team may vary depending on the specific needs and goals of the team, the core idea remains the same: teams should be small enough to facilitate effective communication and collaboration.
Spotify aka The ‘Spotify Model’
The team design and way of working patterns developed within Spotify and published by Henrik Kniberg & Anders Iversson were a series of videos and blog articles which provided a snapshot of Spotify's approach to software engineering and people management in 2014. They were titled “Spotify engineering culture” but somehow came to be known as the “Spotify Model”.
https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/
https://engineering.atspotify.com/2014/09/spotify-engineering-culture-part-2/
The Spotify model is a set of team and organisational design patterns designed and employed by the music streaming company, Spotify, to foster an agile and efficient working environment. It is built around the design patterns of cross-functional, self-organising, and autonomous teams, known as "squads." The patterns gained attention for their innovative approach to promoting collaboration, flexibility, and a strong company culture.
When describing the Spotify patterns, often the team design patterns are described in isolation.
These team design patterns are (as described in 2014):
Squads, small, cross-functional teams consisting of around 6-12 members. Each squad is responsible for a specific aspect of the product or service and has the autonomy to decide how to work together to achieve their goals. Squads are designed to be self-sufficient, meaning they have all the necessary skills and resources to complete their tasks.
Tribes, where squads that work on related areas or share common objectives are grouped together into larger organisational units called tribes. Each tribe is led by a Tribe Lead, who ensures alignment and coordination among the squads.
Chapters, where within a tribe, individuals with similar skills or roles form a chapter. The chapter lead, who is a line manager, focuses on personal growth, career development, and providing guidance to chapter members.
Guilds, which are informal, company-wide groups that bring together people with shared interests or skills, such as software engineers, data scientists, or designers. Guilds allow members to share knowledge, best practices, and collaborate on common challenges across the entire organisation.
However the success of the team and organisational design in Spotify at that time was also reliant on the team's way of working, the culture across the organisation and the organisational strategy.
<<<no Nonsense Agile Podcast content>>>
Software Team Topology
Team Topology is a set of patterns for organising and designing teams within an organisation to optimise their collaboration and communication. It was introduced by Matthew Skelton and Manuel Pais in their book "Team Topologies: Organizing Business and Technology Teams for Fast Flow" (2019). The main idea is to create a structure that enables teams to effectively work together, respond to changes, and continuously deliver value.
https://teamtopologies.com/
The Team Topologies patterns are designed to optimise communication, minimise cognitive load, and create an environment where teams can rapidly respond to changes and deliver value effectively. By understanding and applying these concepts, we can design adaptive, efficient, and resilient team structures.
Team Topologies suggests four fundamental team types:
Stream-aligned teams, these teams are focused on delivering end-to-end value to specific customer or user segments. They are cross-functional and work on a continuous stream of work items related to their specific user or customer group.
Platform teams, these teams build and maintain platforms or services that provide capabilities to other teams. They enable stream-aligned teams to deliver their work faster and more efficiently by providing reusable components and services.
Enabling teams, these teams provide expertise and support to stream-aligned teams, helping them adopt new technologies, practices, and ways of working. They act as catalysts for change and improvement across the organisation.
Complicated subsystem teams, these teams deal with highly complex and specialised areas of the system that require deep expertise. They may work on specific components or subsystems that are too intricate for a stream-aligned team to handle efficiently.
In addition to the team types, Team Topologies emphasises the importance of interaction modes, which describe how teams should interact and communicate. There are three main interaction modes:
Collaboration, working together closely for a specific purpose or to solve a particular problem.
X-as-a-Service, one team provides a service to another team, with a clear service-level agreement (SLA) and a focus on minimising interaction overhead.
Facilitating, one team helps another team by providing guidance, training, or other support, with a focus on improving the capabilities of the recipient team.
unFIX
unFIX is a set of patterns that help with scaling team design, introduced by Jurgen Appelo. The patterns have been inspired by innovative companies including Haier and Tesla, various agile scaling frameworks, and books such as Team Topologies, Dynamic Reteaming, and Organization Design.
The unFIX team design pattern is characterised by a number of patterns:
Crews, a Crew is a team that usually consists of three to seven people and team members are mostly dedicated to their Crew. There are seven kinds of Crews.
Value Stream Crew, a Value Stream Crew has end-to-end responsibility for a value stream. Its members are responsible for everything, from the moment they receive a customer (user) request to the moment they deliver value to the customer (user).
Facilitation Crews, sometimes you need people whose sole purpose is to help other Crews do a great job. Such teams have no value stream of their own. Instead, they ensure that the Value Stream Crews in the Base can operate smoothly. Examples would be a team of Scrum Masters or agile coaches.
Capability Crews, sometimes, you have a few people with hyper-specialised skills and you do not have enough of them to put one of them in each Value Stream Crews. A Capability Crew consists of a group of people with these advanced skills. Their goal is to assist the other Crews when their skills are needed. The Capability Crew members will (temporarily) work on a Value Stream Crew, but they are considered guest members. The situation is very similar to having external consultants with special knowledge working on a Value Stream Crew for a short period of time.
Platform Crew, your federated governance pattern may mandate that Value Stream Crews should share a common architecture and infrastructure to do their work. The goal of a Platform Crew is to offer shared services to the other Crews. Often, the services will be of a technical kind, including architecture and infrastructure, but it's also possible for them to be human services, such as learning and development.
Experience Crew, the Experience Crew is a customer-facing "front team" whose goal is to optimise the entire customer journey and user experience in the case of touchpoints across multiple products and various channels. It provides a holistic customer experience as an organisation.
Partnership Crew, the Partnership Crew has an almost identical role as the Experience Crew, except while the Experience Crew focuses on customers and users, the Partnership Crew keeps its focus on vendors, partners, freelancers, employees, and gig workers.
Governance Crew, the Governance Crew is the leadership team. It consists of several Chiefs who are the leaders of everyone in the Base. In the case of a Base being one entire company, the Governance Crew is the executive team.
Base, all Crews operate from a Base of between a handful to a few hundred people. This Base has a number of Crews of the seven standard Crew types organised around one or more value streams. The Base acts like a fully grown, independent business. It contains all the necessary skills to design, develop, and deliver products, from Design Thinking to DevOps and from Lean Startup to Lean Manufacturing.
Forums, a Forum is a group consisting of people from various Crews. The name Forum indicates that its primary purpose is for like-minded workers to get together, talk, and make decisions together. There could be a DevOps Forum, a UX Forum, a Growth Hackers Forum, etc.
https://unfix.com/
AgileData Team Design
When coaching data and analytics teams we have seen a lot of different Team Designs.
We see designs where the data and analytics skills are in a single large centralised team, or we see a hub and spoke model where skills such as development are centralised in one team and the analysis and visualisation are decentralised out to “business” teams.
Like all things AgileData there is no one pattern to rule them all and this holds true when it comes to Team Design. We have seen many successful team designs influenced by the context of the organisation, the team members, the Data Value Stream, the data platform and the Information Products.
We have seen teams designed based on specific growth patterns described above, and influenced by the data domains, data value streams and team member skills.
We have seen different Team Designs when the Data Value Stream is founded on a flow based pattern and we have seen different designs when it is based on an iteration based pattern. We have seen the same Team Design patterns successfully used for both the flow and iteration ways of working, and also seen them fail for both.
We have seen these Team Designs change over time as the organisation changes, team members change or the team members skills change.
The only constant has been change.
Given this complexity in the variety and combination of patterns we have seen and the constant changing of those patterns, we think the best way to articulate this complexity is to describe the Team Design patterns we have seen being adopted and the context or scenario under which it was adopted.
Decentralised Teams
<<<TBD>>>
Centralised Data Platform Team
Centralised, Platform Team, X-as-a-Service, Platform Crew.
<<<TBD>>>
Center of Excellence Data Platform Team
Center of Excellence, Enabling Team, Facilitating, Capability Crew
<<<TBD>>>
Work-ahead Team
<<<TBD>>>
Tri-flow Team
<<<TBD>>>
Concierge Team
<<<TBD>>>
Distributed Analyst Teams - Centralised Data Teams
In this pattern the team members with business and data analyst skills are distributed out into business units. They are served by a centralised data team.
<<<TBD>>>
Who is the customer?
<<<TBD>>>
Example AgileData Team Design
<<<TBD>>>
Frequently Asked Questions
What is the difference between Team Topologies and Organisational Design?
Team topologies and organisational design are closely related patterns that both address how teams and departments are structured within an organisation. However, they focus on different aspects of the organisation's design and can be used together to create a more effective and efficient organisation.
Team topologies is a specific pattern for designing team structures that are optimised for modern software delivery. It provides a framework for designing teams that are tailored to specific types of work, such as stream-aligned teams, platform teams, and enabling teams. This approach emphasises the importance of creating teams that are cross-functional, autonomous, and able to adapt to changing requirements.
Organisational design, on the other hand, is a broader concept that encompasses the entire structure of the organisation, including its strategy, culture, processes, and structure. Organisational design focuses on how the organisation is structured to achieve its goals, and considers factors such as the organisation's size, complexity, and external environment.
Team topologies can be seen as a specific aspect of organisational design that focuses on designing teams for software delivery. However, to create an effective organisation, it is important to consider both team topologies and organisational design as part of a holistic approach to designing the organisation.
By combining team topologies and organisational design, organisations can create a structure that is optimised for their specific goals and requirements.
We see the AgileData Way of Working as combining both the team topology and organisational design patterns in a way that is specifically targeted at the unique challenges encountered by data and analytics teams. This approach can help ensure that teams are aligned with the organisation's goals, that communication and collaboration are optimised, and that the organisation is able to adapt to changing conditions and requirements.
What is the optimal team size?
The optimal team size for an AgileData team is very dependent on the context of the team, their Way of Working and the organisation they are working within.
There are some general implications for team size for a data team.
<<<Solo team (1 person)>>>
Small teams (1-5 people). These teams are typically more agile and able to move quickly, but lack coverage of the required T-Shaped skills needed to be self-sufficient and not rely on other teams..
Medium teams (6-10 people). These teams offer a good balance between agility and diversity of T-Shaped skills.
Large teams (11+ people). These teams may have more resources and expertise, but may also face challenges in communication and decision-making complexity.
<<<expand>>>
What is the difference between Self Forming teams and Holacracy?
Self-forming team design and Holacracy share some similarities in their patterns
Self-forming teams are teams in which people have the freedom to choose which team they want to join based on their interests, skills, and goals. This approach to team design is centred around self-organisation and self-management, giving team members a high degree of autonomy in how they work.
Similarly, Holacracy is a management system that promotes self-organisation and self-management within an organisation. It aims to replace traditional hierarchical structures with a system of self-governing teams or "circles" that are empowered to make decisions and take action.
Holacracy emphasises the concept of "distributed authority," in which decision-making power is distributed throughout the organisation, rather than concentrated at the top. This approach aims to create a more agile and responsive organisation, where teams can adapt quickly to changing circumstances and take ownership of their work.
So, both self-forming teams and Holacracy share a focus on decentralisation of power and the empowerment of teams to manage themselves. However, Holacracy goes beyond team design and also provides a framework for organisational management, governance, and decision-making.
What is the difference between Self Forming, Self Managing and Self Organising teams?
In self-forming teams, people come together to design and form a team, while in self-managing or self-organising teams, individuals choose which team they want to join.
If people have been empowered to do the team design they are self-forming. If the team design is already decided and people get to choose the way the team works then they are self-managing or self-organising.
Self-managing or self-organising teams are characterised by a high degree of autonomy and a flat structure, where everyone has an equal say in how the team works and operates.
What is the difference between Self Forming,and Self Selecting teams?
In self-forming teams, people come together to design and form a team, while in self-selecting teams, people choose which team they want to join.
If people have been empowered to do the team design they are self-forming. If the team design is already decided and people get to choose which team they want to be part of they are self-selecting
Adding members to the AgileData Team makes you slower
Velocity
When helping a data and analytics team adopt a new AgileData Way of Working, it takes a while to achieve what is referred to as consistent velocity.
Velocity is a metric which is used to measure the amount of work done by a team.
The use of the term originated as part of the Scrum patterns. The team adds up the story points (a guesstimate of effort) that were assigned to the user stories that were completed during the sprint. This total is their velocity.
Velocity is also used to predict how much work a team can complete in future sprints. During the sprint planning process teams assign the user stories or tasks with story points, based on a guesstimate of effort to complete that story or task. As they accept work into the sprint backlog they keep a tally of the total points they have accepted. When the story points equal the total velocity they typically deliver the sprint is treated as full. The pattern is to use previous performance as an indicator of future performance.
In an AgileData context the AgileData team adds up the effort guesstimates that were associated with the Information Product data tasks or the Data Platform features that were completed during an iteration. We can also calculate the velocity of the team if they are using a flow pattern, by adding upon the effort guesstimates over consistent time windows, for example over 20, 60 or 90 days.
AgileData teams can also use the velocity pattern as part of their planning process. Each user story, data task or feature task in the iteration is sized using Poker Points, and then the sprint is filled with work until the total number of points matches the velocity of the previous iteration.
It will typically take a new AgileData team three to six iterations to reach full velocity. By full velocity, we mean the average number of points the team can sustainably and successfully deliver in three weeks of effort. AgileData teams will typically start out with a low velocity until they discover their most efficient Ways of Working and meet their full potential – aka full velocity. (It is important to note that the velocity of different AgileData teams is always different and you should never compare across different teams.)
Once the team has discovered its full velocity, they can also compute (or revise) an estimate of how long all the work will take to complete based on the estimates associated with the remaining Information Product Backlog. This is generally an accurate prediction.
Adding a new team member makes you slower
An issue often arises when there is a fixed or desired deadline and the estimated date of completion is after the desired date of completion. Stakeholders often find this unacceptable.
If you have a well-formed AgileData team that is at their true optimal velocity, you only have three choices:
Accept the estimated date of completion;
Reduce what you are asking the team to deliver;
Stand up an additional AgileData delivery team.
Unfortunately, these workable solutions are not always implemented. There is a big risk that someone will come up with the idea of adding one or more new members to the current team. If the team does not have good T-Skills, or you are pipelining, you will often see the suggestion that you double some of the traditional roles. For example, adding another Business Analyst (BA) and Tester to make it “go faster”.
The issue here is that adding new members to the team will make the whole team go slower and deliver less, at least in the short term. This is because:
The existing AgileData team members will need to train new members up in the way the team works, reducing what they can deliver themselves;
New members often mean new opinions. The way the team works may get renegotiated or time is taken to explain why it was agreed to do it a certain way;
The team will take time to assimilate the new skills mix and make the team effective;
Often there are not enough tasks for two members with similar skills, so one member will be idle for a portion of the iteration.
The danger of a fixed management behaviour
While fixed mindset approaches do not formally state to randomly add more team members, this is certainly a common behaviour of such approaches. It is definitely the behaviour of people who have little experience in a growth mindset and agile ways of working. Their theory being that if the team is not delivering fast enough, the answer is that everyone must be busy and more people need to be added. This is done without an understanding of the root cause for the lack of velocity.
We have seen examples where people have been arbitrarily added to a team, without the team being told the new members were turning up. Also without the people who are adding the additional team members attending the retrospectives to ensure additional team members were required and that it wasn't a problem with the team's Way of Working or something else that needed to be iterated.
I remember a situation when the Project Manager (this title is a warning sign in itself) and Scrum Coach announced they were adding another BA. I asked the experienced AgileData team members if they actually needed more members, and they all agreed it was the last thing they needed. They stated they needed clarity on what was to be delivered each sprint and for the Scrum Coach, Business Analyst and Project Manager to stop randomly removing deliverables from the sprint when the deliverable seemed “hard”.
The first problem was these deliverables were “descoped” during the sprint, not at the sprint backlog session before the sprint commenced. This meant any work that was already done on these deliverables was wasted. The second problem was the Project Manager and the Scrum Coach made the decision to remove them during the sprint, without discussing it with the team. These decisions should be made by the AgileData team not by the supporting roles.
Often when starting to work on a deliverable an AgileData team will find that they had mis-estimated the level of effort required to deliver it. This is common as the team are estimating early and with limited information as part of the sprint planning process and so are often wrong. With an experienced team, this won’t phase them, they are used to dealing with the consequences of this problem.
In this example they were not removed because the team said they had mis-estimated and couldn’t deliver them during the sprint, but because they looked “too hard” to the supporting roles when the real effort was discovered.
At that time, the AgileData team was many sprints down and had formed and stormed as a team, but the desired delivery velocity was not there. There was a fixed deadline to decommission a legacy system and it was very clear that at the current velocity the data and content would not be replaced in time for the fixed deadline.
A number of issues were obvious to the team with their current Way of the Working. The Scrum Coach had yet to introduce story points for the sprint. In addition, a pipeline approach was implemented which meant there was a BA and a Subject Matter Expert (SME) “documenting” requirements in the first sprint, the data skilled team members developing the data in the second sprint, and the content and testing skilled team members doing their data tasks in the third sprint.
The AgileData team members that highlighted any issues to be worked on in subsequent sprint retrospectives were flagged to the “management team” as causing issues. The fact that a “management team” even existed when there was only one single AgileData delivery squad, was a warning in and of itself.
The BA and the SME were reverse engineering the requirements from code and content that had been delivered over decades, rather than engaging with the key consumers and stakeholders to understand what they needed today.
A “business advisor” outside of the AgileData team (not a Product Owner) was making the call on what data and content needed to be delivered to enable the old system to be decommissioned. Another “advisor” from the visualisation software company who had never worked in an agile environment before, and was remote to the co-located AgileData team (this was pre COVID), was providing part-time “expertise” on the agile approach that should be used.
To add to the chaos the organisation had undertaken a massive reorganisation that changed every employee’s role, just as the AgileData team had started their work to rebuild the dat a platform and replace all the legacy Information Products,. This caused massive disruption when trying to get access to the key SME’s, consumers or when the Product Owner needed to engage with Stakeholders to help get key decisions made.
There were a large number of problems with their Ways of Working to solve first, before thinking about adding new members to increase velocity.
Photo by Josh Calabrese on Unsplash