TL;DR
This is a series of articles (among them are Team Topologies and Marty Cagan's Empowered Product Teams) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions.
We assume you might already be familiar with seven archetypes of the Org Topologies.
In this article, we will analyze the famous “Tribes and Squads” model (also known as a “Spotify model”) in terms of where it fits on the archetype map.
The promise of the Spotify model:
The Spotify model sounds promising as it offers a fresh view of old problems.
It has also made it to the large market thanks to large consulting firms.
What is the promise of the model? Your organization will become agile by defining value areas and creating autonomous fast to deliver teams working in them.
And there are cases like the one of ING that seem to prove that it works great to create a culture of delivery and innovation.
What we're concluding:
On paper it might really look promising, the reality, though, is different.
We've met companies after they've “accomplished their transformation to Spotify”.
We see many non-autonomous teams owning some internal concerns like components and services. These teams are bogged down with interdependencies.
They work in what is called “value areas” with an Area Lead being almost like a real Product Owner for the area.
But each team has its own team-level backlog and a team-level output owner.
This kills the idea of managing at the Value Area level because, with work defined at the team level, each team has its focus and agenda.
And what's even worse is that such an organization might truly believe that it has transformed.
But in fact, they are only using some new terminology like tribes and squads, but internally, it is all the same. Low adaptivity, low innovation. A culture of execution and dependency management.
We've also seen cases when SAFe applied with the Spotify model to deal with the inter-team blocking dependencies.
Our classification is likely A1-A2. When the teams are truly great, customer-facing, and autonomous: A3.
Archetype Map of Org Topologies™
If you are familiar with the concept of organizational archetypes – feel free to jump to the next part of the article, where we analyze the Tribes and Squads. Otherwise, here is a quick recap.
The map below represents two essential dimensions along which an organization can mature its design.
The first dimension, the horizontal axis, is fluency in delivering a single customer value item. Simply put, it is how much flow there is when working on a given feature: a) are teams getting blocked along the way with technical dependencies, sequencing the work? or b) are they self-sufficient and work end-to-end with the high flow? In Scrum terms, this is how mature the Definition of Done is.
The second dimension is the vertical axis, and it represents fluency in learning the whole product. It is nice when the teams are end-to-end. But if the teams are only given some low-level product work, and it is the work that they feel 100% comfortable with. You might agree that working on what you already know does not necessarily mean that you are constantly working on the highest value possible. In fact, almost certainly, the opposite is true: working on the same thing forever (or very long-term) means ignoring the business priorities.
This “product fluency” axis is the most overlooked in coaching organizations. This is why we've created the Org Topologies™. In the Agile & DevOps space, there are plenty of talks and books on team efficiency, autonomy, and team-level topologies. We claim that a high velocity of individual teams doesn't mean the entire organization succeeds at discovering and delivering customer value. High team velocity means no more than that the organization is successful in keeping the teams busy. Is that what your organization optimizes for? Hopefully not. If we want to create innovative, adaptive, and resilient organizations, then we should stop paying so much attention to the team-level metrics and start optimizing for long-term product and business success.
So, what is more important: the teams or the product? There is no wrong choice here. We simply need both: team-level fluency and product-wide fluency. This integrated organizational capability, essentially, is adaptability. It means how fluent (fast, easy, cheap, painless) an organization can discover new value and then work on it. In contrast, busy and interdependent teams with their overloaded team-level component-oriented roadmaps make it way harder and more painful to adapt to changing business priorities. So, we need to think in two dimensions: 1) product (or customer value) – around what we build the teams, and 2) teams – how good, flexible, and improving the teams are.
Now that we have a two-dimensional space, we can map different archetypical organizational designs to measure how fluent they are. So let's explore the Tribes and Squads.
Firstly, let's start clearing off the fog from these fancy names. Essentially, a squad is a team. A team on a mission, one can say. And a tribe is a group of teams sharing some kind of high-level common goal. For instance, taking care of the needs of a specific customer segment or the success of some customer journey(s). Essentially, a Squad serves a given business line. A more generic name for this would be a value area. And it is easy to conclude that the teams in a value area should share and work off a single tribe-level product backlog ordered by a tribe lead (product owner).
Ideally, all the teams in a product organization should share all the customer segments and all the journeys. That would be the C3 box on the Org Topologies map. But this is not what the Tribe and Squad model is optimizing for. It is made for creating business-oriented groups of teams (squads) to serve a business line. So let's stick with this optimization goal of the Tribe and Squad model.
Mapping Tribes and Squads: X-Axis
Where do tribes-and-squad organizations belong on our map? Let's start with an X-axis (“fluency delivering a customer value item”). We have a range of options here depending on the teams' maturity. If the teams are dedicated to some architectural elements of the product (components, subsystems, services, platforms), then they are so-called “component teams”. Such teams don't deliver customer value on their own. In order to provide some real value, someone (a manager external to the teams) needs to break down a customer request, assign its parts to individual teams, and then engage in managing inter-team dependencies to get an integrated product feature. That is the first column on the map – the land of component teams and resource management.
If the teams are more advanced and fluent at delivering features independently of each other, then they can span all the way to the 3rd column. And it is a goal of each scrum master, an engineering manager, and first of all the teams themselves to make them as great as possible.
So to conclude our analysis of the Squads and Tribes model, the X-axis: maturity of such an organization is anywhere from the 1st to the 3rd column on the Org Topologies™ map. In other words, it is very much contextual.
Mapping Tribes and Squads: Y-Axis
Now, let's consider the product dimension. The higher an organization is on the map, the more customer-centric concerns the teams can deal with. Let us explain. In the A-row—those concerns are what is mainly known as “technical tasks” and “user stories”. The teams here are given requirements (scope) to work on. This is the lowest level on the Y-axis, as the teams don't have enough view to see how that work impacts the users and the business. Therefore, such teams can rarely measure the value of their changes and improve on those ideas. They can, of course, measure their velocity (the amount of work done per timebox), but this has nothing to do with delivering value. Working fast doesn't mean delivering what is needed. The teams (squads) in such an organization are in execution mode. This is like a factory, where some special people think and decide, and the others simply work on the orders. This is a major under-utilization of human capital in any organization. Do you recognize your organization yet? We hope not!
How does a more mature organization function? Teams of an organization that is one level higher on the map (in the B-row) deal with broader things. Their work is more directly linked to the impact. Those teams are aware of user personas and their customer journeys within a somewhat narrow business line (business area, value area – synonyms). They understand the customer domain within this business area and know how to talk directly with users. The teams speak the customer's language. Therefore, they are aware of how their work impacts users' behavior. Therefore, they can measure and iterate to improve their solutions. The innovation here is high, and so is the impact and learning. It is a creative environment. But can we get any higher?
The teams in an organization, that we map in the C-row, deal with business objectives. The things that are items on their overall, shared, single-product backlog are formulated in a business language. The teams understand and work on the things like higher customer retention, deeper market penetration, expanding new customer segments, and so on. The teams speak the business language and can refine those objectives-oriented backlog items together with the users, experts, and business stakeholders to ideate product hypotheses and feature experiments. Here everyone and every team dreams thinks, experiments, measures, and learns. Note how different this world is from the A-row.
The following map illustrates this idea:
So, where do we put Tribes and Squads finally on the Y-axis?
You can probably answer this question already yourself for your context. Because each implementation of the Spotify model is different. We will share our generalized observations below.
What we see in the industry is that the vast majority of the Squad/Tribe adoptions are at the lowest level along the Y-axis. That is sad news. In those organizations, there are “customer discovery” and “business analysis” specialists and roles. They understand the customer domain and the things like product impact and customer journeys. But one of the cornerstone management beliefs there is that it is “expensive and inefficient” to involve developers in discovery and analysis. And developers themselves start to believe they are not good at communicating with the customer and are happy to “delegate” that work to others. This drives a system where middle-men specialists prepare output-level backlogs for teams. This isolates teams from the world of customers and business. They stop learning. See a map below on output-driven vs. outcome-oriented organizations.
Our Conclusion
It is not up to us to judge your org transformation… But if all the above is true and the squads (teams) are kept focused on the outputs and have individuals backlog, then they have a very limited understanding of the outcomes. Such an organization is clearly in the A-row of the Org Topologies™ map: from A1 to A3.
Agile Transformations: Expectations and Reality
Interestingly, if you read some well-written materials on the model of Tribes and Squads, you see there things like “a team structure mostly aligned to customer and … user journeys” and “dedicated teams to grow selected businesses”. Such an org design would classify at least as an outcome-driven B-row of the map.
In reality, though, when we go and talk to organizations after their “transformation projects” are “successfully accomplished” and the consultants (and the budgets) are gone, we see unexpected things. We see the structures and processes that are incompatible with the ideas of “teams aligned to customer user journeys to grow selected businesses”. We see low-level maturity on both dimensions.
Often there are teams working off individual backlogs full of “pre-groomed” low-level “stories”. Stay there for a sprint or two, and you will notice that the teams frequently get blocked by each other. They are not end-to-end cross-component teams, so there is a lot of waiting, groaning, and wasteful dependency tracking. A lot of managers-coordinators-and-pushers too.
Moreover, because each team is led by its team-level work-output owner, those teams are kept busy working on narrow aspects of a product. Be it a component, a subsystem, a product capability, or a microservice. Have you seen teams such as “search service team”, “mobile team”, “user registration team”, “reports team”, “data mining team”, and “instant messaging team”? These are just some examples. Those names imply that the teams are fixed (forever or at least long-term) to those product parts. This means that the teams will be working only on what they already know. That may sound alright as the teams have a steady, narrow focus and can apply their existing skills effectively.
But do the search, the messaging, or some other product parts always need to be worked on and improved? But what if those backlogs are full of work only because they exist? Or because it is someone's full-time job to fill those lists in? And do we assume that all the changes and improvements of those product parts (like reports, mobile apps, microservices) are always and equally top priority from the viewpoint of the customers and the business? That can't be true. Priorities do change. Users change their minds. Business expectations mutate. Strategies shift focus.
Generally, in such organizations, each team's focus is very narrow, but the organizational focus is spread too broad. Things are moving slowly, and a change is hard. Don't get us wrong. Organizations with such a design function. They do deliver value to their customers and stakeholders. But because of everything that is said above, they are lacking constant market innovation, sharp business focus, and high organizational adaptability. Every change of strategy is a tragedy, not an opportunity. Your organization can do better. And we as an industry can do so much better, too!
Towards Better Organizations (with Empowered Product Teams)
The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for another maturity assessment model. Not at all.
The mission of Org Topologies™ is to help you, a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation, and therefore overall organizational resilience are a great place to grow towards.
So, are we against squads and tribes? Of course, not! If you can envision your target state, any intermediate state can be a good next step. We just want you to keep going, keep growing.
Below is some advice on how not to get stalled, stuck, or lost on your agile transformation journey toward perfection when applying the Tribes and Squad ideas:
Manage the product backlog at the tribe level by someone who is a knowledgeable and respected domain expert with power and budget.
Make that leader the tribe's only product owner who gives work to teams. Promote analysts and other specialists back to the squads as team members.
Having the above-mentioned in place, strive for creating an environment where all squads of a single tribe work together, have a feeling of shared work.
Squads then should meet regularly to agree on how to pull items from the single outcome-oriented backlog, respecting the product owner's priorities.
This way, the squads will be sharing work and learning together, enriching organizational capability to innovate and adapt.
The squads and its product owner (the tribe) and the general management of the organization should work together to remove systemic impediments – things that are getting in the way of implementing the above five points. This way, the tribe as a whole will be improving over time. And so is the organization.
© 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™.
