top of page

Large Scrum Teams: How To Manage (Real-Life Case Study)

Updated: Oct 31, 2022


It is known that a Scrum team should consist of up to 9 people for effective work (Product Owner, Scrum Master, and maximum 7 engineers). Smaller teams are simpler to manage, and the visibility of day-to-day work is much more transparent. In practice, I often see teams of more than 7 engineers (especially in large organizations or on large projects). So what to do if such a project with large Scrum teams appeared?


Let's use a real-life case study of one of my teams, which consisted of 17 people.

How did it happen?


It's worth starting with how it happened in the first place, that the Scrum team consisted of 17 people. When the team started building the product, it consisted of 5 engineers, a Scrum Master, and a Product Owner. In 11 months, it grew to 17 people in the team.


The main factors were the underestimation of the product's complexity and the need for engineers to deliver what was planned (such a regular case). So at some point (when we already had about 10 engineers on board) I had to make a decision on how we would continue working.


Let's review some of the options how such large teams can be managed.



What you can do about it?



Option 1: Divide large scrum team into separete teams or squads


The biggest benefit of splitting the team (given that they can work on independent topics) is to save time and time is money.


Let's divide our team into three separate squads dealing with different product parts. Daily Scrum will become more effective if we make three separate standups instead of 17 people falling asleep on one at least 30 min Stand Up. Instead of three hours of Product Backlog Refinement during which at least half of the people snooze, we will achieve the same effect with three one-hour sessions, where only those interested will be present.


What may seem like a larger number of meetings will actually save time, as these meetings will be specific and attended by committed people.


I implemented this solution on another team (other than the one described above) and over time the two smaller teams split into 2 completely independent teams with their own backog and ceremonies.



Option 2: Level Up and introduce LESS framework

But what if we can't completely divide our teams, and even though we can divide them into smaller teams, we have to work in one Sprint or on one Product Backlog (that just happened to be my case).


LeSS (Large-Scale Scrum) Framework was our solution. Our approach was following:

  • Single Product Owner and Single Product Backlog

  • One common Sprint Planning across all teams

  • One common Sprint across all teams

  • The same shippable product increment

  • Overall Sprint Review (to share findings and discuss next steps)

  • Overall Retrospective


This approach was a definite win in keeping everyone aligned, but at the same time, it was easy for me to manage teams since they were small and engaged.


But remember that this approach also comes with risks. Joint planning meetings, "on-demand" syncs, and cross-team code reviews do not always guarantee full agreement, watch out for poor communication between teams during day-to-day work.



Conclusion

The above two examples will be relevant to many large teams. But what to do if the product team has 50 or even 100 people? There are ways to do this too (e.g., SAFe Framework), but that's for another article. 😅



167 views0 comments

Comments


bottom of page