You’ve set your first steps in agile development. Maybe you’ve run a pilot with a single team and want to leverage the benefits to more teams.
Maybe you already have several teams working according to agile principles and you’ve run into some barriers that are holding you back from getting all the benefits.
Or maybe you’ve been working in an agile manner with your team(s) for several years and now want to adopt agile practices across your entire enterprise.
Whatever your situation, you’ve heard about Scaled Agile Frameworks and wonder whether it’s worth investing in one of them to get you to the next level.
But which one?
That’s where this article comes in.
It gives you a brief introduction to scaling agile and the major scaling approaches so you can focus your attention on the one that looks like the best fit.
Let’s start with what scaling agile means.
What Does Adopting Agile at Scale Mean?
The idea of scaling agile is to enable you to adapt and stay competitive by responding quickly and adequately to customers’ needs and adding delightful touches to keep customers coming back for more.
Ultimately, and in practical terms, it means spreading agile working to every team at every level and in every department — including top management, and reducing coordination and control to a minimum.
The main tools for this are autonomous teams, alignment on values and goals, and accountability and transparency at every level — both up and down what remains of an original hierarchical structure.
Obviously, you’ll be dealing with different issues spreading agile to one or more teams within the same department, than when making the jump to departments beyond software engineering or IT (where agile originated).
The variety in scaled agile frameworks, the structure and practices they advocate, and what specific issues they address, varies.
Which one will suit you most depends on what stage you’re in on your agile journey and how well what a framework is designed to accomplish fits your aspirations for scaling agile and eventually becoming an agile business.
Now, this is important, there’s a lot more to do than adopt a framework.
What Are the Real Challenges in Scaling Agile?
A framework helps you avoid reinventing the wheel with regard to the structure, processes and the principles to follow for you to become agile.
But the real challenges in an agile transition are at a completely different level.
They have to do with the mindset and the culture you need to become truly agile: letting go off (much of your) control and trusting that everyone wants to perform at their best.
That means:
- decentralizing decisions.
- creating transparency and alignment around strategic goals and how you organize work.
- finding a balance between autonomous teams and cross-team dependencies.
- changing virtually everything in the way you organize work.
- delivering sooner and perfecting products “in the wild.”
- collaborating throughout your business and with your customers.
- updating, replacing, and integrating your information systems to enable transparent information flow throughout your company.
That probably sounds daunting and I’m not going to diminish the task at hand.
I will say, however, that it’s entirely possible!
With training, practice, a willingness to fail forward (focusing on learning from outcomes you don’t prefer), and a bit of patience, you can make it work and enjoy the joy of a people- and customer-oriented agile enterprise and the competitive advantage that comes with it.
So, let’s get you clear on the most important characteristics of SIX frameworks for scaling your agile adoption.
1. Scaled Agile Framework (SAFe)
SAFe® combines Lean, Agile, and DevOps practices for business agility.
It provides guidance on three levels for product delivery in a scaled agile environment and adds guidance on extending agile across your enterprise with its fourth, portfolio level.
The last SAFe version extended that top level with a lot from Lean Portfolio Management.
Many agile practitioners consider SAFe overly prescriptive and complex.
It does indeed prescribe many roles, events, and practices. They add quite some complexity and require significant investment and commitment to adopt. And they do detract from the flexibility that agile holds dear.
However, for very large enterprises this can be a blessing in disguise.
SAFe’s prescriptive nature provides concrete guidance without forcing you to immediately overhaul your enterprise’s organizational structure or your product’s architecture to help minimize team dependencies.
One of the tools it uses for this is its quarterly planning event: the Program Increment Planning (PI planning).
It’s a top-down collaborative event and planning cycle on top of and overarching the standard Scrum Sprint cycle or cadence in Kanban.
PI planning allows you to align everyone (at your level of adoption) on the strategic goals for the coming three months. It helps surface the dependencies between teams and departments involved, and come up with a prioritization that allows you to move efficiently towards the PI goal.
The table below shows how the four levels of Scaled Agile Framework relate to its four adoption configurations.
Some notes on the SAFe levels:
- At the team level, SAFe is essentially Scrum plus several XP (eXtreme Programming) practices. Teams can opt to use some Kanban practices to manage their workflow, see below.
- The program level coordinates team efforts with quarterly Program Increment Planning (PI Planning) and a team of teams called the Agile Release Train (ART), Release Train Engineer, as a servant leader and coach who facilitates the ART events.
- If you have a large product that more than 150 people work on, SAFe adds a solution train to coordinate the various ARTs and a Solution Train Engineer whose role is similar to the RTE’s but at a more integrated level.
- The portfolio level manages development streams and coordinates with the other levels to ensure that agile release trains and solution trains align with strategic goals.
SAFe and Kanban
Within SAFe, teams can choose to follow Scrum or Kanban. That said, like most other frameworks, the team Kanban described by SAFe only talks about the practices of visualizing work, limiting work in progress, and managing flow. And it puts restrictions on them because “these teams are on the train, and some additional rules must ap.”
More importantly, SAFe puts restrictions on Kanban teams because “these teams are on the train, and some additional rules must apply.” — quote from the Team Kanban article.
The rules are that teams plan together, demo together, and learn together.
In other words, they have to participate in other teams’ Scrum events — not necessarily a bad thing.
But there’s more. From the same article:
“Kanban teams don’t invest as much time in estimating as ScrumXP teams do. Instead, they take a look at the work needed, split the bigger items where necessary, and pull the resulting stories through the Kanban system to completion, mostly without much concern for their size. However, during PI Planning, SAFe teams must be able to estimate the demand for work against their capacity, and also help contribute to estimates for larger cross-team backlog items (Features). Moreover, forecasting requires an understanding of the team’s velocity in a manner that’s consistent with the other teams on the train and the overall ART velocity.”
In other words, SAFe expects Kanban teams to do a lot more planning and estimating — including for others!
While understandable from an overall planning perspective, this goes almost entirely against what Kanban is about, and reduces the flexibility and agility that is inherent in Kanban.
2. Scrum@Scale (SaS)
Published in 2017, Scrum@Scale is the new kid on the block in agile scaling frameworks and guides you in scaling agile for product delivery.
Img Src: ScrumAtScale
It seeks to do at scale what Scrum does for a single team: keep the what (product) and the how (process) separate. To that end, it defines two distinct but overlapping cycles: the Scrum Master Cycle for product delivery and the Product Owner Cycle for product discovery and definition aligned with your company’s strategic vision and goals.
Each cycle has a leadership group to support effective operation: an Executive MetaScrum (EMS) fulfilling the product owner role at the organization level and an Executive Action Team focused on organization-wide process improvements in the scrum master cycle.
Two new roles facilitate the scaled versions of the Scrum events: the Scrum of Scrums Master and the Chief Product Owner.
SaS defines components with a specific purpose in both the product owner and scrum master cycles. They allow you to customize your transformation with tactics beyond the core design and ideas of each.
Note on Scrum of Scrums vs Scrum@Scale
Scrum of Scrums (SoS) and Scrum@Scale (SaS) are often confused.
Scrum of Scrums is a technique for cross-team coordination. It doesn’t deal with scaling agile for product delivery or the enterprise.
It’s still worth discussing it briefly because it’s widely adopted, it’s an explicit part of Scrum@Scale, and many other frameworks use the basic idea to structure coordination across multiple teams.
Scrum of Scrums (SoS)
Scrum of Scrums introduces a team of teams with its own backlog for everything needed to coordinate the teams’ work and resolve impediments that a single team can’t tackle on their own.
In SoS, team representatives meet in a daily scrum of scrums to discuss completed work and the next steps needed to tackle dependencies.
SoS works for at most 3 to 9 teams of 3 to 9 members each. For larger organizations, a frequently seen adaptation is a Scrum of Scrum of Scrums.
3. Large Scale Scrum (LeSS)
LeSS is a framework for scaling agile product delivery. The idea driving everything in Large Scale Scrum is to (let you)
- do more with less.
- avoid overhead and avoid local optimizations
- adopt a whole product focus by organizing your teams around the diverse ways your product brings value to your customers. For example, a team focusing on voice features and another on texting.
Img Src: less.works
Like other Scrum-based frameworks, LeSS is single-team Scrum with a few adaptations.
It truly keeps these to a minimum. It only adds an overall retrospective and a preliminary part to the sprint planning, and replaces the per-team sprint reviews with an all-teams one.
For all other coordination, LeSS suggests: “Just Talk, Communicate in Code, Travelers, Open Space, and Communities.”
In other words: talk as needed and only about what matters at the time (Open Space) and otherwise promote cross-team interactions through sitting with another team (Travelers) and forming communities around shared interests.
It’s an example of how LeSS is one of the least prescriptive frameworks around.
The fact that the LeSS rules fit on just two sides of a single sheet of paper, is another.
It’s able to be so concise because of its 10 underpinning principles that permeate the framework and the three principles of its guidance on adoption. So, when in doubt, follow the principles’ guidance.
For organizations with more than eight teams, there’s LeSS Huge.
LeSS Huge divides the product into requirement areas and adds just a single role.
That’s the Overall Product Owner. This role is responsible for product-wide prioritization and deciding which teams work in which requirement area.
All areas follow the same sprint and produce a single integrated product increment.
4. Nexus
Nexus is a framework for scaled agile product delivery.
Img Src: scrum.org
It strives to reduce complexity and cross-team dependencies with opportunities to change the process, product structure, and communication structure.
The Nexus framework defines a Nexus as a group of 3 to 9 scrum teams with a single product owner and a single product backlog, similar to Scrum@Scale.
It introduces a Nexus Integration Team and Cross-Team Refinement to coordinate the work and the dependencies between teams.
The Nexus Integration Team deals with integration issues that would prevent the Nexus from delivering an integrated product increment. It consists of the product owner, plus a scrum master and members from the development teams.
Cross-Team Refinement is an ongoing activity to identify cross-team dependencies and surface early which team will likely work on an item. Who attends can vary with the items up for refinement.
Other adaptations to single-team Scrum events, are:
- Nexus Sprint Planning to coordinate the work of all teams in the Nexus.
- Nexus Daily Scrum in addition to each team’s daily scrum to keep tabs on (newly discovered) dependencies and integration issues.
- Nexus Sprint Review that replaces the individual team’s sprint reviews.
- Nexus Sprint Retrospective to review how the teams and their shared processes and tools functioned. It closes the sprint, so it follows the individual teams’ retrospectives.
5. Disciplined Agile (DA)
Disciplined Agile started as Disciplined Agile Delivery (DAD), with a focus on product delivery.
Img Src: pmi.org
It evolved from there and was renamed Disciplined Agile to reflect its widening scope. As of 2017, DA shows how business functions work together and what they should address for agile at scale in what it calls a Disciplined Agile Enterprise.
DA is lightweight. It shines a light on the “what” and the tools you need to make it happen, but it leaves the “how” up to you.
Disciplined Agile gives guidance on four levels:
- Foundation gives you the principles, promises, and guidelines of the “DA mindset”, lean and agile principles, more traditional approaches, roles and team structures you can adopt, and what you need to choose your way of working (WoW).
- Disciplined DevOps extends standard DevOps — streamlining development and operations — by integrating security and data management.
- Value Streams help you tie your strategies together and improve each part of your business in the context of the whole.
- Disciplined Agile Enterprise helps you create a culture and structure conducive to change, learning, and innovation.
The DA toolkit is so extensive it’s like a superset of all the tools used in other approaches. Lean, Scrum, Kanban, and all the techniques and methods that come with them. Still, it’s lightweight because it doesn’t force you in any particular direction, you can mix and match and build your own framework without having to start from scratch.
6. Enterprise Kanban, aka Portfolio Kanban
Hearing “Kanban,” most people think of boards with columns filled with stickies.
Img Src: kanban.university
But the Kanban method is much more than the three practices of visualizing work, limiting work in progress, and managing flow that are often used within other agile frameworks.
The Kanban method is a way of life, sorry, working.
It’s one of the 13 pillars of the Toyota Production System that turned Toyota from a small Japanese carmaker into a world-dominating manufacturer of cars with unparalleled reliability.
Kanban isn’t concerned with how you structure your organization.
Its four principles and six practices guide you in optimizing workflow, focusing on customer needs and expectations, encouraging leadership at every level, and continually learning and improving.
Sounds agile? Yes, Kanban made Toyota agile long before the Agile Manifesto was written.
The beauty is that you can apply Kanban to any workflow or value stream, at any level in an organization or work process. And that makes Kanban inherently scalable.
Enterprise Kanban or Portfolio Kanban comes about by:
- spreading Kanban’s principles and practices and coaching everyone on them
- grouping and linking work to reflect your strategic goals and the portfolio and programs and visualize dependencies between them.
Note on Spotify
Img Src:crisp.se
I didn’t include Spotify as a scaled agile framework for several reasons.
- The white paper that describes the “Spotify model” was the first in a series, but the others never got published. In other words, it wasn’t complete!
- “Spotify’s model” wasn’t a model, it was an aspiration. They quickly experienced problems with it even though at the time they weren’t all that big yet.
- The “Spotify model” uses fancy names for an ordinary matrix structure though it does differ from “traditional” matrix structure in that it doesn’t assign people to projects, but assigns them to stable teams focused on the delivery of their bit of the product.
- The “Spotify model” focuses on autonomy and doesn’t speak about alignment and accountability.
Source: Spotify’s Failed #SquadGoals, the references and resources lists in this source contains links to the original whitepaper and two videos explaining Spotify’s aspiration for its culture.
Picking the Right One for You
That’s it. Six scaled agile frameworks. Or more precisely, four frameworks, one toolkit, and one way of working.
Which one will it be?
A few general pointers to pick the best candidates for you:
- Don’t get too hung up on picking the perfect match. Apart from the distinct differences between Scrum and Kanban, most frameworks aim for the same thing and differ mostly in what aspects of agility at scale they pay most attention to.
- If you’re already using Scrum and are happy with it, the obvious way forward is to shortlist the Scrum-based frameworks.
- If you want as little as possible overhead, LeSS and Enterprise Kanban come to mind.
- If you want to broaden your agile journey from product delivery to the entire enterprise, then SAFe and Disciplined Agile are the natural options.
- If you appreciate picking the best approaches and tools for each aspect, Disciplined Agile may be your winner.
Go Forth and Pick What Suits You
Yes, scaling agile can be an intimidating prospect, but each of these Scaled Agile Frameworks and approaches is designed to help you on your journey.
If none of the frameworks and approaches mentioned here appeal to you, other frameworks and approaches abound, and about 1 in 6 companies roll their own.
So, go on, create that shortlist, and start your selection, or go for tailormade.
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
