Why Isn't Your Current Approach to Scaling Agile Working?

Having trouble scaling your agility? You’re not alone; even organizations who have agile success in isolated pockets have trouble scaling that agility to the broader organization. The challenges express themselves in familiar patterns. Do any of these look familiar?

1. Your copy of another organization’s model doesn’t work
2. Your organization’s design conflicts with the goal of agility
3. You are trying to “copy and paste” what works for one team to all teams
4. You are independently optimizing different parts of the organization
5. You are under-invested in agile engineering practices

In this paper, we discuss common systemic challenges for scaling agility. We close with a comparison between the approach to these challenges by popular scaling frameworks.

Your copy of another organization’s model doesn’t  work

Sustaining agile at scale requires a change in organization structure, working policies and behavior. Like any other change at scale, it is a challenging task.

A quick fix is to copy a successful approach that was used by another organization. While that might give you benefits in the short term, over time this approach will very likely not be successful.

Why? Because there are no shortcuts in an agile journey. You must work through what agility means to you and how you will work to support it; you cannot copy someone else’s answers because their questions (or challenges) are different than yours.

When looking to scale organizational agility, the people in your organization need to own their new way of working. For that to happen, they will have to create their own process that works in their specific context. When people create their process, they will learn what works for them, and then a new culture ‘the way we do things here’ will emerge.

To implement someone else’s model is like providing an answer before knowing the question, which likely will not be successful. Instead, consider to start with the simplest process that works; then build upon it using Empirical Process Control and a framework that makes transparent to all what to improve; that framework is called Scrum.

There is a story that in 2001 Toyota wanted to publish a book called “The Toyota Way”.  Upon hearing of this,  their CEO said he opposed the title, suggesting it should be called “The Toyota Way 2001” because next year their way of working would have changed.

True agility enables an organization to continuously adapt to a changing world. When you short-cut your path to agility by copying someone else’s “model”, at best you’ll simply be a poor imitation of where they were at some point in the past.

Your organization’s design conflicts with the goal of agility

Organizations pursue agility to improve their ability to adapt to changing market conditions. The agile way of doing that is to learn faster than your competitors. Achieving this at the organization level requires the organization to have a design that is optimized for learning fast and adapting to change.

Organizational design that optimizes for agility provides the following benefits:

• Improved transparency in the performance of products and services, enabling better management of strategy execution
• Improved ability to allocate teams and money to achieve specific outcomes,  aligned with strategy
• Faster decisions, enabled by people who are closest to the problem and can make decisions with the right information at the right time
• Improved application of capital and people to shifting market conditions
• An organizational culture that sets and achieves high goals

All of these things sound good, but they don’t happen by accident. The design of the organization has to be specifically aligned with the goal of adaptability. Traditional organizational design is optimized for different goals, usually around resource utilization and predictability of outcomes. This may impede their ability to adapt to the following scenarios:

• Their preference for predictability means that they focus on creating detailed plans and measuring performance against plans. Deviations from plans are met with efforts to bring about compliance with the plan, not adopting the plan to new realities.
• Their tendency to punish deviations from plans reduces transparency, so that information showing the plan may be wrong is hidden as long as possible so as to avoid punishment.
• Their preferences for hierarchical control means that decisions are made based on a person’s level in the organization, not their proximity to the problem to be solved or the customer to be served. This can delay decisions making.

Let’s illustrate this by comparing the design of a Formula 1 car versus an off-road rally race car:

A Formula 1 car is optimized for speed and maneuverability on a known and well-paved circuit that is tightly controlled. While it may have to deal with variable weather, it has a dedicated pit crew to deal with mechanical problems, and there are no route-finding challenges.

An off-road rally team, such as those that race in the Dakar Rally, must carry all their own spare parts. They must deal with variable route conditions, and be able to improvise to reach their goal faster than other competitors.

