Scaling Scrum Meetings to 50+ People

Scrum Scales

Growth is about increasing size. Scaling is about increasing intelligence.

Growth is about adding more layers of hierarchy, defining new roles and adding policies. Scaling is about mastering the complexity by minimizing it.

Scrum doesn't easily support growth: it is against adding roles, having bigger teams, multiplying backlogs. That's why it is so easy to overlook its inherent scaling capabilities while looking for more "correct" solutions.

Scrum allows scaling by raising the inner intelligence of human systems — enabling and empowering each of its parts to act independently yet aligned. Like water molecules that dissolve dirt and help you wash your clothes, dishes, car and even children…

Well, team members don't exactly dissolve product-backlog items during refinement meetings. But you get the idea.

You don't have to manage molecules of water to let them do the job. You just need to allow them to do it for you. The same way Scrum helps to solve complex matters: by pushing the intelligent work down to the level of teams and individuals, to let them figure out the necessary details.

Scrum Meetings Scale

In fact, all Scrum meetings scale so naturally that I've been hesitating to write about it for quite some time.

Scaling Scrum ceremonies requires you — the process facilitator — to do a few key things:

1. Prepare the space.
2. Invite the right people in.
3. Explain the goals to be achieved.
4. Facilitate the formation of smaller self-managing groups.
5. Give sufficient-yet-minimal guidelines on how to go about the matter.
6. And stay away to let the intelligence of the system handle the complexity.

Let's see how this works in real practice.

Scaling Product Backlog Refinement

Managing complexity is not about breaking complex things down into simpler elements: you're not breaking a dish into pieces to get it washed (not to mention your car or kids). Instead you're letting the water take it all and do its job on the invisible — sub-managed — level.

The same goes for products. You will not help the system handle the complexity of product development if you break the product into many sub-products with many tiny backlogs.

In fact, by doing so you will increase complexity, because someone now needs to take care of gluing things back together. Some things are counter-intuitive. You need to see it working to believe me.

Preparing the space

When we scale product development we follow an advice from Large-Scale Scrum: whole product focus. So I help a group of stakeholders, visionaries and product thinkers co-create a big picture. Sometimes they bring their mini-backlogs and we start gluing things back. This can take some time.

In most organizations this actually takes quite some time — the status quo of today's product management relies heavily on breaking things down into small "manageable" pieces. So I always carry a tube of super glue along with markers and post-its in my bag. I can also make nasty jokes with it… but that's another story.

Below, a group of product managers co-creates a visual product-backlog board. The board carries the overall business goals, release goals, user journeys and empty placeholders for backlog items.

Once it's prepared, we call everyone in.

Bringing everyone in and explaining the goals

Once all are in — and by "all" I mean literally everyone who can help us dig into the details of the work — one of the product managers walks the room through the thinking behind the board: goals, priorities, challenges, hypotheses, big questions.

So far it looks easy-peasy. Look what happens next.

Breaking into smaller groups

One product, single product backlog, overall backlog refinement — that's the mantra we follow for our multi-team Scrum approach.

To maximize learning — and by the way, the backlog refinement meeting is a learning meeting — we shuffle the members of the existing development teams and form new groups just for this meeting. We want each group to have members from all of the development teams.

This ensures that everyone in each development team will know some product backlog items (PBIs) — and together as a team they'll be familiar with all of them. That amplifies learning, maximizes the spread of knowledge, and allows product management to change priorities without worrying about team structure and potential knowledge gaps.

That's what agility on the product level actually means — among other things.

Defining simple guidelines

Once we have the groups, the process works like this:

• Each group pulls an unrefined PBI, invites one of the product managers, and spends no more than 15 minutes on the topic.
• The main goal is to build a shared understanding of the item: what the problem is, what the user journey looks like. Just enough clarity to know whether this is feasible and can be done within a few days of work. If not — the item gets split into smaller ones.
• After the time-box is over, the whole group decides — by voting — how refined the current item is, makes a note of its readiness (one dot — not enough understanding; two dots — there are some questions, but OK; three dots — alles klar!) and moves on to the next unrefined PBI.
• Oh, by the way, our PBIs are not stored in Jira. In fact we cancelled our Jira license after we started using A3 sheets for collecting the details of a PBI. We figured out that paper size is just enough to keep the right level of detail. (Don't ask me how XPers used to manage their stories on 5-inch index cards. Size apparently matters.)
• When the group is done with the item, they fold the A3 sheet and hang it back onto the backlog wall. Everyone else in the room now knows the item has been refined — it has dots on it.
• During our 60-minute meeting we refine about 12–15 PBIs — roughly two weeks' worth of work for all of the teams.

Staying away (a reminder for the manager)

This meeting looks unorganized, chaotic, and if you walked into the room you might say the meeting is unmanaged.

Some working groups occasionally split into smaller groups, some people spontaneously jump to a whiteboard and draw diagrams, some folks sporadically decide to have a one-on-one discussion in the middle of the room.

Well, that's OK.

In fact, chaos is a sign of self-organization. Compare an army marching on parade with a long-haired crowd entering a stadium for a Red Hot Chili Peppers concert. Which one looks ordered, and which one is chaotic? Which one is managed, and which one is self-organized?

So it's OK for things to look messy. In fact, when a Scrum meeting is not messy enough — you're doing it all wrong.