Scrum and kanban are two popular agile frameworks used at the team level. Over the past decade, as their popularity grew, the industry began to scale agile to suit larger organizations. Two popular methods emerged to facilitate this: the scrum of scrums, and the Scaled Agile Framework (SAFe). Both are great starting points for scaling agile within an organization.
Wherever you're starting from, realize that your effort to scale agile needs to be agile itself. Choose a framework that will start you on the right path, and adjust it as business needs evolve and new insights emerge. (The trick is not to adjust it so much that it's no longer recognizable as agile.)
Scrum of Scrums
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.
To get started, select a member from each team to represent them at the scrum of scrums, ideally someone in a technical role. The scrum of scrums is a democratic meeting. A scrum master can help facilitate the stand-up, but it's run just like any other team stand-up. This is a daily meeting, and should be short–no more than 15 minutes. It will open doors for knowledge-sharing and surface important integration issues because technical stakeholders are informed early and have a forum to engage.
ProTip: Some teams may choose to have the scrum of scrums only 2 or 3 times per week but run the meeting a bit longer than 15 minutes. Keep in mind, though, the scrum of scrums is not a boring status meeting where team members tune out. Keep these stand-ups focused. Surface issues that affect the group, decide what actions (if any) need to be taken and by whom, then close the meeting.
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.
Scaled Agile Framework (SAFe)
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.
"How do I get started?"
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.
Whether your organization starts with scrum of scrums, SAFe, another established methodology, or a homegrown process, remember that the process itself should be agile. Keep trying new ideas and making incremental improvements. Also keep in mind that development and agile project management tools become an important part in scaling agile. 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.