Why is Agile Scaling So Hard?

Agile scaling is always a hot topic for students and organizations dealing with the complexities of multi-team execution. The questions I tend to get as a trainer and coach range from deep, low-level issues of mechanics (“How many times a week is best for a Scrum-of-Scrums meeting?”) to very high-level concerns about practicality (“Does SAFe ever work?”). But the question I get asked most often is one that sounds the simplest: “Why does Scaling make everything so hard?”

In a nutshell, scaling creates three core challenges for any organization that’s trying to deliver as a team-of-teams. There’s an upfront challenge of how we decide and parse product vision across the structure. There’s a mid-sprint challenge of how to deal with cross-team dependencies. And there’s a back-end challenge of how we get and use feedback about product and process at each of the levels of structure we decide to use. There are a bunch of formal approaches to Scaling marketed today, and each of them makes differing constellations of choices on each of these issues.

1. Up-Front Challenge

The first challenge that confronts any team-of-teams approach to Agile delivery has to do with how product vision is visualized and made available to teams. The two largest questions here are, “How many layers of product backlogs will there be?” and “How many layers of Product Owners will manage those backlogs?”

How Many Product Backlogs?

A team-of-teams situation complicates backlog refinement and sprint planning in several ways. One of the most obvious is the increased throughput of PBIs, which means a Product Owner (or Product Owners) has to facilitate the refinement of significantly more PBIs to a level of ‘ready’ in time for Sprint Planning discussions. Another would be the question of how many people should participate in those backlog refinement meetings: every developer on every team or only select representatives from each team?

One approach to scaled backlog structure is to maintain a single, unified product backlog. All teams contribute in some way to the refinement discussion of the PBIs, and all teams are pulling from that shared backlog when they plan Sprints. You see this structure in Large Scale Scrum (LeSS) and Nexus. Advantages of a unified product backlog include greater clarity of how individual team actions serve the product goal and an easier shared understanding of the impact of reprioritization across all teams. Disadvantages include having to cede more ‘build stuff’ time during the Sprint to these ‘overhead’ type discussions and significantly larger planning meetings (which are harder to facilitate).

The other approach to scaled backlog structure is to visualize the product goal across two (or more) levels, with higher level goals in a program or portfolio backlog which are decomposed into team-sized PBIs within one or more team backlogs. You see this structure in Scrum at Scale (S@S), Less HUGE, and Scaled Agile Framework for Enterprise (SAFe). Advantages of a hierarchical approach are that teams can focus their attention on just refining the items in their queue. Disadvantages are that it is much harder to understand how impediments on one team affect plans across the program, and it’s easy for team-level PBIs to become divorced from any understanding of how they support the product goal.

How Many Product Owners?

For every product backlog, we declare, we also need to determine who owns that queue. If we’re scaling but sticking to a unified product backlog, we may decide to maintain a single product owner who would have all the same responsibilities as they would if we weren’t scaled. This approach is established in LeSS and Nexus. A strength of this is that it’s easier to maintain clarity of product vision, and authority on product choices is very clear. A downside of a single product owner is that it’s easy for a single person to be overwhelmed by the time commitments of handling backlog refinement with many teams while also maintaining open communication with potentially many distinct groups of stakeholders with needs that only partially overlap.

Even with a unitary product backlog, we could also choose to split the product owner function into ‘strategic’ and ‘tactical’ levels. The Strategic PO owns forest-level questions of product direction and priority, and a Tactical PO is on every team, focusing on tree-level backlog refinement questions. I’m not aware of a formal scaling approach that uses this, but it was how I handled things in some of my earliest scaling experiences. This frees up more direct PO attention for team-level refinement, planning, and mid-sprint decision-making, but organizations need to be careful in deciding which level of PO gets to make what kind of choices.

For other scaling frameworks, notably SAFe and S@S, the configuration is to have declared POs for each level of product backlog in use. This certainly makes it easy to clarify questions of decision-making authority but tends to have the side-effect of making whole-program vision murkier and inhibits the ability of the Product Owners at the lowest levels to nimbly readjust toward value when an opportunity arises or an obstacle is encountered.

2. Mid-Sprint Challenge

However we choose to handle the up-front challenges, let’s assume we’ve found a way to organize product vision and parse it across an array of teams. Then we immediately have to confront the mid-sprint challenge of how these teams will handle cross-team dependencies that arise during iterations. We start by reducing dependencies by rigorously adhering to the notion that every team should be cross-functional, and ruthlessly restating PBIs to remove dependencies with the use of placeholder elements where possible. But what about the ones we can’t remove, or the ones we didn’t see coming? We need an event to bring visibility to issues that are too large for a team to fix for themselves and solicit stakeholder support toward resolution.

For S@S, Nexus, and SAFe, that mechanic is a “Scrum of Scrums” meeting. This event occurs throughout the sprint (though how many times varies from one framework to another). Each team sends representatives to speak and listen on behalf of their colleagues, in a pattern that’s similar to the daily Scrum meeting for an individual Scrum team. An advantage of this approach is that every team gets weekly or even daily insight into what’s happening on other teams, and a shared forum for self-organizing cross-team impediments exists. A downside is that Scrum-of-Scrums meetings can quickly devolve into long-winded, ineffective status briefings with no useful communication or collaboration.

