Ceremonies of Agile At Scale – The De Facto Guide, Tips & Techniques

Let’s be real, very few of us work in a solo, small team working on a single product. So whilst the common agile ceremonies, like daily stand-ups and retros are great, they aren’t enough alone to facilitate coordination across multiple teams.

Over the years, agile has evolved to include several additional ceremonies to help facilitate agile at scale. These ceremonies are mostly designed to help scale ceremonies at the team level to help facilitate better cross-team coordination and rapid decision making.

Although there are numerous of these ceremonies, the most common are:

• Scrum of Scrums
• PO Sync
• Quarterly Planning (also known as Big Room Planning and PI Planning)
• Communities of Practice

In this article we’re going to explore these ceremonies, what they are, their purpose and tips to help you implement them.

Scrum of Scrums

What is the Scrum of Scrums?

Scrum of Scrums is an agile ceremony that is designed to mimic the daily scrum at a cross-team level. During the meeting, representatives from each team meet to discuss cross-team dependencies, escalate blockers, resolve cross-team issues and raise risks

What is the purpose of the Scrum of Scrums?

The purpose of the Scrum of Scrums is to facilitate self-organization and resolve cross-team impediments. Regular Scrum of Scrums provides a forum to escalate impediments and resolve them swiftly

Who is responsible/facilitates the Scrum of Scrums?

The Scrum of Scrums is typically self-organized however there may be an Agile Coach, (Senior) Scrum Master, Release Train Engineer or equivalent role that facilitates the ceremony.

Unlike common management structures where there is a central manager who coordinates the work, it is composed of representatives from each team, who collectively resolve impediments and coordinate together

Who attends the Scrum of Scrums?

There should be at least one representative from each team at the Scrum of Scrums. Who and what role is determined by each individual team.

It’s common for a Scrum Master and/or Product Owner to be the representative who attends, however some teams like to rotate this role and others will send whoever had an impediment to raise

How to run a Scrum of Scrums?

Since the Scrum of Scrums is designed to mirror the daily scrum at a cross-team level, it is therefore common to run the meeting in a similar format.

Taking turns, each team representative discusses their progress, impediments, risks and any dependencies on other teams.

A common format is to have each representative answer the following questions:

1. What has your team done since we last met?
2. What will your team do before we meet again?
3. Are there any impediments slowing your team down?
4. Do you have any risks or anything else important to raise?

Alternatively, Scrum@Scale advises that each representative answer the following questions in the Scrum of Scrums:

• What impediments does a team have that will prevent them from accomplishing their Sprint Goal or that will impact the delivery plan?
• Is a team doing anything that will prevent another team from accomplishing their Sprint Goal or that will impact their delivery plan?
• Have any new dependencies between the teams or a way to resolve an existing dependency been discovered

Tips for running an effective Scrum of Scrums?

The Scrum of Scrums should be timeboxed — typically between 15 and 30 minutes — it is designed to be lightweight and quick.

Best practice is to also hold the Scrum of Scrums regularly. Common cadences range from daily to once a week. Generally the more frequent the better. It’s better to have the Scrum of Scrums and not need it — or to finish early — than to not have it and potentially have impediments waiting days to be resolved.

It’s important that what is discussed at the Scrum of Scrums is visible and captured. Therefore it’s best practice to have a Scrum of Scrums board. This can be a kanban board visualizing the work at a portfolio level across the teams, or it can simply be a list of action items, risks, etc that are captured and followed up at each Scrum of Scrums.

Having a visual board also allows you to use the ‘walk the board' format for your Scrum of Scrums. This is an effective format that can help keep the focus on removing impediments, coordinating dependencies and resolving risks/issues.

Since the intent of the Scrum of Scrum is to resolve issues across teams, it is important to have the right people at the Scrum of Scrums. Depending on your work and organization structure, you may need to invite key stakeholders or specific leaders to the Scrum of Scrums For example, engineering or product leadership. Ultimately, anyone necessary to resolve common team impediments.

Similar to the daily scrum, the Scrum of Scrums does not replace cross-team communication and coordination. It is a formal event to facilitate better cross-team coordination and alignment but shouldn’t be the only place where cross-team communication occurs.

PO Sync

What is the PO Sync?

Where the Scrum of Scrums is focussed on resolving impediments in the current sprint, the PO Sync looks further ahead. During the PO Sync, the Product Ownership team gathers to share and discuss their roadmaps in order to manage dependencies, make prioritization decisions and create alignment.

What is the purpose of the PO Sync?

The main purpose of the PO Sync is to coordinate future work across multiple teams. This compliments the Scrum of Scrums as one is focused on the ‘how' and near-term, whilst the other on the ‘what' and longer-term.

Who is responsible/facilitates the PO Sync?

Depending on organization structure, the Product Leader (often the Head of Product, Group Product Manager or Chief Product Owner) is responsible for the PO Sync.

Who attends/facilitates the PO Sync?

At a minimum the attendees of the PO Sync should be all the Product Owners in a given group or area. These are generally the Product Owners who work on a common product line or business area. For example, all the POs that work on video streaming.

Since the PO Sync is focused on coordinating the ‘what', it can be beneficial to have key stakeholders and subject matter experts attend as well.

How to run a PO Sync?

The team of Product Owners coordinate during the PO Sync by:

• Sharing their individual product roadmaps
• Identifying and sequencing work to resolve future dependencies
• Creating alignment and maintaining consistency across teams
• Making cross-team prioritization decisions

A typical format for the PO Sync starts with the Head of Product (or equivalent) sharing their goals and any other pertinent news that may impact the team’s roadmaps. The Product Owners will then take turns to share their roadmaps and together look for dependencies, points of contention and opportunities for alignment.

Tips for running an effective PO Sync?

