top of page
video-course-spring-2024.png

Case Study: from Component Teams to Team Topologies to FaST Agile

Updated: Jan 19

This article is a detailed analysis of James Shore's talk at the AgeofProduct. We recommend watching the full video of the talk.


We're looking at this case study from the viewpoint of Org Topologies™ to understand better the chain of transformations he is describing in this talk. The story he is sharing spans several years while he was helping a company to move away from a rigid multi-team constellation of component teams to an org design based on mainly stream-aligned teams of Team Topologies® and later on to a more fluid FaST-ecosystem.


The meta-level goal of this article is to demonstrate the power of Org Topologies™ as an approach to visualizing and communicating org design and org change ideas. Thus, this article contrasts three different organizational designs showing their significant differences.


First Org Design: Component Teams


In the video, James Shore first shares his definition of component teams:

In the Org Topologies™ language, we are trying to avoid the black-and-white definitions like 'component teams'. That's why we have a map of 16 archetypes, with 7 of them being the most recognizable.


If we map the 'component teams' as James describes them, they will be represented by the orange post-its on the map below as Y2 and Y3 archetypes. The exact classification will depend on how incomplete or complete those work units are in terms of their technical capabilities:

In James' words:

"Component Teams ... is the most common thing I used to see and actuallty the most common thing I still see today....
This is where each team is focused on a particular technical part of the system... A front-end team and a back-end team... The database team... Or the Ops team... People who are focused on specific technical areas.

James was hired to help that organization with component teams because "the work was grinding to a halt." This is not surprising if we analyze an ecosystem of such teams:

  • structurally, such teams cannot independently ship customer features or work on business objectives end-to-end (that's why they are mapped at the Y-level, the task focus level. They can't complete user features);

  • they cannot see the bigger picture, simply because that is not their focus;

  • therefore, such teams require external specialists and functional groups to provide them with detailed requirements and task breakdowns and help them coordinate and integrate their tasks into a shippable valuable piece of software.

An organization that has such an organizational design will have many blocking dependencies, hand-offs, queues, coordinating roles, upfront plans, dependency boards, and integration issues to manage. Such an organization will be too busy dealing with its world of self-imposed complexity. Rather than being customer-focused, outcome-oriented, and product-centric.


The mapping below depicts all the overhead archetypes that are needed to complement the Y-level archetypes for the whole system to deliver a working product (individuals and groups dealing with analysis, design, coordination, integration, operation, etc.):


No surprise such organizations would want to improve, eventually. But in our experience, the required management awakening can take years. Why is it so hard to change?

An org design with component teams is very sticky.

First of all, the developers in component teams might not see a problem at all! They strongly focus on what they are good at (and everyone likes to have focus). They feel a strong sense of ownership (of components). All the excessive complexity such a component organization needs is handled by people external to the developers. So, the developers usually don't feel the burden.


Sometimes, when you talk to the developers of component teams and ask whether they know of many cross-team dependencies, they might surprisingly respond: "No, not at all!". Component teams might not see the dependencies, as each team has its task-level backlog that someone external to the team populates and manages. They live in an illusion of independence. "We can do those tasks without any other team," they'd say. And they would be correct. But from the value flow viewpoint, a feature touching multiple components that are owned by different teams has to be broken down into separate tasks. And those separate parts of the feature sit in many different team-level backlogs. Will they be picked up by different teams simultaneously and worked on in a single cadence? Very unlikely. So there are dependencies and asynchronous work that slows down the delivery of value, but one needs to see the bigger picture to see that.


This can be summarized by this famous definition of a cognitive bias described by Daniel Kahneman in his book "Thinking, Fast and Slow":

What You See is All There Is (WYSIATI) says that when presented with evidence, especially those that confirm your mental model, you do not question what evidence might be missing.

The dependencies are between the backlogs, not within them. But these dependencies are not what the teams are looking at... That's why component teams might linger in sweet ignorance of being 'efficient' and 'productive'.


This can be illustrated with the following map overlay:


See how this illusion of independence and the focus on internal concerns (better developers' focus, stronger developers' ownership) create a dysfunctional organization where rich collaboration and joint work of multiple teams becomes almost impossible. James reports that the company had 200 engineers, 300 people in the R&D, and 42 teams. And based on his value-stream mapping analysis, it had 97% of waste or wait time! So they were spending months on something that would take just 2–3 days of work. That was caused by all that waiting and asynchronous, unaligned work of the component teams.


James wonderfully describes in one passage the dynamics and culture such an organization exhibits, showing how such companies "get killed by their cross-team dependencies":

