One of the myths in the agile community is that agile development cannot be scaled. Just look up the topic online, and you’ll come across heated debates about whether or not agile can (and should) grow beyond the 3 to 9 member development team.
I’ve scaled and helped others scale agile development on multiple occasions in my professional experience. So I know and I believe that it can be done. But don’t take my word for it. In this post, I’m going to show you how some of the founders of the agile movement have built frameworks that help hundreds of companies scale agile successfully.
So is it true that agile development cannot be scaled?
Agile development can be scaled. To successfully scale agile development, organizations need to be explicit about their choice of agile frameworks and their implementation roadmap. They also need to ensure that agility is practiced by everyone in the organization, from entry-level employee to senior-level management.
To scale agile, you need to choose your agile framework well. In this post, I’m going to walk you through the different approaches to scaling agile that two of the most popular scaled agile frameworks take. As well as what to watch out for on your company’s agile journey.
How to Scale Agile Development
Before I begin, I’ll clarify what I mean when I use the term “development” and “developer.”
Many people think, for one reason or another, that agile only applies to the software development field.
Yes, it’s true that agile began as a movement among software developers. In 2001, a group of 17 programmers got together on a ski retreat and came up with the Manifesto for Agile Software Development.
But for the two decades that agile has been around, its applications have expanded well beyond the software development field and the IT department. Today, agile is a mindset and approach for product development. And anyone developing a product is, essentially, a developer.
So if you’re reading this as a leader or employee of a product or service company—or any company where complex problems need to be solved in a way where you don’t necessarily know the answer from the very beginning—agile is an approach that’s fit for purpose and fit for use. Whether your company builds software as part of its core business, or not.
Choose one agile framework—and make sure it’s adopted by everyone in the organization.
To scale agile, you need to make its adoption and its use repeatable (able to be done continuously) and reproducible (able to spread from one part of the organization to another).
Agile is a mindset that powers an approach to making plans and getting things done in an empirical way. Anyone can take an agile approach to deliver customer value by working in short cycles, shipping in small chunks, and continuously learning. An adoption of agile is successful only when an organization becomes better and better over time in this new way of operating.
The mistake that most companies make when adopting agile is that they treat agility as an outcome instead of an approach. It’s not uncommon for executives to think, “We’ll train our people in Scrum, they’ll start using the framework to deliver—and we’ll have more or less completed our agile adoption roadmap.”
What they should be asking instead is, “How can we continuously improve the way we work?” The answers to this question should span across the organizational hierarchy, from the way that the company makes its strategic plans to how it sponsors a network of agile teams and empowers individuals to self-organize against a common vision, mission, and goals.
Start by choosing a single agile framework and scaling its adoption and use throughout the company. This will take much of the guesswork of adopting agile away from the individuals and agile in your organization, helping you to flatten the learning curve and reduce the margin of error. Sticking to one agile framework helps to make agile adoption reproducible, as good practices and know-how can easily spread from one part of the company to others.
Understand how different frameworks can help you scale agile differently.
Before we get to scaling agile, let’s spend a minute or two looking at the “mechanics” of an agile framework. Most agile frameworks consist of roles, events, and artifacts. Some are less prescriptive and intentionally leave room for interpretation, others are more explicit.
In the Scrum framework, for example, there’s the role of the Product Owner (PO). The PO is accountable for maximizing the value of the work being done. She participates in events, like the Sprint Planning, Review, and Retrospective, where she communicates and collaborates with the team and its stakeholders. She describes the value of the work that needs to be done in an artifact called the product backlog.
Another example of an agile framework is Extreme Programming (XP). XP is less explicit about the roles in an agile team and more explicit about the software development practices that an agile team can and—especially until they achieve a certain level of group cohesiveness and individual mastery—should do. The team captures requirements as user stories and estimates them for the release planning meeting. When a release plan is made, they start an iteration, in which all work goes through an automated set of acceptance tests.
The “mechanics” of Scrum and Extreme Programming (XP) are easy to understand on an individual team level. Fast-growing startups and big companies, however, struggle to apply them on an organizational level.
When a Scrum team has many leaders, managers, sponsors, stakeholders, customers, and users to tend to, and no rules exist to make that interaction repeatable and reproducible, it becomes challenging to impossible for them (and their stakeholders) to have productive interactions. Multiple that by the number of agile teams in an organization, and you have a problem.
How do you scale this agile way of work?
In general, most agile frameworks take two approaches to scaling agile.
The first approach is to take the same set of roles, events, and artifacts—and scale it across all levels of the organization; from interns in the open office to executives in the boardroom.
This is the approach that the Scrum at Scale (Scrum@Scale) framework takes.
Scrum@Scale was created by Jeff Sutherland and is right now being taught by his team at Scrum Inc. Sutherland is the co-creator of Scrum (along with Ken Schwaber) and one of the 17 signers of the Manifesto for Agile Software Development.
Scrum@Scale starts with individual Scrum Teams. They’re then grouped in a Scrum Team of Scrum Teams where only some members of each team participate, but the same roles, events, and artifacts apply. They just look at priorities and impediments on a higher level.
In large companies, the same principles apply. There’s a Scrum Team. The Scrum Teams are part of individual Scrum of Scrums (SoS) teams who work together to get things done. The SoS teams, each with not more than 5 teams inside, are then part of a Scrum of Scrum of Scrums (SoSoS) team, where work is planned on an even higher level:
To make the adoption of agile repeatable and reproducible within a large organization, Scrum@Scale scales the same concept to all of its levels. Every 24 hours, the organization is fully synced as each change that happens on the lowest level naturally feeds into the highest level, and vise-versa.
When talking about the Scrum@Scale framework in one of his lectures, Jeff Sutherland compared it to how fractals in mathematics work. A fractal is a self-similar subset of Euclidean space whose fractal dimension slightly exceeds its topological dimension. When visualized, fractals produce a pattern that seems to repeat itself endlessly, no matter how much the observer of the pattern zooms in or out of it.
The second approach to scaling agile is to give different roles, events, and artifacts to each level of the organization. Usually, this leads to each level working at a different pace.
This is the approach that the Scaled Agile Framework (SAFe) takes.
As any agile framework, SAFe starts with multiple agile teams. These teams use the Scrum framework and apply the best practices from the Extreme Programming (XP) methodology, working in short cycles (usually one to four weeks long) and delivering product increments in small chunks.
Above the Scrum Teams sits a trio of a Product Manager, a System Architect, and a Release Train Engineer (RTE), who plan the work in a 12-week Program Increment (PI) and help the Scrum Teams to establish a release rhythm called the Agile Release Train (ART).
The PI starts with a program backlog and the ART departs as the teams work iteratively and incrementally to deliver on the goals and priorities. The PI ends with a demo and a retrospective.
Above the Program Team sits a Solution Team that consists of a Solution Manager, Solution Architect, and Solution Train Engineer (STE). They coordinate delivery of value across multiple ARTs in what is called the Solution Train.
The Solution Train consists of internal teams, service suppliers, and technology vendors who work together to deliver large solutions, which the organization needs to enable its business goals and service its customer needs.
Above the Solution Team sits a Portfolio Team that works in a timeline of multiple quarters. The team consists of Epic Owner/s and Enterprise Architect/s who work side-by-side to translate the organization’s strategy into Strategic Themes and Value Streams.
A Value Stream contains the series of steps necessary to implement Solutions. Epic Owner/s and Enterprise Architect/s tend to report to the executives or senior management of the organization, usually the CEO/COO and CIO/CTO.
Compared to Scrum@Scale, the Scaled Agile Framework (SAFe) is more linear and with a longer feedback loop.
Fast-growing startups and companies that need to plan and act quickly will prefer Scrum@Scale because it allows them to shorten the feedback loop. The Scrum@Scale framework gives them “just enough structure” to operate with.
More established companies where agility is a must—but change and disruption are less frequent—will favor the SAFe approach to scaling agile. SAFe allows for openness, transparency, and adaptability while delivering value steadily and predictably.
You need an adoption roadmap and an inspection & adaptation cycle.
Earlier in this post, I mentioned that most companies make the mistake of treating their agile adoption as an outcome, and not necessarily as an approach. How can you fix that?
Start with an agile adoption roadmap. The roadmap should show when and how you plan to train executives, leaders, champions, coaches, and practitioners of agile and your framework of choice. The most successful agile adoptions start with a pilot in one or a couple of departments, where a select few agile teams implement agile.
The one part about agile adoption that companies often neglect is to create a feedback loop. This is best done by inspecting & adapting the organization’s agile journey in a cycle, i.e. every quarter, half year, or one year, with a preference for the shorter timescale.
Like the Sprint Retrospective of a Scrum Team, the best way to approach this is to create a cross-functional group of agile sponsors, champions, and coaches who can review where the organization is progressing and stalling on its agile journey—and identify actionable ways to foster progress and eliminate impediments.
The inspect & adapt cycle should carefully examine the frameworks, key performance indicators, and good/bad practices throughout the organization, with the goal of continually improving its agile ways of operating across all geographies and departments.
7 Steps to Scaling Agile Development Successfully
- Select a scaled agile framework based on the needs of your organization. Choose well, since everyone across the organizational hierarchy will use it.
- Without agile leadership, an agile transformation will fail. Start by training executives and senior managers in business agility and agile leadership.
- Build a small team of Agile Coaches and Agile Champions who will lead by example and help everyone else in the organization adopt an agile mindset.
- Rome wasn’t built in a day and neither can you scale agile at once. Pilot agile in a select number of teams and scale what worked to the rest of the organization.
- Remember that agile only scales when everyone thinks and acts in an agile way. A network of agile teams reporting to waterfall management will deliver subpar outcomes.
- Foster a culture of openness, transparency, and measurement. When everyone in the decision and implementation chain tracks metrics, informed improvements can be made.
- Inspect & adapt your organization’s adoption of agile frequently. Agile is not an end state, it’s a way of work. The goal of agility is to become continuously better.
The Bottom Line
Agile development can be scaled. A number of agile frameworks, some of which created by the founders of the agile movement, exist today that can help organizations scale agility beyond the single team and on the level of the enterprise.
There’s no one-size-fits-all approach to scaling agile and every scaled agile framework has its ups and downs. The right thing to do is to choose a framework that suits the needs and circumstances of your organization, then scale it across the organizational hierarchy.
This is where most companies stumble and experience difficulties on their agile journeys. Don’t make the same mistake as them: pick an agile framework and implement it, in a way that flattens the learning curve for your employees and maximizes the benefits of agility.
Whichever framework you choose, remember to act as agile about its adoption as you’re asking your teams to be in its use. Implement feedback loops with inspect & adapt events where a cross-functional team exchanges know-how and lessons learned from across the organization—and in a way that helps everyone working in it to course-correct on their journey to agile.