Both Formula 1 cars and off-road racers have speed as their goal, but the degree of unknowns in an off-road rally means that the team and the car must be highly adaptable. Formula 1 cars are faster, but only because they operate in a much more controlled environment; in a rally, they would break down irreparably almost immediately.

Organizations in today’s world find themselves in a race much more like an off-road rally than a Formula 1 race, in which adaptability to changing conditions determines the winner.

A common organizational design is Hierarchy

As noted above, Hierarchy optimizes for efficient conformance to a plan in which deviations from the plan are quickly identified and eliminated.

John Kotter highlights some other importing goals of the Hierarchy.

...the challenge is that, at both a philosophical and a practical level, the Hierarchy (with its management processes) opposes change. It strives to eliminate anomaly, standardize processes, solve short-term problems, and achieve stopwatch efficiency within its current mode of operating...

Agility, by its very nature, has to assume that there are conditions in which the plan is wrong and needs to be either revised or scrapped. This is threatening to a hierarchical organization; you cannot optimize for control and efficiency and at the same time optimize for adaptability and speed of learning. Therefore, if you make superficial changes to the organizational design, the old systemic goal remains.

When the scaling initiative starts challenging the current power structures, it will very likely be undermined because the system will try to maintain its old goal. People will refer to the current standard working agreements and policies and use them to refute the new way of working. This happens not because the people do not want to change, but rather because the system in which they work expects them to resist.

You are trying to “copy and paste” what works for one team to all teams

Another common misconception is that scaling agility means that only teams have to change, while the system of management, the organizational structure and policies, and the overall culture of the organization can remain largely the same. Organizations that subscribe to this belief scale agility by copying and pasting Scrum Teams: Each new Scrum Team adds a Product Owner with its team backlog, a Development Team and often a Scrum Master too.

This strategy starts to break down quickly when multiple Scrum Teams need to work on a single product. As they add more Scrum Teams, they need to coordinate and, in response, they add more process, and more coordination roles to manage dependencies. Each added team has a tendency to locally optimize their own output without considering the whole.

Adding more processes makes everyone feel that the process is responsible for ensuring things are right, which destroys the teams’ ownership and accountability; improving the process is someone else’s problem. Adding hand-offs between teams and customers also destroys customer empathy, and reduces the teams’ understanding of the product.

Finally, the added team backlogs reduce the transparency of progress at the whole product level and require extra status and alignment meetings. All of this added complexity reduces the adaptability of the organization.

You are independently optimizing different parts of your organization

When you try to scale agility in the Hierarchy, you focus on making the existing structures work in an agile way, which keeps the people and teams isolated from one another. Having teams that are functionally siloed, such as an agile business-analysis team, an agile architecture team, an agile project management team, or a DevOps team are the result - teams that cannot deliver anything on their own. A similar problem exists when teams focus on single components, resulting in an agile database team, an agile UX team, or an agile Java team - none of these teams can deliver something of value on their own.

Assuming that increasing the performance of each of these teams separately will increase the performance of the whole is a mistake because it ignores the critical problem of how the teams work together to produce working product.:

There are many places where making the performance of the part worse will improve the performance of the whole. The performance of a system depends on how the parts interact, never on how the parts act taken separately.

Professor Russell L. Ackoff ( From Recreating the corporation. Oxford University press 1999.)

Without the ability to create a working product, teams cannot know whether they are building a solution that meets customer needs. This is true even when you are not scaling, but its impact is amplified when scaling. To solve this problem, teams need to be cross-functional, and cross-component, taking on the responsibility to solve a customer’s problem, to deliver to them a complete end-to-end solution.

This means:

• Designing your organization around your products to deliver better customer outcomes, without delays
• Creating a product organization consisting of feature teams that work on a single product
• Moving to a cross-functional line organization where cross-functional teams report to cross-functional managers.
• Introducing a budgeting system where the Product Owner is empowered to make investment decisions based on feedback that is received from the market and customers or users
• Changing the management system and the culture so that they value learning and collaborative cross-functional teamwork, and continually expand the capabilities of both teams and team members, empowering them to solve problems and supporting them as they grow their capabilities.

