Re-release: Stable Scrum Teams can limit you to create value — Enter Fluid Teams

Fluid teams self-organize to manage complexity

I published this article two years ago, on Medium. I hope you can appreciate the re-release.

Fluid Scrum teams self-organize to manage complexity

Scrum is a fascinating framework. It exists to create valuable products in a complex environment. It does so by providing structure with distinct accountabilities within a Scrum Team, with artifacts and with events. This all happens in Sprints that are of a fixed length.

I like Scrum, but it tends to be used in a different way than intended. To explain what I mean, I will start with a quote from the Scrum Guide:

In complex environments, what will happen is unknown. — Scrum Guide 2020

This is an important statement. In complex environments, you have assumptions that you need to verify. Then, you can take the next step. Scrum helps to manage complexity.

However many people also use Scrum with the aim of reducing complexity. Examples of this are efforts to optimize the flow of work and the predictability of the team. For this to work, teams need to be as stable as can be. Ideally, the team has no changes in their composition for a longer time. Another important prerequisite for this is that the way of working has an impact on the overall complexity. By improving the way of working, the product environment becomes less complex.

Do you recognize this? Many teams will. Does it work for you? That’s great! And you are not alone. Stable teams are a Scrum Pattern. These patterns are practices that have proven to work in complex adaptive environments.

But what if the complexity of your environment calls for a different mix of skills with every objective? What if every topic you need to address is vastly different from other topics? What if this calls for a different way of working every time? Would you still strive for stable teams and predictable flow?

I believe this is not the case. In particularly complex environments, you may need different people for every problem you wish to solve. These product environments may benefit from Fluid Scrum Teams.

In complex environments, you may need different people for every problem you wish to solve.

Scrum with multiple teams

Scrum is a framework that aims to maximize the value of products in a complex environment. This happens with one team or with multiple teams. It is key that these teams are small, with a maximum of ten people.

If more than 10 people work on the product, they should create multiple smaller teams. They all work from the same Product Backlog and do their Sprint Review together. After all, Scrum’s focus is on the product, regardless of how many teams work on this product.

Scrum is a framework that works perfectly well with multiple teams. Let’s discuss Fluid Scrum Teams now.

What are Fluid Scrum Teams?

Fluid Scrum Teams organize themselves based on the work at hand. It is a vital aspect of approaches like Open Space Technology and FAST Agile.

Here’s how Fluid Scrum Teams work. Suppose your pool of people is 20. These people organize themselves into 2 to 7 teams to address specific topics.

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” — Scrum Guide 2020

Every time new topics need to be addressed, the people of the Fluid Scrum Teams organize themselves to optimize the chances of success of the challenges. The team of 20 is stable and cohesive. They form smaller teams each Sprint to maximize their effectiveness.

Fluid Scrum Teams depicted in the Stacey Matrix — Willem-Jan Ageling

Fluid Scrum Teams and Scrum events

How does this work in practice? Here’s an example.

At the Sprint Planning, all the developers that work on the product, the entire pool of people, are present. The Product Owner proposes a number of objectives for the upcoming Sprint. Now follows a discussion to agree upon the objectives.

Then, the people of the Fluid Scrum Team self-organize themselves around the objectives. They decide how to split into multiple teams that will work on their own objectives during one Sprint.

The teams have their own Daily Scrums and at the end of the Sprint, there’s one Sprint Review reflecting upon the outcome of the work of all the teams. In every Sprint, different teams will be formed to address the objectives.

Fluid Scrum Teams and Cross-functionality

Scrum stresses the importance of cross-functional teams to address complexity:

“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” — Scrum Guide 2020

But how do you know you have the right people to address all the complex problems now and in the future with stable teams? In complex environments, we don’t know what will happen!

Enter Fluid Scrum Teams. With a larger pool of people, you also have the possibility to have more skills in the team as a whole. This allows for more options to find the best ways forward.

Another benefit is that it resolves the constraint of stable teams. Picture this: Team A has the same composition all the time. It wishes to work on topics that will allow every team member to be useful.

But what if the skills of a certain person in the team aren’t needed to meet the objective of team A for a Sprint? Team A has no other option than to find something for this person that’s either separated from the major objective of the team or not using the strength of this person.

With Fluid Scrum Teams, this person who would be hardly useful for stable team A could be focusing on another topic with a different group of people. Fluid Scrum Teams increase the chances of effective contributions of the people.

Fluid Scrum Teams and self-management

Fluid Scrum Teams are fully in line with the concept of self-management:

“They [the Scrum Team] are also self-managing, meaning they internally decide who does what, when, and how.” — Scrum Guide 2020

Every Sprint, the developers of the fluid team organize themselves around the objectives. They determine who does what. Fluid Scrum Teams have more control over what they are working on than stable teams.

Because with stable teams, the Product Owner would already determine the objectives of every team before the Sprint Plannings. With Fluid Scrum Teams, the Product Owner allows everyone to decide which objective they wish to tackle.

This is also helping to increase the sense of ownership of the entire product. As a result, it helps to fulfil the accountability to maximize the value of the entire product.

Levels of fluidity

I discussed Fluid Scrum Teams and stable Scrum Teams as two opposites. But there are several variations.

Complete fluidity

In every Sprint, the teams that are formed can be totally different, depending on the problems at hand. This is a solution for environments that are especially complex and every new problem is distinctly different from previous problems.

Partial fluidity

A part of the pool of people is working in stable steams addressing topics of a certain nature for multiple Sprints. Another part is fluid and organises again and again. This approach is helpful for environments with elements of high complexity and also elements of lower complexity.

Specific fluidity

A smaller group of people with special skills are assigning themselves to teams based on the need for their skills. Many organisations work like this. Especially when they have people that can’t work with a single team full-time. Think architects, database administrators, network specialists, and salespeople.

Fully stable teams

The teams will not change for a longer period. In every Sprint, the teams have the same composition. There’s zero fluidity. This can be a good approach for environments that are complex but with a high degree of predictability of the type of work at hand.

In complex environments, Fluid Scrum Teams can increase agility

Scrum exists to create value in complex environments. Most Scrum Teams aim to do this by embracing stability and predictability. They focus on optimizing flow and predictability to reduce complexity.

Often this is not feasible. In especially complex environments, what will happen is unknown. You can’t reduce the complexity. You have to manage the complexity.

One way of doing this is by working with Fluid Scrum Teams. Fluid Scrum Teams organize into smaller teams to tackle a specific issue. Every time they will organize themselves differently because of the different nature of the issues at hand.

By relaxing the constraint on stable teams, your teams will be able to handle increased complexity and tame the chaos.

Here’s a link for all current material on Fluid Scrum Teams. If you can’t access it, you can reach out to me.

Fluid Scrum Teams - All current material