Experiences in Small Scale Scrum Scaling

3 min read

scaling scrum teams

Scaling the Scrum process has become a very hot topic recently and frameworks supporting it keep popping up. After SAFE, we’ve seen the rise of LeSS and Nexus, just to name the most popular ones.

If you’re looking to scale Scrum in your teams, you might be feeling confused. Which scaling framework will fit your needs best? Perhaps you feel that all of them add too much complexity and overhead to your process?

This problem is especially prominent when you’re dealing with no more than 3-4 teams working on a single product. Do those frameworks even add value at that point?

During my talk at 2nd STX Next Tech Summit, I shared some of my experimental outcomes and experiences with scaling Scrum. Below you will find a summary of my findings and, if you’re more visually-oriented, a video from the talk.


Frustrations with the Scrum of Scrums format

The first area people are concerned with when attempting to scale Scrum is cross-team communication. What most people try first is organizing Scrum of Scrums meetings.

Unfortunately, they rarely work as intended.

No matter which people attend that meeting, they usually don’t have have enough context of the other teams’ work to communicate issues effectively and pick the right topics to bring up.

We’ve tried pretty much everything. We’ve tried Scrum of Scrums handled by POs, SMs or Devs. We’ve tried having people visiting other teams’ Daily Scrums. We’ve even tried having cross-team global Daily Scrums, which everyone attended, after the regular team daily meetings.

Unfortunately, all those attempts at implementing Scrum of Scrums ended up being yet another meeting that didn’t bring in much value.

What are the alternatives?

When Scrum of Scrums meetings failed, we tried a different approach – handling cross-team issues through a single Product Owner and single Scrum Master, shared between the 3 teams we worked with.

We saw a few risks caused by such an approach. Will the PO and SM find time to work with the teams? Won’t they become a bottleneck? But we decided to try it out anyway.

One side effect that we noticed right from the start was that the quality of our Daily Scrums increased significantly.

People could focus more on verifying the plan for the next 24 hours rather than figuring out what to say at each meeting.

Additionally, the Product Owner and Scrum Master could easily spot integration issues, because they were involved in the day-to-day work of the teams.

And because all the teams were working on the same product, context switching cost for those two roles wasn’t as big of an issue as we expected. Apart from that it was much simpler for the Product Owner to share a single product vision with the teams.


What about the rest of the process?

Such a team setup (a single Product Owner and Scrum Master working with multiple teams) also impacted how Scrum artifacts and events were handled. If you want to learn more, watch the video below.

Image credits and references

  • Icons made by www.freepik.com from www.flaticon.com are licensed by CC 3.0 BY
  • Icons made by Icomoon from www.flaticon.com are licensed by CC 3.0 BY
  • Icons made by SimpleIcon from www.flaticon.com are licensed by CC 3.0 BY
  • Less.works
  • www.scaledagileframework.com
  • www.scrum.org

Łukasz Aziukiewicz

Product Owner

More articles about Agile