The following relies heavily on the Nexus guide for scaling scrum and personal experience. While it is not a definitive guide, it can be a starting point or simply one option to consider. When working with people there is hardly a universal solution, but that’s part of what makes it interesting.
Scrum is designed for small teams, from 3 to 9 people. So naturally, scaling scrum can present a little bit of a challenge. A possible solution is to create multiple scrum teams that are all part of a bigger team; this approach can be commonly known as scaling with Nexus. Throughout this article the scrum teams will be called subteams and the bigger team to which all subteams belong will just be called a team.
With the approach mentioned above we can create multiple subteams with different specializations, like front end, back end, quality assurance, UI/UX, etc. The main thing to keep in mind is that all of the teams must be after the same common goal. The subteams are, in theory, not limited to being part of the same company, but it is important to note that the more spread out they are the more the cross-subteam complexity increases.
It’s best if only one Product Owner exists for the team, but, speaking from personal experience, there’s a little bit more freedom regarding the Scrum Master position. Having one per team could work, but having one per subteam could also work. The latter is true especially if the amount of work is too big. The downside to this is the risk of miscommunication and the lack of communication. With multiple people overseeing the project it’s paramount that they all stay on the same page to avoid unnecessary complexity or dependencies.
Another important part of scaling is having a subteam with leaders from the other subteams. A similar concept is brought up in the Nexus guide for scaling scrum, and it’s called the Nexus Integration Team. The purpose of this team is to work on eliminating cross-subteam dependencies as fast as possible and to guarantee a continuous delivery of increments to the product. Members of this subteam should make their work regarding this subteam their priority over their other subteam’s work. The reasoning behind this is that cross-team dependencies are one of the biggest weaknesses of scaling scrum and should be dealt with with as much speed as possible.
Having meaningful meetings applies to every work scenario, but it is especially true when scaling scrum and particularly so for members that are part of both a subteam and the leader’s subteam mentioned above. The last thing the team needs is cross-subteam dependencies not being resolved because the people in charge of doing that are constantly in meetings.
Next we’ll focus on how some of the events from scrum would work when scaling.
The sprint planning could be done in two stages. The first stage would be for some subteam leaders to get together with the stakeholders and work on defining the sprint scope and priorities. At this stage everything should remain at a high level so that getting an overview can be easier. The second stage would be with each individual subteam. In that session the subteams can go into details regarding the work for the next sprint. It is here where estimation and assignment of the stories would get done.
The daily stand up could also benefit from being done in two stages. Every subteam would have their own and then the leaders of the subteams would get together for a second one to review and discuss progress and cross-subteam dependencies. Having one giant daily stand up for all subteams would take too long and the members would have to sit through many things that aren’t crucial to them.
For the sprint review, it would be useful to have it done for the whole team instead of for each individual subteam. This would help as a reminder that every subteam is working towards the same common goal.
And lastly, the sprint retrospective. Subteam retrospectives are crucial, but team retrospectives are very important as well. The latter one can be often neglected because they might seem trivial or because everybody has more than enough on their plates. Nevertheless, they are critical to the improvement and growth of the team because at the end of the day all the subteams are working together.
