What are Floating Teams
In an earlier post I have described the Iron Triangle of Teaming and how we have to make trade-off decisions between the size of our team, its cross-functionality and member stability.
The concept of Floating Teams suggests an elegant solution to this dilemma. While my brother Stefan has recently written about the idea in his latest book, I have also heard from several companies experimenting with similar team setups. It looks like a promising pattern which seems to work well in many contexts.
What are Floating Teams?
When we use Floating Teams, we basically combine two different teams and move back and forth between both setups. The first one we can call the Pool, which is a group of experts who combine all the necessary skills to develop a product. The pool is cross-functional and stable over time (in terms of team membership)¹, but it cannot be very small - otherwise it would lose cross-functionality. The Pool is a container which should create high team cohesion and responsibility to a dedicated product domain. The work of building new functionality, however, is usually not done within the Pool. It’s done in Story Teams instead. These units are formed around a specific piece of work (e.g. a User Story or a slightly bigger feature). Since not all the Story Teams need all the domain knowledge to build a specific piece of new functionality, they can be quite small and nimble. Once the work on a specific piece of work is done, a Story Team will be dismantled and moved back into the Pool until new Story Teams will be formed.
As we can see in the illustration, the two teams combined cover all dimensions of the Iron Triangle: We have the stable and cross-functional Pool, combined with small (but still cross-functional) Story Teams.
How to Make this Work
The idea of Floating Teams is simple enough, but there are a couple of things we need to get right, in order to reap the benefits without getting too many negative side effects.
The size of the pool can’t be too big. While it is true that the whole point of the Pool is that it can exceed the often recommended size of a product development team (single digits), there are also limits. My recommendation would be to limit it to 30-40 people. The main reasons for this are team cohesion, trust and psychological safety - all of which are much harder to build and maintain in larger groups. A group of 30-40 should be small enough to sustain this feeling of togetherness and accountability and at the same time big enough to “own” the whole product domain, so we can minimize dependencies to other teams.
Maintenance and systems ownership need to be clarified. One big benefit of small, stable product development teams is that there’s a clear mapping of teams to technical systems. This also includes an understanding of who is responsible for bug fixes and handling incidents: You build it, you run it! With Floating Teams there is a risk that we break this feedback cycle, because new functionality is being built by Story Teams, but those teams will often not exist any more, when something breaks. If this happens repeatedly, a natural instinct seems to be to form a dedicated maintenance team (often with a fancier name). This cannot be recommended, so the ownership issue has to be solved in another way. There are different approaches to this, and my recommendation would be to include everyone working in the Pool when coming up with a solution.
High fluidity requires standards. The success of Floating Teams hinges on the ability to form effective Story Teams quickly. Because they are so short-lived, it’s just not economically viable to spend a lot of time on team building and defining the teams’ ways of working. Defining standards and getting buy-in from everyone to accept these standards is one way of reducing ramp-up cost for new teams. Standards can include not only the tech stack, but also things like the usage of a small set of tools, pair or ensemble programming, core working hours, the way how standups are run etc.²
It’s worth noticing that the first point (the size of the Pool) also has an impact on the other two. It’s easier to decide on an effective ownership model and to come up with standards that everyone agrees on, if the Pool is small enough to include everyone in the discussions.
Summary
Floating Teams can be a good way to balance the tensions described visualized in the Iron Triangle of Teaming. By combining small, short-lived Story Teams with a slightly bigger, stable Pool we can get the benefits of small, stable and cross-functional teams. In order to use this model successfully, we need to make sure the Pool does not become too big, we develop a clear ownership model and we introduce some standards to reduce ramp-up cost for building Story Teams.
__________
¹ When I talk about team stability, I refer to stability in terms of team membership.¹ Stefan also uses domain stability (the team works on the same product domain over a long period of time) as another dimension for describing different team concepts.
² I am not saying that we are simply demanding compliance with standards here. We want everyone to understand why we need them and therefore agree to use them. And of course our standards are not carved into stone for all eternity. We should inspect and adapt them on a regular basis, for example when we run big retrospectives with the whole Pool.
Mit vielen Teams viel schneller liefern
Im Juni halte ich zusammen mit meinem Bruder Stefan eine Schulung zum Thema Team-of-Teams. Ort und Termin: 11./12.06.2025 in Hamburg
Mehr Info
