Reteaming — often
or how to build a great product while on a boat
If something is hard — you should do it often
The challenge
When I started at Storytel our team consisted of six developers. My first task was to grow the team, and after an intense period of recruitment, we were 15. It was clear that we could not continue working as a single team. The normal symptoms were showing up: long standups, a lot of handovers, and lengthy meetings were necessary. The efforts of planning and continuously reporting status was becoming a big overhead.
The knee jerk reaction in this situation is to break the team up into smaller groups (at Storytel we call them crews). We know the best work happens in small, cross-functional groups that can focus on a single mission. Our team has a strong culture, and we wanted to keep working together. The nature of the work we do is flexible and we usually don’t do long-running projects. We decided to try something different.
The idea
Instead of having permanent crews, responsible for a small area of the product, we decided to organize around the work, and shift as the work shifted. That would mean creating new crews as often as the work changes. I started sketching on a new way of working.
One source of inspiration was another team at Storytel, working with our payments. About a year earlier they decided to try reteaming as an alternative to permanent crews. This was a great inspiration and showed us that you can get great results in working this way. 🎩 off to Emil Tinebo and his team.
The analogy that came to mind was the naval theme of boats. This later became a source of inspiration for countless jokes. I will describe the initial idea, the design of the reteaming system, and a few challenges we have encountered so far.
Basics
Each boat has a crew of 2–5 people. Each boat has a clear mission and a clear definition of done. You can only be in one boat and have to stay for the duration of the trip. There will be radio communication, there will be help and support, but the crew on a boat are responsible for completing the mission. There is a naval control that focuses on where the boats are, removing obstacles so that the mission is easier to complete. People that participate in the naval control are not in a boat.
Ceremonies
The normal team ceremonies (standup, planning, and retrospect) happen in each boat. After each round of boats, we do a bigger, systematic retrospect with the whole team (all 15) focusing on improving our system of work. At the beginning of each round, we run a boat selection where we decide what work to take on. Every week the naval control will meet with the boat captains to create a weekly radar image. This meeting is similar to a scrum of scrums where we raise problems and obstacles that need to be solved on a bigger level.
Roles
We clarified the roles we have in our team and introduced the concept of a captain.
Captain is a part-time role. They focus on crew work and cross boat communication. Captains represent their boat in the weekly radar meetings and communicate with stakeholders for the mission the boat is on. The captains make sure ceremonies happen and status is up to date.
Crew coach focuses on the whole system the team works in. Removes blockers for the boats and supports the captains. The crew coach facilitates team ceremonies such as boat selection, weekly radar, and full team retrospect. Communicates with team stakeholders and improves the whole system. Is part of naval control.
UX specialist lays a runway for the boats. Facilitates speedboats (spikes) and other exploratory work. Supports the boats with things like creating assets, testing, and reviewing. Is part of naval control.
Test lead helps the boats. Focuses on the overall quality of the product area. Think about automation, test strategy, releases, and other things that are key to good quality. Coach the boat crews in testing, and sometimes helicopter into a boat. Take part in cross-team activities (regression testing for the whole company). The test lead is part of naval control.
Developers make up the crews. Their main focus is the mission. Sometimes take on the role of a captain. These are the people closest to creating outcomes. Responsible for reaching the definition of done. Each crew is cross-functional and developers are responsible for the success of the boat. That includes ensuring the quality.
The tech manager (me in this case) focus on growing people. Responsible for the environment and the whole team system. Grows the team. Improves the system. Makes strategical decisions for the team, and decides where things go on a roadmap. Takes part in cross-team communication and is part of naval control.
Product manager is responsible for what goes on a roadmap, overall priorities, and product vision. An important part of laying the strategy ahead. Knows the market and the team's stakeholders. Helps to set a direction for the product the team is building. Part of naval control, but not officially part of the team.
Planning
We decided to reteam every six weeks. Why? Well, it is shorter than 10 weeks. For the work we do, we can make meaningful progress, and ship value to our users, in just six weeks. It also aligns well with our releases and calendar quarters where there are some important roadmap workshops. During these six weeks, each boat runs one-week iterations starting with planning and (sometimes) ending with a retrospect. Over time the boats have moved into something that looks more like kanban and focuses on the flow of work rather than sprints.
Naval control
Naval control focuses on keeping the system running and improving. They discuss strategic topics, keep status up to date (radar), continually improve the system, create roadmaps, keep track of team metrics (lead time, WIP, and velocity) as well as business metrics. They ensure clear communication with all the team’s stakeholders, and run communication with other teams, working on other features. Members of naval control help and advice the boat crews. They help individuals in the team grow. They fly in to help crews with specific tasks (UX and test). Naval control meets weekly to discuss strategic topics that will be important for the whole team in the future. This group consists of the tech manager, product manager, crew coach, UX designer, and test lead. The meetings are open for anyone from the team to join.
Port time
When a boat is done with its mission it comes back to port. Now it is port time. The crew members get two options: go and help another boat, or start working on smaller things that don’t require a full boat. Those can be small tasks or bugs in our port backlog or spikes where we want to try something out in preparation for a coming boat. Naval control is responsible for grooming the port backlog and keeping it up to date, to make sure that there is always meaningful work to pull from.
Boat selection
Every six weeks we start a new round of boats. The product manager brings a list of prioritized features to work on. They present problems to solve. Then developers get to choose what they want to work on. The missions are refined, team agreements are created and boats set off on their mission.
Setting sail
After months of preparation, refinement, discussions about the processes, and getting everyone on board (pun intended) we launched our first round of boats at the end of August 2020.
The self-selection and appointment of captains worked surprisingly well. People were excited to try new ways of working, and we had a common understanding of the pains we were trying to address. We keep improving this process, but even though people think this is going to be hard, self-selection has by far not been our biggest challenge.
Refinement
In the first round, we tried doing refinement in breakout rooms. Each crew would break down their work. Our product manager would run between the breakouts answering questions and clarifying the mission. When we gathered back, the crews would share their result and then the boats would launch. We quickly realized the limitations of this model, and in the next round did refinement together. This gave everyone a better insight into how crews would address their problems. It also gave developers that were not part of the crew an opportunity to share input and good ideas. We were able to define the goal of the boat together and discover possible dependencies.
Crew commitment
As a preparation for the first round of boats, we had a workshop with the whole team where we defined a common definition of ready and a common definition of done. Each boat crew was given some time just after forming to come up with additional team commitments and to clarify what the definition of done for the whole boat was. They would decide on ceremonies and book them, create their slack channel and any other agreements needed.
In the first round, our crew coach suggested names for each boat, just to lighten things up. This stuck and has become a cultural mark for each round of selection. Examples of boat names are The Codfather, Unsinkable 2, Ship happens, Usain Boat, Boaty McBoatface, and other creative names. This really helped the crew spirit and finding a good name became an important first task of the crew.
Experiments
The first round of boats was a big experiment in itself but in every consecutive round, we would use the retrospect at the end to define experiments for the next round. The whole team has consistently taken on one or two bigger experiments to improve the way we work. After each round, we evaluate the experiments. Some of them are deemed not helpful, and some become our ways of working. We can already see how the whole system has developed a lot, after only three rounds of boat selection.
New challenges unlocked
As we started working in boats new challenges quickly appeared. Since my thought process looks a lot like the theory of constraints I believe many of these challenges were there from the beginning but changing the way we work made them visible.
Isolation
One of the first things I noticed when working in boats was how isolated I became. Suddenly, as a manager, I was even further away from the work that was happening. I shared this feeling with several other members of the naval control. For me, it was not as big a problem as it was for the crew coach and the tester. They had to fight their way into every boat, joining their ceremonies, and make sure they understood what was going on so that they could support the crew in the best possible way. We also got reports from developers that even though they had a greater focus on their work, knew less of what was going on in the other boats. A number of experiments have been conducted to address the problem. Everything from sessions of Among us to more transparency of work, regular demos, common Slack channels, and other common team activities. We are still working on addressing the challenge of isolation, as part of the problem is by design. To be able to focus you have to isolate yourself from other things happening.
Dealing with support
As in the case of isolation, it was clear that working in boats created a greater focus on the boat's mission. This also meant less time spent on things going on outside of the boat. But we don’t work in a vacuum. Bugs, customer reports, and questions were still arriving at a steady pace. In the beginning, we were just trying to deal with them as they arrived, but this defeated the purpose of the boats. Instead, we started experimenting with a rolling schedule of a “fixer”. This person would take on the role of being notified and taking care of problems external to the boat, whenever they happened. Even though this didn’t fully address the situation, it did help.
No port time
When designing this system I had the assumption that we would always have some time in between the boat rounds. Some boats would always finish early. In the first round, this was confirmed as all boats came to port before the round was up. Already in the second round, we noticed that not all boats had port time before we started the next round. That’s when I realized — the more rounds we do, the better the crews are going to be at slicing work for exactly six weeks. That means the system is going to converge towards having no port time at all. This is something we have not solved yet, but I imagine having mission free weeks in between the rounds, or having dedicated days of work are approaches we can try.
Bottleneck of testing
Already before we started working in boats we could see that testing was a bottleneck for our team. Many developers were used to the environment where a tester would manually verify all new functionality, and we had very little to no automation in place. In a team of 15 people, we have one, highly skilled tester. When switching to boats this bottleneck became one of our biggest constraints. Tickets were left in “waiting for test” and developers considered work done. This was a great start for conversations. Our tester started running exploratory test sessions with the boats, helping them to feel more comfortable to verify functionality. Since manual regression testing takes a lot of effort we started investing in automation. Our tester was key in driving these efforts and little by little we have built up automated tests around the area of the product where we contribute.
Testing is still our biggest bottleneck, and something we keep investing in to improve, but I can already see a difference in attitude, and confidence from the team. As ☕ J. B. Rainsberger so nicely put it
You might not be faster, but you will be driving on four wheels instead of two.
Can’t man the boats — devs taking on new roles
In our second boat selection, we came to a situation I had feared (but hoped we would not experience until later). It became clear that we did not have enough people to man all the boats suggested by our product manager. Not only that, we did not have enough people to properly man the two most important ones. As with most challenges, they become opportunities. In this case, two developers stepped up and volunteered to move across tech stacks. One of our frontend developers volunteered to also do some backend work for the functionality he was building, and an Android developer volunteered to do the same. One of our backend developers got the main task of coaching his colleagues instead of writing code on his own. Even though it went slow at first, and it clearly was an investment we made for the future, we managed to finish what we took on for the round.
People moving across stacks was one of the effects I was hoping for, and I was excited when I saw that we have removed enough barriers for this to happen in the team. There will be more opportunities for team members to grow in this way, and it helps the flow of work.
Boat continues
One recent challenge we have is that a crew is not done with their mission at the end of a boat round. We still open up for a new round of boat selection after six weeks, but most of the crew choose to stay on. In some cases, they get new crew members, joining to help out finishing the mission. Challenges arise when we are unable to ship to customers after each boat ride, missing the opportunity to get early feedback on what we are developing. We are trying to remedy this by being better at slicing work into parts that make sense to ship to customers, after just six weeks of work. We are also utilizing feature flags and A/B testing to better understand if we are going in the right direction. This is a challenge that we will keep having, and as long we are able to continuously ship value to our customers, I don’t see a big problem with investing several boat rounds in the same feature.
Going forward
We have only worked this way for about five months, doing three boat rounds, launching a total of nine boats. After sending out a pulse survey the team has agreed to keep working in boats. Experimentation and continuous improvement are built into the system, so I expect it to keep changing. I can already see how we have vastly improved in just three iterations. I expect that we will have a very different system in another six months, and we are still learning a lot in each iteration we run. I hope the experiments we run will become bolder, and that we will see more process improvements happening in the separate boats. I also think that there are big challenges we have not faced yet, that will help us learn and adapt. My aim is to build an antifragile system that can come back stronger after being under pressure.
We can already see that our way of working is inspiring other teams at Storytel to try on similar systems. We have one team of submarines and another team of air flights. I expect that our development will be very different, adapted to the context each team works in. We do however keep inspiring and learning from each other.
This type of dynamic reteaming is not for every team or every context, but it works very well for us and it is something we will keep doing.
Further reading
There are many other organizations experimenting with how to do reteaming well, and often. Here are a few resources I have found valuable:
Dynamic reteaming by Heidi Helfand. Contains both a structured description of different forms of reteaming and a large number of examples from different situations and organizations.
Creating great teams by Sandy Mamoli and David Mole describing in detail a process for self-selection that we have used as a model for our boat selections.
Antifragile by Nassim Nicholas Taleb describing systems that gain from disorder, and come back stronger. The model idea for a learning system.
https://kodsnack.libsyn.com/kodsnack-341-en-kraft-som-drar-ihop-teamen-med-pia-fk-sunnanbo A podcast episode about an experiment in reteaming at Swedish National Television (SVT). Unfortunately, this episode is in Swedish
