Dynamic Focus Teams - Experience Report

The Starting Point

Our team had reached a size with over 20 members making it impossible to work efficiently. The usual Scrum meetings (Refinements, Estimations, Planning, Review and Retro) took longer and longer and felt incredibly dull. Many issues were discussed in detail during these meetings, but were often only relevant to a small group.

Due to the size of the team and everyone’s strong desire to move quickly, a wide variety of topics had crept in, further fueling the situation. The product team had no focus. Too many things were tackled at the same time, but only a few were completed. At times, each developer worked on her own topic. Yet there was always a need for something from the colleagues. This led to many interruptions and context changes for everyone.

This state is shown in Figure 1. The green lines mark constructive / productive collaboration, the red lines are disruptions and interruptions that hindered the team’s progress.

Due to the large number of topics, real, intensive collaboration between team members was almost impossible. This was not only a problem for the team’s performance, but also led to frustration.

So it was time to act. Thanks to Chrono24’s strong willingness to experiment with new approaches, it was possible for the team (in which the author is Head of Development at the time of writing) to test and gradually improve different ways of working over a longer period of time. First, we looked together at different scaling models of Scrum and decided to test LeSS.

First approach: LeSS

LeSS (Large Scale Scrum) [1] is one of the approaches to scale Scrum. Put simply, it involves multiple teams working on one product with one product owner and one backlog, planning and reviewing together, but go into individual teams for the implementation. In our case, this meant splitting the product team into two equal, fully functional teams.

This sounded very good to us at first: We don’t need to split the topics and can always work with both teams on the most important things. Meetings will become smaller and the teams will be able to focus better. That was our assumption.

Unfortunately, the split did not have the desired effect, as there was still a lot of communication between the subteams (see Figure 2). It took us a while to realize the problem and the root cause here. Ideally, teams should be able to work independently within the sprint, but this was obviously not the case. The reason for this was that the topics that the team was working on usually had a strong focus (UX / frontend / backend). This meant that, for example, the backend developers from both teams worked on different stories that belonged to the same topic and had to coordinate accordingly. On the other hand, the frontend colleagues could not contribute to the topic and worked on other tickets / stories.

Due to this situation, the dailies degenerated into pure reporting. It was usually not relevant what the others in the team were doing, and those with whom one should have coordinated were not there.

To summarize: The skills required of the topics did not match the skills of the teams. At this point there is a lot of room for discussion:

• Shouldn’t a topic still be handled by one team only, even if it takes longer?
• Shouldn’t there be a possibility for everyone to contribute to the topic? Even if it is only through tests?
• Isn’t it also okay if individual roles have some idle time?
• Do we want to go for fullstack development?

The list can be extended indefinitely. We discussed many approaches. We finally decided on the following:

• A topic should always be handled by one team.
• The skills in the team must match the required skills. We don’t want any forced idle time and fullstack development is currently not feasible in this context.

Our approach to achieve this: Dynamic Focus Teams

However, this presented us with a major dilemma:

Do we really want dynamic teams? Doesn’t that violate one of the basic rules of Scrum?

The Dilemma: Stable vs. Dynamic Teams

The dilemma we faced can be summarized as follows:

• To be productive, we need stable, cohesive teams. (Keyword: Tuckman Team Performance Model: Forming, Storming, Norming, Performing [2]).
• To be able to optimally deal with topics, we need flexible teams with the right skills.

We need to be as productive as possible and work on topics optimally so that the company can be successful in the long term.

How can this conflict be resolved?

Forming, Storming, Norming, Performing. These are the four phases through which every new team must pass (according to the Tuckman Team Performance Model [2])) and only in the last phase is a team fully productive. Any change in the team structure results in the need to go through the phases again.

This is one of the basic assumptions of Scrum and speaks for stable team structures [3].

Is that really the case?

We took a closer look at this assumption. Current research [4] shows that storming does indeed occur continuously throughout a team’s lifecycle. Further, organizations should continuously feed team dynamics to maintain high performance over time. In other words, the best teams continually enter the ‘Storming’ state. So dynamic teams can - to a certain extent - contribute to keeping performance high.

Furthermore, the question arises whether these phases always have to be equally intense. In our case, for example, all team members know each other well and the overall atmosphere is open and constructive. There is already common ground on many issues and a good underlying foundation for more flexibility.

In addition, ‘resources’ are not arbitrarily shifted back and forth by management in the company, but rather a limited scope (the old team) exists in which teams can form. The members of the team decide for themselves - at fixed points in time - how to split up among the topics.

Thus, it is possible that although the phases have to be passed the process actually has a positive impact on the performance and satisfaction of the teams. Combined with the focus gained, dynamic focus teams have great potential in this context.

Dynamic Focus Teams

One thing first: when we talk about a topic, we mean a significant extension to the existing product with a clear goal, which can cover the full discovery-delivery cycle.

A focus team works on a topic for 3-6 sprints (6-12 weeks), after which the topic is completed (validated and live). It is possible to define a follow-up topic. However, this has to be newly established versus other, possibly more important topics.

Focus teams are dissolved after their topic is completed. At the end of each sprint, we look at the state of the teams and jointly decide for each team if it makes sense to let the team continue.

Additionally, a core team takes care of the day-to-day business and thus covers the backs of the other teams. This includes critical bugs and smaller stories / tickets. This team exists permanently. The members change with the formation and completion of focus teams, so that the members of this team change regularly.

The introduction of dynamic focus teams has improved communication tremendously, as shown in Figure 3. Each team has a clear focus and goal. Meeting productivity (especially dailies) has increased immensely. We have brought in stakeholders to join some teams who were previously only very sporadically involved in the process. The focus has allowed us to move forward quickly. The teams feel responsible for their topic.

The results are confirmed by a survey we conducted in the teams. The survey was done once in the LeSS working mode and once after the introduction of dynamic focus teams. The goal was to find out how the change affected the collaboration of the teams and the quality of the meetings. The results of the survey (Figure 4) show that we could improve certain aspects massively (Daily, Goal and Focus) and others slightly.

Conclusion

Through dynamic focus teams, we have managed to strengthen team communication, meetings, and focus. Of course, we still have room for improvement. For example, it has become apparent that teams need about one sprint to find each other and get through the topic. Also, moving members between teams turned out to be a somewhat less flexible process than originally anticipated.

Inspired by Shape Up [5], we are currently working on restricting the scope of the topics purposefully and on moving to a fixed rhythm. In the long run, we hope that the concept of ‘fixed time, flexible scope’ will lead to more progress on the relevant topics and to an easier transition between teams.

One final warning: Context matters! Just because we have had success with this structure in our setup does not mean that it will automatically work the same way in other contexts. It is important to proceed systematically in small steps, to involve the team in the solution finding process, and to measure one’ own progress.

The result is an incredible team achievement and has only been possible thanks to the support of Chrono24 and the strong drive for innovation of all involved, especially the team. A big thank you to Jana Schumann, Rouven Schaube, Danijel Nevistic, Sven Ferber, Manfredo Lanzas and the whole team at Chrono24. You are the best!

References

[1]: LeSS Framework

[2]: Tuckman’s stages of group development

[3]: ScrumBook.org

[4]: Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model, Pamela Knight

[5]: Shape Up, Ryan Singer