Agile at scale

Scrum is the most popular agile framework for individual teams. When several scrum teams work together on a large project, scrum of scrums is the natural next step for scaling agile. The main component of scrum of scrums is a multi-team stand-up. This is not a status meeting. Nor is it a meeting for scrum masters to talk about agile process. It's a short meeting to keep people from around the organization abreast of important issues across the portfolio.

Typically, a scrum of scrums will cluster around a large work item like a theme. They're not meetings to discuss team-level epics or releases unless these items involve the other participants in the meeting.

Some organizations also find value in extending other agile ceremones like sprint planning and sprint retrospectives to the scrum of scrums. Representatives meet just prior to their respective team's sprint planning and share what's likely to be pulled into their upcoming sprints. This is a great way to avoid blocking dependencies between teams or address integration pain-points before they become criplingly painful. For retrospectives, the scrum of scrum meets after their team's individual retrospectives and discuss action items that may require cross-team coordination to resolve.

While scaled-up planning and reflection may not need to be done every sprint, these are important parts of agile culture. Start with a cadence of once per month and adjust the frequency as needed. 

Another way to scale agile in large organizations is SAFe (see diagram). Pioneered by Dean Leffingwell, SAFe takes a more structured approach to scale agile than scrum of scrums. SAFe describes three levels in the organization: portfolio, program, and team. This structure typically appeals to larger organizations, because SAFe employs a tiered approach for the delivery of work.

In SAFe, large areas of related work, called themes, map to business epics and architectural epics. Business epics describe customer-facing initiatives such as launching a new product. Architectural epics are company technology initiatives such as migrating from Windows- to linux-based servers. These epics make up the portfolio backlog.

As a business begins to execute on the portfolio backlog using priorities set by product management and technical leadership, each business or architectural epic becomes an agile program with its own agile release train. Several agile teams work together on each program within the organization. Each program contains several features and architectural work items that compose the program backlog.

Finally, each team has its own backlog derived from the program backlog. Individual teams work together to deliver working software each iteration while coordinating with other teams within the program.

Glad you asked! When scaling agile across an entire organization, focus on “just enough”. Too much process saps an organization of agility, and not enough leaves senior leadership without visibility. Successful agile development at the portfolio level mirrors agile development at the team level: the same transparency, responsiveness to change, and focus on integrated, working software can be applied to any portfolio program.

Make sure the organization's toolset meets both the needs of the agile team as well as the senior leaders of the portfolio. Finally, use retrospectives at all levels of the organization to get insights into how to further optimize the company’s process to deliver software faster, with higher quality and greater confidence.