Adopting Fluid Scrum Teams in a multi-project software team
Fluidity within a project-oriented team
Fluid Scrum Teams are an idea of Willem-Jan Ageling, which he published in September 2021. This approach enables a team (in the article’s case, around 20 members, which required coordination and communication) to break-down, self-organize and to tackle their different problems at hand. The approach originally describes how to face different features of a same product. I describe in this article how we used this approach in my team, for facing different projects.
1. What are Fluid Scrum Teams?
Essentially, Fluid Scrum Teams allow the team to set focal points in Sprints and create low-adhesive groups to create value and work on Backlog Items. The idea behind it is that you may set up a specific Scrum Team for a Sprint from a pool of people (for example, in the original article, creating a subteam from a pool of 20 people), based on the current needs. Then, in the next Sprint, there are other different needs, and you might set up a different Scrum Team.
“Fluid Scrum Teams organize themselves based on the work at hand… 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.
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.”
Because of the complexity of work, the concept of Fluid Scrum Teams allows enough flexibility to work as a team on the Sprint Backlog but also to create enough cohesion on specific topics. Sure enough, this could also just be seen for the developers to set up within the Sprint for themselves — but especially with several data products it proved helpful for us to align beforehand in the Sprint Planning.
At the Sprint Planning, all the developers that work on the product are present. The Product Owner proposes a number of Sprint Goals for the upcoming Sprint. Then, the people of the Fluid Scrum Team self-organize themselves around the Sprint Goals. They decide how to split into multiple teams that will work on their own Sprint Goal during that Sprint. They determine who does what. Willem-Jan dedicated an article for Sprint Planning.
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. Every Sprint, different teams will be formed to address the objectives.
2. Our context
To better understand how we adopted Fluid Scrum Teams the way we did, let me first describe how my team is organized. We are a team responsible for delivering software projects in different business units of the company. Our natural way of team organization would be to have a stable team per project. However, the projects didn’t demand the same effort over time.
Each of the projects has a person with a Business Analyst (BA) role assigned to define each project’s roadmap and to assure that the project’s customer had their needs visible.
In the past, every time a BA identified a customer need (or a set of needs), and after a validation from the sponsor that there was budget available to it and only after there was a certain number of needs gathered, there was an Analysis of the team’s current work to form a Team for that Project. Only then we created a Backlog and start organizing the delivery in Sprints.
It was not ideal from the customer’s point of view, as they had to wait a long time between their meetings with the BAs and the time they actually saw the Project Team working on it.
When we got the chance to read the article from Willem-Jan, we experimented if such fluidity was what we needed.
We no longer had to split the Team in sub-teams for the projects. There wasn’t a need for dedicated backlogs. By having a unique pool of all needs, there were always needs available to start working, and we hoped that the Team could self-organize and start working towards the delivery of the features in a fluid way.
From the point of view of each client, the BA plays the role of the Product Owner of the project, being responsible for the backlog (of each project). From the team’s point of view, there is a Business Unit Leader (BUL) figure, that we could say is like the team’s PO. It’s not to say that it’s like a PO of (the other project’s) POs, but rather in the sense that she defines the team’s roadmap and the priorities in a unified backlog (which is a gathering of all projects’ backlogs created by the BAs).
There are also different levels of fluidity (see before the conclusion of this article). As already described, there can be Fluid and stable Teams working together. In our case, we also had a stable Team working in a specific Project. For example, in the image above, Project A had more consistent work over time. For that reason, Project A had a stable team configuration.
Having described our context, there are things about Fluid Scrum Teams that we adopted the same way as in the original articles from Willem-Jan, and other things we adjusted a little bit. That’s what I describe in the article now.
3. What we adopted from the Fluid Scrum Teams
Just like in the original article, we conduct delivery iterations by Scrum Sprints, using a single Sprint Backlog for the different Teams (stable and fluid teams). Each person on the team volunteers for Backlog items as they see fit, regardless of the project it is. A person is not allocated to a specific project.
For the Sprint planning, we adopted a similar way as a pool of Backlog items — just like the image from the Sprint planning article and used in this article as well (sidenote: as a joke, we called that image with the Sprint goals as Mickey Mouse planning….). It includes spaces for bugs and fixes, enhancements, and technical work. Each of these has space allocated for each Sprint Goal, like a checklist. Visual boards are very useful for this (either the Mickey Mouse ones from the article on Sprint Planning, or also different ones like this article).
Regarding Sprint Review and Retrospectives, we conduct them the same way as in the original article. They are based on the single sprint backlog and with participation by the entire team, rather than split them by the different projects. In short, all team members (stable and fluid) participate in all Scrum events. I describe our daily Scrum meetings in the next section.
4. What we adopted differently
The main differences between the way we used Fluid Scrum Teams and the way it’s described in the original article relates to its events.
In the article, the difference between Sprints planning and daily Scrum and reviews, is described as below:
“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.”
This means that teams come together in the Sprint planning and members volunteer to Backlog items from different Sprint goals. And, after that, they split themselves in separate events, like the daily Scrum.
In my team, we didn’t split ourselves. The Daily Scrum is unique, it is a team event and not a project one. Mainly, because the team is composed by 12 members, we felt it wasn’t big enough to justify such a split. One of the pitfalls relates to duration, as this event lasts us always around 30 minutes. We also decided to keep sharing all projects in only one single event. Our justification for doing so is that members from other projects can be engaged in the Daily Scrum because they can be a good fit for the configuration of a new fluid team in upcoming Sprints.
Members volunteer for a (set of) Backlog item(s). They sign up for item(s) that may not all be part of the same subteam and their output is only checked at the end of the Sprint.
During a subteam’s configuration, no one may require a person to sign up to a particular item in the detriment of another. There can be a case where one may desire a specific member to sign up for a specific Backlog item, however that’s not ideal (as a person as a PO, for example, detailing tasks and assigning them to anyone in particular, it’s actually an anti-pattern in Scrum).
Sprint Planning is based on the roadmap defined for the team, with the BUL having the role of proposing items in the sprint backlog. The BUL prioritizes in accordance with the BA(s). In case of disagreement with the BAs, the last word on what goes into the Sprint Backlog belongs to the BUL.
5. Level of fluidity
Finally, I revisit the variations in fluidity presented by Willem-Jan, and namely which one my Team is classified.
● Complete fluidity: Every Sprint, the teams that are formed can be totally different, depending on the problems at hand.
● 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.
● Specific fluidity: A smaller group of people with special skills are assigning themselves to teams based upon the need for their skills.
● Fully stable teams: The teams will not change for a longe nor period. Every Sprint, the teams have the same composition.
My Team has partial fluidity, as we have members whose projects allow for fluidity about How they assign themselves to Backlog items, but other members work always in the same project (the ones working for Project A dashboards features).
5. Pros and Cons
Adopting Fluid Scrum Teams had their pros and cons, of course.
As pros, we may definitely say that we earned much in:
- Fluidity: no need to form small teams for the sake of a specific project — often, short-duration projects
- Communication: when holding a single Daily Scrum, everyone could talk directly to others
- Motivation: the possibility to work on different projects overtime was a motivation point for the team, as allowed them — in their words — “not to work always in the same thing” and “trying something new”.
As cons:
-
- The Daily Scrum timebox increased to 30 min
- Sprint Planning, Review and Retrospective address a wide range of subjects, as all projects are discussed, but it’s easy to have meetings where one of the projects is focused and consequently only a small part of the team actively discusses it.
6. Conclusion
When your team is organized around projects, however projects are not enough to have steady work over time, it may be worth looking at Fluid Scrum Teams.
Using Fluid Scrum Teams allowed us to have always available work for the team members, regardless the project (or customer needs) currently in progress.
Fluid Scrum Teams allowed us to have unified Sprint backlogs composed with different projects.
BAs and BUL work together towards a unified and prioritized Backlog with needs for the different customers.
All Scrum events address all Sprint goals with all Team members, which is a difference relating to Fluid Scrum Teams.
7. Links to resources about Fluid Scrum Teams
- Stable Scrum Teams limited us to create value — Enter Fluid Scrum Teams: https://medium.com/serious-scrum/stable-scrum-teams-can-limit-you-to-create-value-enter-fluid-teams-3df4f2108219
- Fluid Scrum Teams — An example: https://medium.com/serious-scrum/fluid-scrum-teams-an-example-9acd0a4d0bf0
- Fluid Scrum Teams vs Fixed Scrum Teams — A comparison: https://medium.com/serious-scrum/fluid-scrum-teams-vs-fixed-scrum-teams-a-comparison-8bb49a1ac089
- Fluid Scrum Teams to Address the Complete Product Experience: https://medium.com/serious-scrum/fluid-scrum-teams-to-address-the-complete-product-experience-c9f50ee144ae
- The Sprint Planning with Fluid Scrum Team: https://medium.com/serious-scrum/the-sprint-planning-with-fluid-scrum-team-1dfac3614530
- Using Fluid Scrum Teams in Data Products Development: https://www.inovex.de/de/blog/using-fluid-scrum-teams-in-data-products-development/
- how to improve flow between Stable and Fluid Teams by using the unFix model: https://www.youtube.com/watch?v=EJOD65Q5ihU
To understand the theory behind fluid teams, it may be worth taking a look also at:
- Fluid Scaling Technology (FaST) guides: https://fluid.scaling.tech./guide
- Dynamic Reteaming: https://www.agilealliance.org/resources/experience-reports/dynamic-reteaming-how-we-thrive-by-rebuilding-teams/
- Fluid teams: https://www.parabol.co/blog/fluid-teams/
