5 lessons I learned working in a remote scaled Scrum team
Due to COVID-19, a lot of teams are working almost entirely remotely. There are some challenges that can come to the surface from remote collaboration. I want to share with you the struggles that my team faced, and how we overcame them.
Our team was mostly working remotely, and from 3 different time zones. The team was formed by 10 mobile engineers, 7 front end engineers, 7 back end engineers, 6 quality assurance engineers, 3 business analysts, 2 project managers, 1 scrum master, and 4 solution architects. We were over 40 people, and it was still growing when I left the project. Even before COVID-19, working with such a big team would be an interesting challenge. Since our team was large, we applied the concept of scaled Scrum, also used by Spotify. We had our team divided into 3 squads — gin, tonic, and ice.
According to Scrum Alliance:
“The ideal size for a development team is between 3 and 9 people, not including the Scrum Master and Product Owner. Any smaller and the team couldn’t accomplish enough each sprint. Any larger, and communication becomes complex and cumbersome.”.
This made me realize that a lot of the struggles with communication we faced happened due to the fact that we were such a big team. But why did we have such a big team? The answer is not quite simple. Before going there let me give you some introduction about our client. Our client is a major retail and commercial bank in the UK. We ran a digital transformation program where we developed a mobile app (for iOS and Android) and a website for their private bank and wealth management brand.
Until our Beta release, we iterated over 36 weeks using 2-week sprints. Here are some lessons that we learned from this experience.
1. Start writing documentation early
Most of the documentation for all Backbase products can be found on our Backbase community website. This documentation describes the handling, functionality, and architecture of a technical product or a product under development or use. However, as in many projects, there is a level of customization that is only relevant to us. This knowledge cannot be limited only to a few people, especially in a remote team where our work needs to be aligned and independent. These things need to be documented so other team members are able to understand and work on the same features if needed. For some platforms and capabilities, we did start early and it showed to be very useful, but for some others, we only started documenting late and it turned out to be a learning point.
A good example of this is the documentation we produced regarding the Identity implementation — our Backbase product for user authentication (including, 2-factor authentication and transaction signing). For a while, this knowledge was only limited to the few developers who worked on it. So, when it was needed for new developers to touch on these features, it was almost impossible to do without help from the ones who implemented them. Once documentation was produced this made things much smoother. This also became very valuable for new joiners.
2. Have shared repositories
Early on the project, it was spotted that the mobile platforms would share some assets, for example, localization files, environment configuration files, mocked data responses, off-line model files, etc. So, we created a shared mobile repository which was made a submodule of both platforms repositories. This way we would keep this data aligned as much as possible, avoiding multiple sources of truth and misalignments.
One of the benefits of this shared repository was that we kept all the localization files up to date on both platforms. All the new labels would be added to the shared assets repository, on a CSV file. Then in order to update the iOS and Android files, it was needed to run a script that would update the localization files based on the new data from the CSV.
3. Create groups and threads on Slack
In a remote team with 40+ people, a chat group can easily become a huge carnival party with many loud cars everywhere. This challenge was pointed out early in the project because working remotely means that communication should be optimal. This seems to be a very logical and intuitive thing to do. However, people simply forget about it. Especially, if they are not used to working in big teams or if they are new to Slack. Our solution was pretty simple:
Always use threads, make smaller groups when needed, and use tags when relevant.
And if we remind you every day about it, don’t take it personally 🙃.
I would say that when executed well, it showed to be very helpful. Kudos to Tolu, our PM, who reminded us every day.
4. Link and watch user stories and Confluence documents
Keeping a single source of truth aligned in a team can be challenging. Especially if you have 3 platforms, and 10 different people working on the same feature. On top of that, in the real world changes happen. So, how do we keep all of the relevant people aligned at all times?
Some user stories need extra information (for example, Confluence documents), or are dependent on the work of others. In order to solve this, we agreed to link user stories and documents which are related. As well as, use the watch feature on Jira and Confluence. That way the relevant people would be able to receive updates from the relevant content about a feature when changes happen. This showed to be especially valuable in a remote scenario because instead of having to message a group of people that are working on the same feature (and potentially forgetting someone), all people watching those user stories, Confluence documents, etc, would get notified by email when changes happen.
5. Have cross squad updates sessions
It was clear from the beginning of the project that we would have to be smart about how to handle our ceremonies. Stand-ups were handled per squad, as well as refinement and estimation sessions. However, retrospective sessions were done with all squads — that was the moment where everyone could come together and share some feedback and experiences. Kudos to our scrum master, Lena. Besides the fact that we were all working remotely, she always had an activity that would make the most productive sessions.
However, there were times when members of different squads had no idea about the different features that were being developed by others. Having 3 squads working on different features on the same repository can be challenging if the team members are not on the same page. This caused some misalignments and misunderstandings. So, the mobile developers (“guild”) have set up a daily sync session of 15 min when we would discuss:
- Feature related updates, that can affect other squads. Different from stand up, more on a technical level.
- Model or CX manager related changes.
- Community updates, things that are relevant to both platforms.
- CI/CD updates.
- Align the way of working.
Conclusion
This project was an interesting journey. We had a big and ambitious road map. We implemented all the Backbase features on the menu: you name it, we have it. Some of which we were the very first ones to do so. This brings me to give a big kudos to our RnD department — we had great support and cooperation with many different teams. And that was crucial to the success of this project.
Our core team also had a very hard job on this project. They had to work with both a high profile client, as well as with our very diverse Backbase team. So, it was needed to be very creative and flexible in order to achieve success. Kudos to them.
Finally, why did we have such a big team? It’s very typical for big banks, certainly in the UK, when running large digital transformation programs such as this one, to have several delivery features teams. In this case, our client had 7 feature teams, each having more than the typical size of a Backbase scrum team. It would have been impossible for us to work in the way we usually do to meet our client’s expectations and delivery timelines. So, in typical Backbase fashion, we adjusted and ramped up the Backbase team. On one hand, I believe that we were able to build things faster and deliver a lot at the end of every sprint. On the other hand, there was a learning curve for adapting to this way of working and it was difficult to create good connections within the team — build a team spirit.
Besides the good and the bad, I believe that the most important point is that the whole team was always working towards a common goal. When working remotely we have to be aware that others are also working somewhere out there, but with you. Every person in the team needs to be mindful of their colleagues and find ways to make sure they are able to collaborate.