Synchronizing work across multiple teams can be easier said than done. A good technique to assist is to make the work more visible. This can be through maintaining a dependency board or a portfolio roadmap. Regardless of what you choose, making the work visible will help to identify dependencies and points of contention to be solved in the PO Sync.

At times the PO Sync and Scrum of Scrums can feel like the same ceremony with similar attendees. In some cases it can make sense to combine them into a single ceremony. This is fine to do if it works for your context, however remember to maintain a balance between discussing the ‘what' and the ‘how', as well as near-term problem solving vs longer-term planning.

Quarterly Planning

What is Quarterly Planning?

Quarterly Planning, also known as PI Planning or Big Room Planning is a scaled agile ceremony where multiple teams come together to plan the activities for the quarter or a selected timespan (e.g. the next 4 sprints).

What is the purpose of Quarterly Planning?

The purpose of quarterly planning is to set the goals and high level backlog for the quarter. Quarterly planning is designed to foster cross-team coordination and resolve interdependencies.

At the end of quarterly planning, all team members should have a common understanding of the goals for the quarter and a high level plan towards them.

Who is responsible/facilitates Quarterly Planning?

Depending on whether you are using a scaled framework like SAFe or not, the person responsible for quarterly planning will differ. In SAFe, quarterly planning is known as PI Planning. This is where teams come together to plan out what SAFe calls a PI (Program Increment), often 6 sprints in duration (a quarter). In SAFe the Release Train Engineer is responsible for, and will facilitate PI Planning.

However if you aren’t following SAFe, you may have an equivalent role, such as a Chief Scrum Master or Senior Scrum Master, who could facilitate quarterly planning. Alternatively, it is common for quarterly planning to be owned by the product team, facilitated by the Head of Product or Chief Product Owner and their team.

Who attends the Quarterly Planning?

At a minimum all teams, their members and all key stakeholders within the common business unit or area should attend quarterly planning.

How to run Quarterly Planning?

SAFe has a comprehensive agenda for running PI planning but generally speaking, a typical quarterly planning agenda will follow:

• Welcome
• Business context
• Product vision, goals and context
• Stakeholder considerations for the quarter (architecture, sales, marketing, etc)
• Team planning breakouts
• Team playbacks
• Risks, Issues, Dependencies, etc
• Close

Depending on size, quarterly planning is often at least a 1-3 day event.

Tips for running an effective Quarterly Planning?

It’s important to protect the time for quarterly planning. It’s easy for a 2 day planning to digress down to a 1-2 hour meeting. However the more interdependencies, the more time will be needed to plan ahead and coordinate. Failure to do so will result in a loss of time later to dependency management, which can add up quickly to be more than a day or two’s worth of upfront planning.

The next most critical element to a successful quarterly planning is the attendees. Getting the right people in the room is paramount to the success of quarterly planning. Decision makers, key stakeholders and subject matter experts should all be in attendance. But don’t fret, not everyone needs to be there the whole time. Consider how you might split the day(s) to allow key stakeholders to step in for moments like the business context and team playbacks, but be excused for team breakouts and individual planning.

Finally, the way in which you plan. Commonly, teams use a program board to track high-level dependencies. You can also use story mapping for team-level planning. These two work very nicely in combination.

Communities of Practice

What are Communities of Practice?

Communities of Practice are self-organized groups of people with common interests who come together regularly to share and learn from each other. They are normally formed around a topic or theme; for example, Product Ownership.

Communities of Practice are a great way to share information, learnings and advance skills across the organization.

What is the purpose of Communities of Practice?

Communities of Practice are designed to share best practices, create new knowledge and advance a particular domain or skill area.

Participating in a community of practice can also help to build connections, create opportunities and a sense of belonging.

Who is responsible/facilitates the Communities of Practice?

Whilst Communities of Practice are often self-organized, it is not uncommon for formal communities to exist within organizations. In these cases, the Communities of Practice may be owned and facilitated by a practice lead or equivalent role.

For example, the Product Owner community may be owned and facilitated by the Head of Product and the agility community may be owned by the Agile Practice Lead.

Who attends the Communities of Practice?

Communities of Practice are designed for anyone that shares a common interest in a given area. Therefore attendance is open to anyone. In more formal Communities of Practice, attendees may be based on a profession. For example, Product Owners will attend the Product Ownership community. However that doesn’t preclude other roles—who might be interested in a career in product ownership—from attending.

Tips for running effective Communities of Practice?

Similar to other agile ceremonies, holding community meetings on a regular cadence is best practice.

Whether self-organized or formalized, it’s important that communities of practices are inclusive and valuable to their members. The best communities are two-way, where participants discuss and share their own experiences.

It’s best to keep Communities of Practice simple and informal to encourage dialog and participation. Leaders should also encourage participation and learning through the various Communities of Practice. They themselves should lead by example and participate too.

I’ve also found it effective in the past to have a small group of community leaders. This decentralizes the role of organizing and administering the community from a single person, whilst still having dedicated people who seek to ensure the community of practice is effective and valuable.

Scaled Agile Ceremonies Summary

Conclusion

A common observation is that these ceremonies take up a lot of time, particularly when looking at ceremonies like quarterly planning taking up a full day or more. However experience has shown that although there is an upfront investment in time, the speed gained later due to alignment, good planning, dependency management, fast decision making and shared understanding, more than make up for the time investment.

I typically recommend starting with quarterly planning and Scrum of Scrums however, when scaling, it’s best to introduce any scaled agile ceremonies as the need arises. For example, if you begin to find that you are regularly needing to escalate and solve cross-team impediments, then it would make sense to introduce a Scrum of Scrums. Introducing too many agile ceremonies before there is a clear need for them can lead to the ceremonies not being valued.