Scrum framework was originally envisioned to be used in a simple and focused environment— one team of up to 9 people working with one Backlog to deliver a (relatively) small-scale project.
Over time, however, the framework started gaining ground in the enterprise landscape. In such an environment, everything is larger, including the organizational structure, the number and the size of teams working on a single product, budgets, goals, etc.
The process of managing and running multi-team Scrum projects is a daunting endeavor. There are so many moving parts and nuances one has to synchronize and oversee.
In essence, you need to scale up Scrum and that is no simple endeavor. Today, we will provide a brief overview of different approaches to scaling Scrum and in following articles, we will take a closer look at the most popular approaches.
Going Over the Basics
The scale of implementing Scrum doesn’t necessarily alter the core of the framework.
You still adhere to the same roles, artifacts, values, and principles. Planning is done collaboratively and teams are self-organizing. You usually keep one Backlog for all teams in order to streamline the whole scaling process.
At the same time, scaling brings forth more interactions, requirements, complexities, and events. It affects domain, people, and technology. Moreover, it prompts you to rethink the hierarchical order (as un-agile as this sounds), as well as vital activities like testing and integration.
For instance, the pivotal role of a Product Owner has even more weight. This individual has to coordinate several teams and analyze the benefits, risks, and costs. The result of these efforts should be tighter collaboration and more open communication.
Beyond these basics, one crucial task lies: picking the optimal framework for scaling Agile.
First off, we have LeSS, a highly flexible, minimalist, and non-prescriptive approach. Instead of adding more complexity, it aims to simplify things by establishing some ground rules. Thus, it’s considered a no-brainer by many practitioners.
The governing principle is to use as few processes as possible to keep multiple teams on the same page. There’s a shared Backlog, Sprint Review, and Product Owner. The processes themselves are essentially Scrum, but with slight modifications.
Furthermore, LeSS has two different models. Framework 1 is tailored to smaller organizations up to 10 teams (with seven numbers each). Framework 2 is suited for larger companies. In both cases, one Product Owner manages multiple teams.
Not surprisingly, industry application cases show that LeSS is more effective in smaller environments. It’s a great starting point for those who’ve already laid the Scrum groundwork.
[email protected] is even less prescriptive than LeSS. It was developed by Jeff Sutherland, one of the founding fathers of Scrum. He wanted to address the key points of friction along the scaling path.
As a result, he envisioned [email protected] as a meta-level framework. It can overlap with other methodologies on our list or it can be its own custom model. The main advantage it offers is the freedom to adjust scaling to your unique business case.
The two main inroads to successful development are Product Owner Cycle and Scrum Master Cycle.
The former process involves strategic vision, Backlog prioritization, release planning & management, and product/release feedback. The Scrum Master Cycle revolves around cross-team coordination, continuous improvement, and impediment removal. The two cycles are intertwined and mutually dependent.
Scrum of Scrums
The next approach to scaling is one of the oldest and most common.
Namely, Scrum of Scrums integrates multiple teams working on the same project. It promotes close collaboration so that outputs can be aligned across the board. This process is integral to handling overlaps and sequencing of events.
Scrum of Scrum meetings are events that pave the way to successful implementation. They take place once a week at minimum and once a day at maximum. Teams send their Scrum Master or other representatives to attend these meetings.
The logic behind it is to get rid of impediments, discuss past accomplishments, and plan for future sprints. Perusing these goals consistently allows even large enterprises to tap into the Agile way of doing business.
Nexus is a lightweight framework geared toward larger companies.
It maximizes transparency and accountability, two values that often get lost during scaling. The methodology encompasses everything from practices and skill sets to infrastructure and software requirements.
The main difference from other models is the addition of a new role— Nexus Integration Team (NIT), as well as an artifact called Nexus Sprint Backlog. NIT is tasked with overseeing the development of working software (“Done”). It’s composed of delegates from all Scrum Teams.
The new Backlog ensures continuous workflow and its refinement. It’s a tool for visualizing the work that needs to be done in a single Sprint. It gives you a chance to face integration challenges and work out dependencies between teams.
Mastering the Art of Scaling
Transitioning from singular to scaled Scrum is no cakewalk.
First of all, one can organize multiple teams in many different ways. That is to say you need to educate yourself to navigate the maze of decision-making.
While at it, weigh the pros and cons of different large-scale Agile frameworks. For better or worse, no two companies are alike and there are no one-size-fits-all solutions.
The next task is to select the right metrics to evaluate the value impact of the scaling process. They help you refine your techniques and strategies based on fresh data and insights.
Just make sure to get all stakeholders involved in the process, especially those with authority to make decisions. Find the best way to apply Scrum at scale together. Focus on optimizing the product structure and break down projects into smaller, digestible bits.
We would also be remiss not to mention the fact that many (renowned) agile and Scrum practitioners see the efforts to scale Scrum as inherently negative and destined to fail. That being said, many organizations have done it successfully, still feeling the benefits of Scrum despite the fact they took it to a more enterprise-scale level.