4 Reasons Why Agile Scaling Goes Wrong

Agile frameworks are predicated on the notion of forming small, cross-functional teams. A low number of people (generally less than 12, total, whether the team is using Scrum, Kanban, XP, or something else) enables self-organization, self-management, and shared clarity of purpose. All of these factors are necessary for teams to reach a level of stability and effectiveness. These small but mighty teams use continual small-scale experiments to reach high levels of performance and value delivery. But sometimes we need to do big things, and we need to do them faster than a single, small team could get them done. In those circumstances, instead of adding more people to a team and making it dysfunctional, the preference is to add additional Agile teams. In the Agile community, that’s called “scaling.” Put simply, scaling means forming a team-of-teams to accomplish a shared goal.

But Agile scaling is a lot easier said than done. That’s why there are so many formalized approaches out there: LeSS, SAFe, Nexus, Scrum@Scale, DAD, DSDM… the list goes on. All of them assume that individual teams are using Scrum, and the Scaling framework itself is a list of practices, roles, and structures for answering questions above the single team level. There are significant differences in doctrine between each of the methods mentioned, so it’s hard to create a list of universal practices for scaling success. And yet, having worked in and coached many scaled programs over the years, there are some striking similarities that pop up when an organization fails at scaling. Here are four reasons I’ve seen scaling fail again and again:

1. Scaling before you’ve seen agility work at the team level

The best time to add more Agile teams and contemplate scaling is sometime after you’ve got at least one successful Agile team up and running. If your organization has never had a single Scrum team, it’s nearly impossible to leap from 0 teams to 20 functional Scrum teams instantly. And without teams that are individually effective, the choice of scaling framework becomes irrelevant. If none of your teams can safely deliver without setting the production environment on fire, SAFe won’t save you (and neither would LeSS, or Nexus, etc…). Getting your first Agile team going isn’t just about one small group of people getting familiar with the mechanics of something like Scrum; it’s also fundamentally an institutional growth opportunity. Just as the team is learning practices like self-organization, the company around that team is learning how to get out of the way of that team. Sorting out and removing institutional impediments to team-level Agility is a critical learning step necessary for your organization to become good at nurturing Agile teams. If that environment doesn’t already exist when you attempt to scale, teams will face a triple threat as they attempt to deliver value: 1) they’ll be fighting themselves as they learn to be a team 2) they’ll be fighting the additional complexity of being one part of a team-of-teams, and 3_they’ll be fighting all the legacy institutional anti-patterns that still lie in the way of both of those efforts.

2. Trying to manage complexity, instead of reducing it

Agile teams are supposed to be cross-functional. That means that each team, as a unit, has all the skills and abilities needed to go from an idea to a releaseable increment of value in a very short period (say, a week or two). If an organization’s existing structure is based on something like skill specialization, reorganizing for cross-functionality can be a daunting premise. So, instead, organizations sometimes adopt a scaling framework as the answer for how to be ‘Agile’ when anything a team does has to be worked on by other groups before it gets to ‘done.’ The rationale is that, by visualizing complexity and the cross-team dependencies that exist, we can maintain the structure as-is but increase predictability of delivery. Then, we can claim that we’ve embraced Agility. But true Agility is almost never what results. More value, better value, faster value delivery? Not so much. Instead, we get a lot of re-titling of people, additional meetings, and processes layered on top of our existing legacy ones. And we get to spend a lot of money and time in trainings. Instead of imposing structure on top of structure, we should be asking, “What is the least amount of process we need to get out of our way?” While the phrase, ‘minimum viable product’ gets a lot of play in the Agile community, when it comes to scaling we should be focused on ‘minimum viable bureaucracy.’

3. We continue focusing on output, instead of outcome

One of the best things about an independent Agile team is near-constant feedback about product direction and value delivery. If we’ve got an idea for a feature that will bring more users to an application, we can build it, ship it, and measure whether it’s having the impact we intended in a few days or weeks. But when a goal is broken into two or more layers of a stratified product backlog, capturing and understanding that feedback gets really difficult. Ideally, even when scaled, individual teams should still be building product backlog items that are ‘vertical product slices.’ This means that each item is coherent enough to test, demonstrate, and get feedback on. But if that lesson hasn’t been learned at the institutional level, I see organizations adopt scaling approaches that let them perpetuate old habits of formalized requirements decomposed down to the task level in some kind of re-named “requirements traceability matrix.”

That complicates fundamental questions, like, “Are we done yet?” If teams are working in vertical product slices, we should be able to answer that question on demand against any real-world objective. But where teams are  working on a set of horizontal slice tasks instead, we can’t expect to see impact on real goals until many teams are each done with their individual pieces. So instead of asking, “Are we done?” in real world terms like revenue or change in market share, the question defaults to, “What is the percent-complete of that epic?” And that means we’re focusing attention on output over outcome. Best case, you end up with a structure that’s great at doing stuff. Is it the right stuff? Who can tell?

4. Teams become cogs, and are robbed of critical context

Hierarchical backlogs of horizontal product slices don’t just create problems for product direction feedback. They also undercut the ability of teams to nimbly redirect effort to whatever thing would be most valuable for the enterprise. Imagine a Scrum team that’s one of twenty trying to collaborate to build some major initiative. And imagine that, in the middle of their sprint, they realize that one of the backlog items they intended to complete is not, in fact, possible. The expectation is that they should meet with the Product Owner to negotiate the best use of the remaining time and effort they would have spent finishing that item. But what if they can’t tell what’s the best thing to next? Their backlog is a list of technical items that don’t clearly map to end value. It’s probably also not clear exactly what the implications of their unfinished item might be for other teams, so how do they communicate it? Maybe all these questions can be sorted out in a day or two of discussions with every member of the product owner vertical in the structure, but meanwhile the team in question is spinning their wheels.

So, how do you proceed?

Whatever framework you’re trying to use, Agile scaling makes everything harder. It’s not something to do lightly, and it’s one circumstance where having some guidance from experienced Agilists who’ve seen things work – and not work! – can be a huge help. If you’re looking for amazing, experienced Agile coaches who’ve lived and breathed the complexities of scaling, our team at NextUp Solutions can help. For more information, visit our coaching page or email info@nextupsolutions.com.