Scaling Scrum — a practical approach
When you need to scale your Scrum workflow
Most developers have, at one point or another of their career, worked in a team using Scrum. Even that not all companies implement it the same way, or in a good way at all, the main pillars are always there. The cycle starts from the Product Backlog, which is skimmed to the Sprint Backlog that should be developed during the 2–4 weeks sprint into a potentially shippable product increment. On Scrum, there is one backlog from — potentially — one product for one development team, which is one of its fundamentals. However, what happens when you still have that one backlog but several teams? How do you scale Scrum to fit the needs of your projects while remaining Agile? How do you work with cross teams and keep the communication flowing between them?
SAFe, Nexus and Less are the usual frameworks mentioned when the idea is to scale Scrum. Every single one of those frameworks and the other ones not mentioned has its pros and cons as it depends more on which one fits better the project’s need. And there is where we — the Sportsbook FE teams at Betsson — were standing a couple of months ago. We had one quite large backlog, six teams of 7–8 people each between developers and QA’s and the need to scale our Scrum approach to fit our new setup while keeping the speed and quality of our deliverable. After looking into the several available methodologies on the market, we came up with our own custom-made version of scaled Scrum, which I will share in this article.
As mentioned previously, our starting point was a big backlog and six teams, which previously were working in individual exclusive Scrum Sprints. Our goal was to maintain the 2 weeks delivery sprint while spreading the tasks and knowledge equally between all teams. From this came two challenges we had to tackle on our scaled Scrum approach:
· How to be sure that all high priority stories could/would be picked up during the current Sprint?
· How to keep the knowledge flowing between teams without too many meetings and meetings with too many people?
The Tribe approach
To tackle those problems we borrowed some of the LeSS concepts and decided to separate the Sprint flow into two phases. One phase involves one or several members of each team — we called that phase the “Tribe” meetings — and then the other is the normal Scrum sprint flow, which each team conducted individually. The tribe phase was consisted of:
· Tribe Refinement (2 weeks before the start of the Sprint): Each team sends two members to give a high-level estimation (T-shirt sizes) to the stories present on the backlog. The list is sent prior to the meeting, giving the participating elements time to check it properly beforehand. There are two main purposes to this meeting, one being to give a starting estimation to the stories for future splitting (see Tribe Planning), and to allow all teams to have some knowledge about ALL stories that will be handled by the Tribe, cross teams.
· Tribe Planning (2 weeks before the start of the Sprint): With one representative of each team and the Product Owners, the purpose of this meeting is to split the work between the teams based on the estimations given on the Tribe Refinement. The items with high priority are taken first. Each team representative is responsible to be aware of how much work his team can compromise to, for the following Sprint.
· On the following three weeks each team goes through their own individual Scrum sprint flow
· Tribe Retrospective(The week after the end of the Sprint): The same representatives of each team discuss what went good or bad during the Sprint, bringing new ideas or improvements points both from their own feedback but also from the feedback given by their team on the Team Retrospective. The main goal of this meeting is to polish the process.
Between the Tribe flow, each team conducts individually their own Team Sprint which is consisted of:
· Team Refinement (a week before the start of the Sprint): After the tasks are split during the Tribe Planning, it is the responsibility of each team to more deeply analyze their complexity and to clarify any requirement with the Product Owners or design team. The estimation at this point is made by man-days of work needed for the task and should be as accurate as possible. The tasks remain on the Team Backlog.
· Team Planning (first day of the Sprint): The team and a PO decide how many and which stories from the Team Backlog will be selected to be developed and shipped during that Sprint.
· Daily Stand-ups
· Team Retrospective(last day of the Sprint): The team discusses the positive and negative points of the past Sprint, as well as the action points to improve the process on future iterations. Any Tribe related feedback will be mentioned by the team representative during the Tribe Retrospective and discussed there between the several teams.
A couple more rules
This process has allowed the teams to work individually while maintaining cross-communication with the other teams and both the technical knowledge as well as the domain knowledge spread. However, to increase that knowledge sharing we complemented this approach with two other actions. The first one is the cross-team code reviews. As in most companies currently, we use code reviews to maintain a good code quality with a minimum number of approvals needed for any code to be merged. In addition, the rule is that those approvals should come from other teams, to have a different technical opinion or even to be aware of some domain dependency the original team may not have been aware about.
The second is a feature demo/presentation from the team or teams that worked on that feature. As mentioned before, when the tasks are split, every team is represented and usually stories/tasks from a specific feature will always end up on the same team (or teams), which guarantee the quality and stability of the development of that feature, while having all the others teams aware of the status and steps of the feature development. The demo/presentation reinforces that with a final sharing of how the feature was developed and how it works, allowing a deeper understanding from the other teams.
The results of our Scaled Scrum approach have been quite positive, with the speed and quality of our deliverable remaining high. It did take us a couple of iterations to reach the current rules and set-up, however, at this point we feel confident that we could easily scale even more and have more teams join the “Tribe”. Having said that, do not expect our method to fit your needs perfectly. You will have to try and adjust, as we did. Nonetheless, I do hope that our approach and this article can help you as a starting point.
