Fluid Scrum Teams — An example

Here’s how fluid teams can self-organize to manage complexity

A while ago I introduced the concept of Fluid Scrum Teams. It sparked quite a discussion! Many responses were very positive and I am thankful for that. Others were reserved and some people were downright hostile to the idea.

What was the idea again? Well, fluid teams organize themselves based on the work at hand. Every time new topics need to be addressed, the larger pool of people organize themselves to optimize the chances to succeed with their challenges. The pool of people of 20 is a stable and cohesive team. They form smaller teams each Sprint to maximize their effectiveness.

To clarify the concept of Fluid Scrum teams, I will now discuss a practical example. With it, I show how it actually works. Meanwhile, I will address some concerns that I received as feedback on my article.

The main concerns were the following:

• Fluid teams are a nice idea in theory, but it will not work in practice. Especially in a well-established organisation.
• Fluid teams will lose cohesion and a sense of togetherness. They will cease to be a true team. As a result, they will be less effective than stable teams.
• Fluid teams will be fragmented in their focus and lose sight of the single objective.
• Fluid teams are (another) tool for management to abuse by assigning the people to specific tasks without their consent.

These issues don’t have to occur at all. On the contrary, some of the topics, like the focus on the overall goal, are strengthened with fluid teams. To clarify this, let’s now discuss that example!

Example “The challenging product?journey”

The company has the objective to enhance its customers' experiences by introducing an online reporting tool. The challenge of this functionality is that it will display everything that happens immediately. As we are talking about millions of payments a day, this is quite a challenge.

The market in which the company operates is particularly volatile. Developments follow each other very fast and the company needs to be on top of them.

The product has the potential to disrupt the market. But it has unknowns that may put the endeavour at risk. The most important three unknowns are:

• Can this online product actually handle the required capacity? The payment flow is huge. Especially the real-time replication of the data could be challenging.
• How difficult is it to create this product end-to-end? The company doesn’t have any experience with this type of product. They need to reduce the risk of unknown challenges quickly.
• What is the actual need of the customer? Is our product indeed as valuable as we expect? The company needs to verify if the product has potential, but also what functionalities will be most appreciated.

The journey has more unknowns, but these three need to be addressed asap, within a month. Based on the learnings, the team can then focus on the other challenges.

Team composition

The product will have software and hardware components. A group of 17 people is responsible for creating this product. The pool of people in its entirety has people with multiple skills, but they are primarily specialized as follows: 3 front end developers, 3 back end developers, 4 testers, 1 UX specialist, 2 database admins, 2 data lake specialists, 2 infra specialists.

Below is a depiction of the complete pool of people. For clarity of the article, I only depicted the primary skills of the people. Adding the additional skills and how they impact the options would make things too complex for you as a reader.

The expectation is that this pool of people has all the skills required to create the product. The intention is to keep this group together for a longer time to maximize stability.

Sprint 1 — Determining Sprint?Goals

So, the pool of people needs to clarify two technical concerns and also wants to understand quickly if the product has the potential to succeed. The Product Owner suggests tackling the technical issues first and the team agrees.

They have the following topics to address immediately:

• The main concern involving capacity is whether the replication process can manage the load. While other aspects of the product should be checked too, this is unchartered territory and needs immediate attention.
• The other question that needs a swift answer is if the end-to-end solution can actually work.

This is why the pool of people picks the following two objectives for the upcoming Sprint:

• Prove that the replication process can handle both the expected load.
• Prove that the end-to-end solution is technically feasible.

Sprint 1 — Organizing into two fluid?teams

Now that the Sprint Goals are clear, the people self-organize to create two teams for the Sprint. Both will address one objective.

Objective 1 — Functioning replication process

Infra specialist A, database admin A, data lake specialist B, Front end developer B, Backend developers B and C and tester C and D volunteer to work on objective 1. This objective will be their Sprint Goal.

Objective 2 — End to end Proof of Concept (POC)

The other 9 (infra specialist B, database admin B, data lake specialist A, backend developer A and C, the three front-end developers, the UX designer and tester A and B) will attempt to prove the end-to-end solution works. They have the POC as their Sprint Goal.

