Fluid Scrum – an Experiment

How can product development, daily business and maintenance in long-running projects be reconciled as efficiently as possible? This question I kept asking myself as the teams' Scrum Master. For one of our clients I found the answer in Fluid Scrum. Goodbye silos, hello product passion!

Initial Situation

We provide two development teams for one of our longtime clients. Both teams together consist of a total of 9 developers in a good ratio of longtime tenure and some newcomers. They share their Scrum Master and Product Owner.

Team A handles the continuous development of the product and goes by? Scrum; they have just released the Minimum Viable Product (MVP) of the prevailing product goal “redesign with technical relaunch”. This means: The future steps in the product development will be significantly smaller and the created increment must be further developed and maintained.?

Team B is responsible for daily business, maintenance and – at least in theory – for the development of smaller features, which often cannot be attended due to their high workload. This team (B) organizes their work with the help of a Kanban board. It performs regular Retrospectives and participates in the Review meetings with team A and the client. However, the proportion of visible work done by team B seems rather small as they mainly cover team A’s back.

Challenges and Questions

Now that the MVP is live, the next product goal is less extensive. Additionally, team B is to be relieved and the knowledge acquired during the work on the previous product goal is to be shared.

The complex question I was now asking myself as the teams’? Scrum Master was:

What does an optimal team setup for the future look like – a setup which on the one hand ensures that both daily business and maintenance as well as product development are considered in a balanced manner and on the other hand is still flexible enough to distribute the capacities in the front and back end as required??

In close exchange with the Product Owner and my colleagues, we gradually came to the following conclusion:

Hypothesis

The teams have reached a mature agility level and can face the described challenges with sprint-based, flexible team distribution. Thereby, knowledge will be shared continuously and frustration due to monotonous work will be prevented.

Preparation

For this – admittedly somewhat bold – hypothesis to come true, two things had to happen simultaneously: The future team (i.e. the union of the teams A and B) had to be enthralled for the innovations and the experiment had to be well prepared to have a chance of success.?

From the very beginning, it was set that this was only an experiment for us. In our conception of agility, it absolutely takes courage to try new things, but at the same time it also takes courage to declare something as failed.

Willem-Jan Ageling ’s explanations were of great help during our planning phase. It felt great to read that others had thought of a model similar to the one we imagined for us and that there was even a name for it: Fluid Scrum.?

After some elaboration, we presented our idea in our weekly team meeting. Colleagues were very interested and curious, but there were also critical opinions. Many things could be discussed immediately, other uncertainties and questions were taken along. All in all, it was a successful pitch – what a relief!

At some point – after ongoing discussions within the team and with individuals, various visualizations in Miro and a difficult search for time slots in Outlook – it became clear that good preparation and planning is one thing. On the other hand, one should not wait too long with the kick off to not let the initial motivation and energy go to waste. Hence, we decided to start our first Fluid Scrum Sprint the next month.

To provide a good foundation for the future collaboration, we held several productive meetings for the joint development of a Definition of Done and the next product goal which paid into our joint understanding and commitment.?

Execution

As our entire and now united team had switched to “full remote” during the pandemic, all of the Scrum events described below are virtual appointments. Since the Sprint process does not differ significantly from that in non-fluid Scrum, I will only dive into the differences and start with the Sprint:

Sprint:?

The duration of the Sprint was extended from previously two weeks to four weeks. This adjustment was not directly related to the switch to Fluid Scrum, but it should be mentioned here as well.

Sprint Planning:?

The Sprint Planning starts with the whole team, i.e. the developers, me as the Scrum Master, and our PO. The PO presents the Sprint Goals and the complete team looks collectively at the tickets to see which pay into each goal. Subsequently, the developers decide which Sprint Goal they would like to contribute to next. Here, it is not only important to consider where they can best apply their existing know-how, but also where they can gain new knowledge.

Further questions are whether the cross-functionality for achieving the Sprint Goal is given and whether the teams are still properly equipped to ensure quality assurance through code Reviews. Once the fluid teams have been formed, the detailed planning continues in breakout sessions in the subteams. These don’t differ from the conventional Sprint Planning anymore. After the planning meeting, the teams start working in their fluid teams that have been defined for the duration of a Sprint.?

Daily Scrum:?

There is one Daily per fluid team, with one representative from each team attending the other Dailies to identify and discuss any potential dependencies and intersections between the subteams. The Dailies are planned back to back. In our case, Product Owner and Scrum Master also participate in them. Here the PO has the opportunity to bring in work that arises on short notice and couldn’t be taken into account in the Sprint Planning. Together, we consider which fluid team will take over these tasks and pull the respective tickets in the fastlane on their Sprint board.

Sprint Review:?

There are no formal changes to the Sprint Review as we have previously conducted it together with both teams. In terms of content, however, it has improved due to the focus on the Sprint Goals, as value created can be classified much more clearly this way.

Sprint Retrospective:?

At first, we started with one Sprint Retrospective per fluid team, but after two iterations, we noticed that the close collaboration leads to a redundancy of topics. Hence, we hold the Retrospective with the whole team which still feels good and right so far and is still manageable with a team size of 11 people (including Scrum Master and PO).?

Product Backlog Refinement:?

While the Refinement isn’t a Scrum event in the conventional sense, I would like to mention it here as well, as we schedule it as a regular meeting. Since it’s not foreseeable who or which fluid team will work on which task in a Sprint, we usually hold our Refinements with the whole team. During the Refinement, the tickets will be presented and further specified, acceptance criteria will be defined and already known technical information documented. Subsequently, the task’s complexity will be estimated in Story Points using Planning Poker. If required, there will be additional refinement processes in the running Sprint which will then be held with a representative group instead of all developers.

Observation

After five Sprints, we can see a Velocity in Story Points, which – due to the flexible combination of team members – can only apply to the whole team. Even though this will surely consolidate in the next Sprints, we already sense a way better predictability.?

Out of the five Sprints, we performed three with two fluid teams, one with three teams and one with the entire team. During the Sprint with three teams, a mini-team of two developers was able to significantly advance a topic that probably would not have been prioritized in a traditional Sprint – a clear advantage of Fluid Scrum. We will surely use this opportunity of encapsulating and working on a topic as a Sprint Goal more often.?

Altogether, it turned out that well-formulated Sprint Goals are a key factor in many respects: They help with planning and facilitate the process of dividing the team into fluid teams at the beginning of the planning. The goals also guide the focus during the Sprint and the classification during the Sprint Review. From my perspective, it was absolutely right that the latest version of the Scrum Guide sharpened the focus on the Sprint Goal by linking it to the Sprint Backlog artifact.

Perhaps the greatest uncertainty at the moment is still found in handling the Refinement activities. Considering that at the time of the Refinement it is not clear in which Sprint and with which fluid team composition the work will be done: How can we ensure that the right people take part in it?

Conclusion

At the end of the fifth Fluid Sprint we are optimistic that our experiment was successful and that we will establish a demand-driven practice using Fluid Scrum. The uncertainties that occur are well manageable. They even help us to remain vigilant and to continually improve the process following the Scrum pillars of Inspect & Adapt.?

So we draw the following conclusions:

• Fluid Scrum has proven to be a good tool for our challenges described at the beginning of reconciling product development and maintenance.?
• We have also made progress in the area of knowledge transfer thanks to the new teams formed for each Sprint.?
• It’s fun to see the teams working together very closely and at a higher level than in their previous form of self-organization.?
• Fluid Scrum works pretty well for us!