The alternative recommended in LeSS is to replace the Scrum-of-Scrums type meeting with the informal mechanic of “just go talk.” In this approach, teams collaborate on an ad-hoc basis as needed and engage others when needed. Teams may also “send a listener” to attend other teams’ daily Scrum meetings as an added awareness step. This certainly cuts down on the possibility of “meetings just for meetings sake.” To be effective, it does require that teams have enough organizational understanding to know which teams/groups to huddle with to solve a problem that’s bigger than themselves. This generally means that the scaled structure has good cross-program clarity of vision and team function, which likely means that they’re serious about coaching themselves to be less scaled over time.

3. Back-End Challenge:

The last – and maybe most important! – challenge inherent in scaling agile methods has to do with how we’re going to organize iterative feedback and learning. An enormous strength of single-team Scrum is that every sprint concludes with a Sprint Review meeting where the group receives feedback about the value being delivered (in the form of functioning increments of the product) and a sprint retrospective where they can inspect their growth toward becoming a high-performing team. Scaling complicates these feedback loops significantly.

Teams must preserve some mechanic to inspect contributions toward product goals, while the program must also institute some method of understanding the holistic contribution of all teams in a way that nimbly informs program- and team-level backlog refinement. Teams typically continue their own individual retrospective discussions, but the program also needs to have mechanics to identify and adapt around issues that are bigger than a team can solve by itself. Surveying the most popular approaches to scaling, we find similar answers to the feedback question, with the major divide coming down to the issue of cadence.

In Nexus, Scrum@Scale, and LeSS, the approach is to implement program-level feedback loops within a single-sprint cadence. This means that teams plan a collective sprint together and then execute their respective team’s portion individually. At the end of the iteration, all teams hold a combined Sprint Review meeting so everyone involved gains a shared understanding of what new capabilities have been added to the product by all teams.

This discussion might also include a sharing of technical “lessons-learned” where significant obstacles have been popped up, so other teams can avoid the same pitfalls. Teams then conduct their own individual Retrospectives, followed by a program-level retrospective that includes representatives from each team, as well as coaching, leadership, and other stakeholder support where the program can inspect and adapt on larger issues. An advantage of this approach is that teams and the entire program are receiving product- and process-feedback every single sprint and maintain a single sprint rhythm of several weeks, which helps preserve the nimbleness we’re aiming for to achieve business agility. A downside is that those program-level meetings do add more overhead to each sprint, cutting into the available work time of teams during each iteration.

An alternative specified in SAFe is to include program-level feedback loops at the end of a multi-sprint cadence. A grouping of teams (an “Agile Release Train”) come together for a 2-day planning session called a “Program Increment Planning Event” where they map out milestones, team objectives, and dependencies for the next “Program Increment” (or “PI”, usually three months). Teams then execute sprints independently. The very last iteration of the ‘PI’ is called the “Innovation and Planning Sprint,” where teams finish up last-minute commitments, conduct innovation games to generate ideas for the next PI, and prepare for the next planning event.

Product- and program-level retrospective discussions are part of the upfront agenda of the planning event, prior to introducing themes and priorities of the next PI. This has the advantage of maximizing team working time during individual sprints. A downside is that the way this pattern is generally realized is that teams don’t get a whole-product view of how their work contributes to the whole. Another downside is that program-level retrospective discussions are infrequent (typically only four times a year!) and tend to be superficial reviews of metrics.

So, What’s an Enterprise To Do?

Unfortunately, there are no magic bullets. The single best piece of advice I can give when it comes to Agile scaling is: “don’t.” Invest in making teams as independent and cross-functional as possible, removing the multi-dependencies that make scaling seem necessary. Map out value streams and restructure teams so that teams contain entire streams, and not the other way around. Reduce your institutional focus on maximizing output and within-team productivity in favor of visualizing outcomes and the cycle-time-to-value.

But failing that, the next best advice I can give would be to think of any Scaling framework as a starting point, not a goal. You’ll have to tailor the choices and mechanics involved until you discover a structure that is functional and capable of realizing some semblance of Agility. I call this “minimum viable bureaucracy”: the smallest set of rules we actually need to get out of our own way. MVB is something you discover through experimentation, so empiricism (not dogma) still needs to be your primary mindset.

But you don’t have to go it entirely alone! A good coach – one with real-world scaling experience – can save you a lot of time, money, and heartache. And, more importantly, they can also help you focus your attention on the questions that matter most as you wrestle with each of these challenges. If you’re looking for amazing, experienced enterprise Agile coaches, we’ve got you covered. From planning a transition to rescuing a transformation that’s gone off the rails, from individual teams to very large enterprises, from the private to the public sector, our people have the skills, knowledge, and stories to help you succeed.