Here’s how the two Fluid Scrum Teams are formed for Sprint 1:

Both teams will self-organize during the Sprint. They will be focusing on their respective Sprint Goals autonomously.

Sprint 1 — Sprint?Review

At the Sprint Review, the first team managed to show how the replication works. But two parts of the replication functionality need to be altered to make the solution stable. This requires immediate attention.

The other fluid team has successfully created a POC of the end to end functionality. There’s one small issue with grabbing the data from the data lake. This should be fixed for the first increment of the product.

The pool of people and its stakeholders agree to also focus on creating a first version of the product. They will focus on displaying all the potentially fraudulent payment attempts.

The Product Owner proposes to have these three as goals for the next Sprint and the entire team agrees to pursue these.

Sprint 1 — Sprint Retrospective

The two fluid teams first have their individual retrospective. After this, everyone will sit together for an overall retrospective. This works just as in the LeSS framework. Many techniques exist to have effective discussions with a larger group of people. Personally, I recommend Liberating Structures.

Sprint 2 — Organizing into three fluid?teams

At the start of the Sprint, the two temporary teams are no more. The pool of 17 people starts the new Sprint as one team.

The experiences from the previous Sprint, culminating at the Sprint Review, clarified the team should address three immediate concerns:

• Objective 1 — They wish to show that replication meets all requirements after fixing two issues in the current functionality.
• Objective 2 — They wish to repair the issues from the POC. This requires fixing the problem with grabbing data from the data lake.
• Objective 3 — They want to present the first working version, displaying all potentially fraudulent payment attempts.

After some discussion, everyone agrees with taking on all three objectives in the next Sprint. This means the pool of people will divide itself into three Fluid Scrum Teams. They self-organize into teams from their objectives.

Objective 1 — Fix replication

Backend developer A had worked on the end-to-end solution last Sprint, but she is the expert on the replication areas that need fixing. The same is true for infra specialist B. Data lake specialist B and tester C will also chip in.

Objective 2 — Fix POC issues

Backend developers B, data lake specialist A, database admin A and tester D will work on the POC issue.

Objective 3 — First functionality

The rest of the pool will work on the first increment. This includes all front-end developers, tester A and B, the UX specialist, backend developer C, database admin B and infra specialist A.

Here’s how they are organized for Sprint 2:

For this Sprint, 3 Fluid Scrum Teams all have one objective to focus on. As in the first Sprint, each team works autonomously. All three teams have a topic that will bring value. Two will improve the technical solution and one will work on showing the first functionality.

The journey continues

From here, they will continue to reorganize themselves around the objectives. This team is merely at the start of its product journey. They will continue to face challenges of a great variety, requiring a different mix of people to fix them every time.

The pool of people is a stable team. Everyone is committed to their mutual goals. They self-organize into smaller teams to have the maximum focus on the topics at hand and have maximum flexibility.

Debunking the?concerns

At the start of the article, I mentioned four concerns from people that responded to my fluid team introductory article. Here’s my response.

Concern: Fluid teams are a nice idea in theory, but it will not work in practice. Especially in a well-established organisation.

Response: I have seen it working in several environments. Other people responded to my article with the remark they recognized the concept from their own experiences. They also used it successfully.

Concern: Fluid teams will lose cohesion and a sense of togetherness. They will cease to be a true team. As a result, they will be less effective than stable teams.

Response: The pool of people is a stable team that shares a common Product Goal. They also have most of the Scrum events together. The issues of a larger team (problematic communication and collaboration) are resolved by having smaller teams for the daily work.

Concern: Fluid teams will be fragmented in their focus and lose sight of the single objective.

Response: The pool of people shares a common goal with the Product Goal. They will indeed work on different Sprint Goals (as Fluid Scrum Teams) but they are all aligned with the Product Goal.

Concern: Fluid teams are (another) tool for management to abuse by assigning the people to specific tasks without their consent.

Response: Fluid Scrum Teams are self-organizing. Management has no role in the choices they make involving the work they do during their Sprints.

Do you want to write for Serious Scrum or seriously discuss Scrum?