How would you scale Agile ceremonies for a team of 50+ members?

Scale Agile ceremonies by creating sub-teams, each with its own Scrum ceremonies. Use Scrum of Scrums to coordinate between teams, ensuring alignment and resolving dependencies. Leverage tools for communication and maintain a focus on collaboration and transparency across the larger team.

First of all, a very big team would not be able to work efficiently, so I would divide that 50+ team in teams of no more than 10 individuals. Then, we can scale or descale with frameworks like SAFe or LeSS, but before that, we have to diagnose the value streams that the company has, in order to build multifunctional-self organized teams that can syncronize well between them, so they can achieve the same Objectives. We can start with that, as this is a long process of understanding, teaching, coaching, mentor and facilitate not only teams, but also and more important first the stakeholders that will support all this.

Scaling Agile ceremonies for large teams, like in LeSS, means each team conducts its Scrum rituals—daily stand-ups, sprint planning, reviews, and retrospectives. Coordination happens through product-level meetings, fostering autonomy with shared alignment across all teams.

When you're managing a large team using Agile, consider using the Large-Scale Scrum (LeSS) framework. LeSS is tailored for multiple teams collaborating on the same product. Each team conducts its own Scrum ceremonies like daily stand-ups, sprint planning, reviews, and retrospectives. Additionally, representatives from each team join in a coordinated meeting to align on the overall product vision. This setup balances team independence with unified direction, crucial for effective collaboration in larger Agile setups.

These strategies will help Daily Stand-up: - Sub-teams of groups of 5-10 members. - Reps attend cross-team meetings for updates and issue resolution. Sprint Planning: - Define clear, prioritized user stories and tasks. - Sub-team Sessions, Plan separately, align in cross-team meetings. Sprint Review: - Sprint Demo, Multiple presentation stations, rotate teams. Sprint Retrospective: - Sub-team Retro, Focus on feedback; consolidate in larger meetings. Backlog Refinement: - Maintain visible priorities; refine items independently, ensuring alignment. General Strategies: - Utilize digital tools for collaboration and communication. - Scrum of Scrums for coordination. -Ensure team competency. -Encourage transparent communication.

In scaling Agile for large teams like 50+, SAFe (Scaled Agile Framework) offers a structured approach. It organizes teams into Agile Release Trains (ARTs) for synchronized planning and execution. This method fosters alignment and centralized decision-making, crucial for managing complexity in enterprise-level projects.

The Scaled Agile Framework (SAFe) is widely used for scaling Agile practices effectively. It blends Agile and Lean principles into a structured approach. In SAFe, large teams are organized into Agile Release Trains (ARTs). These are groups of Agile teams that collaborate closely in planning, committing to goals, and working together on execution. SAFe focuses on synchronization, cross-team planning, and centralized decision-making to ensure alignment and smooth operation across complex organizations.

Align the teams around a shared vision and roadmap through a Program Increment (PI) Planning event. During PI Planning, all teams collaboratively plan their work for the upcoming increment. Conduct regular ART. Use Inspect and Adapt workshops at the end of each PI to review progress and improve processes across all teams.

To scale Agile for a team of 50+, I use the Scrum of Scrums method. I break the team into smaller groups (6-10 members). Each group has its own stand-ups, sprint planning, and retrospectives. Representatives from each group meet regularly to discuss progress and any dependencies. We use tools like JIRA to keep track of tasks and ensure everyone is on the same page. This approach keeps everyone aligned, working together, and focused on success.

To scale Agile ceremonies for a large team, the Scrum of Scrums technique is highly effective. It works by having representatives from each sub-team meet regularly to discuss progress, challenges, and coordination. Think of it as a stand-up meeting for team leads or Scrum Masters. The aim is to improve communication between teams and ensure everyone is aligned on goals without delving into the specifics of each team's daily stand-ups. This keeps the overall workflow smooth and synchronized across the larger group.

To scale Agile ceremonies for large teams like yours, consider using the Scrum of Scrums method. It involves representatives from each sub-team meeting regularly to discuss progress and challenges. This promotes alignment across teams without delving into each team's daily details, ensuring cohesive direction and communication.

Scaling Agile for 50+ members necessitates adapting ceremonies to avoid cumbersome meetings. Scrum of Scrums offers a streamlined approach. Representatives from each sub-team participate in regular meetings, discussing progress, impediments, and cross-team dependencies. This promotes transparency and alignment across the larger team, allowing for quicker identification and resolution of blockers. It also ensures everyone stays informed without requiring the entire team to participate in every daily stand-up, optimizing time and maintaining Agile's collaborative spirit.

I'd try Nexus for our 50+ team. I'd form 3 Scrum teams of 9 each, then pick a sharp Nexus Integration Team (NIT) with our best Scrum Master and top devs. We'd start with Nexus Sprint Planning, focusing on dependencies. Daily Nexus Stand-ups would tackle cross-team issues. NIT would handle integration challenges. Nexus Sprint Reviews might be rough at first, but we'd improve at showcasing integrated work.It should help with scaling, but I'd watch communication closely. Nailing the cross-team Definition of Done would be key. Worth a shot if you're Scrum-focused. Not perfect, but better than basic Scrum at this size. Adjust as needed.

For 50+ team, I'd set up a master Kanban board with sub-boards for each unit. We'd use swim lanes for different projects or value streams. I'd implement WIP limits to prevent bottlenecks. Daily stand-ups would focus on flow, not status updates. We'd track cycle time and throughput. Bi-weekly service delivery reviews would spot improvement areas. Kanban's flexibility helped us handle varying workloads better than sprints. The key was visualizing all work and improving flow. It took time to get everyone on board, but it paid off. If you're dealing with unpredictable work, try Kanban. It worked well for us at scale. Adjust as needed for your team.

Scaling Agile ceremonies for a team of 50+ members requires strategic segmentation and coordination. Divide the large team into smaller, manageable sub-teams, each handling specific aspects of the project. Conduct daily stand-ups within these sub-teams to maintain focus and efficiency. Implement Scrum of Scrums meetings to synchronize progress across sub-teams and address interdependencies. Use regular sprint planning, reviews, and retrospectives at both sub-team and overall team levels to ensure alignment. Leveraging tools for collaboration and communication will also streamline processes, ensuring everyone stays informed and engaged.

When I scaled Agile for 50+ folks, I split us into 7- 8 person squads. Each ran daily standups and 2-week sprints. We did weekly Scrum of Scrums for cross-squad sync. I set up monthly demos and quarterly planning. JIRA helped with async updates. Squad leads improved communication. Keep ceremonies short. Rotate sprint review presenters. Gather feedback and adjust often. Consider SAFe, but don't blindly adopt. Maintain agility while scaling. It's trial and error, but you'll find what works. This approach kept us agile and aligned. It wasn't perfect, but it got the job done. Tweak as needed for your team.

Understanding the nature and context of the work will directly influence what types of scaling works best. Most scaling approaches generally begin with the assumption that a single product or service is being delivered. In a commercial, single product context, I prefer LeSS and Nexus. My experience with scaling in the DoD and federal space ranges from contexts where 10 teams are supporting 10 distinct products with different stakeholders to 10 teams supporting a single data warehouse with over 70 distinct data feeds and over a dozen distinct stakeholder groups. I've found SAFe, with its focus on dependency management, is often the default scaling approach in contexts where separation of duties and check gates are mandated.