You have under-invested in agile engineering practices

While many organizations understand that they need to hire coaches to work with agile teams, helping the Development Team, Scrum Masters, and Product Owners improve their ways of working, many do not understand the importance of hiring coaches to improve the technical excellence practiced by those same teams. As a result, the organization is unable to scale because they can’t sustain or improve the quality of the code.

In agile software development, the key point is that your software is soft enough so that you can change it quickly, at low cost, and can validate if it delivers what is expected. The way to achieve this is to craft high-quality software using agile engineering practices. You can have all the processes, sticky notes, Scrum Masters and agile organizational design you want, but without high-quality software and high competence in agile engineering practices, the process part can only take you part-way.

Scaling agility requires effective automation of the build and test process, for starters, and eventually complete automation of the entire delivery pipeline. Scaling also requires that the product being built has a decoupled architecture, so that any part of the product can be easily changed or replaced. The version control practices matter too. Trunk-based development, especially the elimination of feature branching and continuous integration, is essential for teams to coordinate effectively, and to keep technical debt from invisibly and insidiously growing, and these are just a start.

Scaling frameworks take different approaches to these challenges - A comparison between SAFe, LeSS, and Nexus

Differences between different scaling frameworks reflect deep philosophical differences on the primary challenges in scaling agility. SAFe attempts to be minimally disruptive so as not to invite conflict, so it tries to adapt itself to the existing organization as much as possible. LeSS views the existing organizational design as the fundamental barrier to develop a product with multiple teams,  so it tackles this head-on. Nexus does not try to solve the organization problem and instead focuses on developing large products with multiple teams working together. These differences are expressed in the following table with comparisons on how they map to the 5 challenges:

Conclusion: scaling agility means developing organizational agility

You can’t scale agility by copying others. You have to learn for yourself what process, structure and policies work in your specific context. To sustain and grow agility, the people in your organization need to own their process so that they will improve it over time, and for that to happen the people need to be a  part of creating their process from the beginning. 

Along the way, you should be looking for opportunities to make some changes:

• Changes in your organizational design: New working agreements, policies, and a new organizational structure could be needed so that the focus moves to maximize value instead of utilization. Value flows horizontally in an organization, not vertically, as most organizations are structured.
• Changes in skills: People will probably need to learn new practices to be able to deliver frequently a high-level product that is co-created with their customers.
• Changes in behavior: The people themselves will be asked to work in and with real teams that take ownership of team results.

Agility is not some sort of process, tool, or framework that organizations adopt; it’s a way of thinking and working that embraces experimentation and learning. There are no shortcuts that avoid all the hard work, but the good news is that learning and experimentation can be fun, and they make navigating the unknown less daunting. You don’t have to have all the answers, you just need a goal and a willingness to try new things.

About the Authors

Cesario Ramos has worked in agile product development since 2001. Nowadays, he works worldwide as an agile organization coach and product development expert. He has worked at various organizations, including high tech, large banking, insurance and telecom. Cesario is the author of the book ‘EMERGENT – Lean & Agile adoption for an innovative workplace’ and co-author of the book 'Scrum Patterns’. He regularly speaks at conferences around the world and co-organizes the LeSS conferences. He is also a Certified LeSS Trainer and Professional Scrum Trainer at Scrum.org. In 2010 he founded AgiliX, a consulting company, that provides consulting and training worldwide.

Kurt Bittner has more than 30 years of experience delivering working software in short, feedback-driven cycles. He has helped a wide variety of organizations adopt agile software delivery practices, including large banking, insurance, manufacturing, and retail organizations, as well as large government agencies. He is a former technology industry analyst with Forrester Research. His focus is on helping organizations build strong, self-organizing, high-performance teams that deliver solutions that customers love. He is the author of four books on software development-related topics, including The Nexus Framework for Scaling Scrum. He is based in Boulder, Colorado and serves as VP of Enterprise Solutions for Scrum.org.