A team would start working on something, but they would need another team to do something, so they would hand off and then they would wait. And while waiting they would take on other work. So when another team came to them saying "we need something from you", they said "sorry, we're in the middle of something" and now that team would wait...

They created what James calls "the spaghetti diagram". Each card represents a team and every line represents a blocking dependency:


Second Org Design: Stream-Aligned Teams


James has helped the organization of 42 component teams to move away from the spaghetti state by redefining the responsibilities and making, what he calls, "full ownership teams.", which is very similar to the "stream-aligned teams" popularized by Team Topologies:


Looking at this organizational redesign through the lens of Org Topologies™, this was a move from a Y-level team setup of entangled component teams to an A-level setup with the majority of teams being able to work on customer features end-to-end. And that is a great improvement!

That organizational improvement helped the company to grow and got up to about 67 teams.


However, with the new design and increased number of teams, the company started running into new problems, which were mostly around product management. And this is not surprising:

Every new solution will create new (better) problems.

In an earlier article, we made an extensive analysis of the Team Topologies, and concluded that such a setup creates a low-level ecosystem:

So the "product management" problems referred to in the story by James are caused by the fact that the stream-aligned teams are focusing mainly on what they are good at already. They build and deliver features that lie within their field of expertise. And that is not a coincidence, That’s intentional.


In the language of Team Topologies: "The goal is to optimize for fast flow of change". Because of this optimizing goal, stream-aligned teams will be given work that is in their field of expertise because that is the fastest way to get that work done. They will be given some set of features in which they can develop deep expertise to be fast at shipping those changes. That's why the steam-aligned teams are mapped at the A-level, the feature focus level. Because of the relatively narrow scope of work, stream-aligned teams "did not truly own a significant portion of the final product" (a direct quote from James in the video). A rhetorical question: what happens when you have work units that are fixed to work only on given parts of the whole (components or feature sets)? You will have dependencies between the teams! But we agree such dependencies are less strong than between the pure component teams. So the new setup is an improvement compared to the previous state.


According to the storyline, the new org design with stream-aligned teams was significantly better than the initial one with component teams. With the stream-aligned teams, you can focus more on external concerns such as shipping features to serve known user needs, getting fast feedback thanks to the fast flow of change, and then improving the product features. That feedback cycle is the essence of agility.


Yet, James also mentions issues related to this design. One issue had to do with not having enough "specialties" such as UX, Security, and SREs (site reliability engineers) in each team. In other words, the teams were incomplete (A2 as per Org Topologies™).


In this phase they had to deal with two different kinds of dependencies:

  • product-level dependencies, due to the narrow scope of work (features) in teams

  • specialization dependencies, due to the incompleteness of skills in teams

The second issue mentioned is of greater importance. It had to do with the architects (likely a C1 archetype, as per Org Topologies™) not being able to constantly match the team structure to the changing business and architectural needs. This is substantial: the "essential agile" team archetypes, as per the illustration above, cannot sustain business-level agility. By design, such teams tend to be stuck at whatever they are already good at (they have a feature focus). Thus, they are not fluent and unresponsive when it comes to changes in the product strategy or changes in the architecture. They can't adapt quickly and easily. They are stuck to build and ship fast what they know how to build and ship (remember: the fast flow of change is the goal for stream-aligned teams).


To keep the organizational design and the business strategy in sync, narrowly specializing teams (like all stream-aligned teams) need to be reorganized regularly. This is expensive and difficult. James concluded in his story that the architect group failed at that task. But our view on that is that the task of realigning the team structure to the strategy is too complex to be performed by anyone regularly. And the scale they had (40+ teams) was also not making it less of a challenge.


So the next step the company was heading toward was to craft an organizational design that would enable true (business-centric) agility. This should be a design where the structure is in constant re-alignment to the business needs. A fluid structure.


Third Org Design: Towards True Agility with FaST


James got excited about the FaST. He learned it from Quinton (Ron) Quartel and Paige Watson around 2019. FaST stands for Fluid Scaling Technology, and is about combining open space technology (a tool for self-organization) with a frequent opportunity to change team compositions.


The reason FaST appealed so much to James, in his own words:

What we were doing in the Team Topologies approach is that we were scaling horizontally. We're adding people by adding new teams... That requires careful design... Ultimately we're talking about making a big design change to the organization and potentially reflecting that also in the architecture... Sort of a top-down approach ... and to be done in kind of a big bang way.

So the self-managed, bottom-up, and incremental approach offered by FaST was appealing to James, being much more in the spirit of agile:

In the FaST approach we're scaling vertically. We're adding people by having more people participating in one virtual team (a Coll