The Scaled Agile Framework, or SAFe, promises to do for large teams what the original agile methods could not: bring improved results to software groups with hundreds, even thousands, of people. That includes better organization, coordination, consistency, governance, and selection of priorities and progress made visible.
Perhaps the most on-point argument against SAFe has to do with the nature of agile: If SAFe is a collection of processes and tools designed to be adopted—that is, switched to with immediate cutover—then that suggests a one-size-fits-all solution. And that’s a far cry from the incremental, respond-to-change, focus-on-individuals approach espoused in the Agile Manifesto.
To understand these concerns, I went to the source and interviewed Jennifer Fawcett, SAFe fellow and director of service delivery for Scaled Agile, Inc. I also spoke to three other practitioners, asking them the questions that came from the critics and giving them a chance to answer.
Here's their expert advice on how to tailor SAFe to the specific environments and cultures where it might be best applied.
SAFe, by the book
Fawcett points out that it is unlikely any two SAFe adaptations will match. In her simplest example, Fawcett suggests a medium-sized software subcontractor aligned with a single customer. The portfolio management and priority pieces of SAFe are already handled well, because the contractor knows what her team is working on now and what they will be working on next. That means that two levels of SAFE 4.0— the value stream and portfolio levels—do not apply.
On the other hand, a large aerospace firm developing embedded systems to run on physical hardware might want everything the SAFe framework has to offer.
Picking and choosing what parts do and do not apply to any given need is, of course, the hard part. To make things easier, Scaled Agile has created Essential SAFe, which consists of ten practices:
- SAFe lean-agile principles
- Agile teams and release trains
- Cadence and synchronization
- Essential team and program roles
- Program increment (PI) planning
- System demo
- Inspect and adapt
- IP iteration
- Architectural runway
- Lean-agile leadership
These principles in SAFe are similar to the mutually supportive principles in Extreme Programming: Without test-driven development, for example, it is not possible to refactor, and without refactoring, incremental development becomes slow and painful. In SAFe, an understanding of the ten principles allows the team to evaluate where they are now and what to add next. For another example, without agile team and release trains, the teams won’t work toward a common mission and will become bogged down by dependencies, and the over-specialization will create bottlenecks that inhibit flow.
In other words, the ten practices above are the bare minimum to implement SAFe at the release train, or “team of teams” level, which is considered the right level for a team of 60 to 150 people.
Beyond the SAFe essentials
Scaled Agile also offers guidance to organizations that need a little more than essential SAFe. If the company consists of product groups that are each under 150 people, then scaled agile suggests the three-level model—teams, program (each program has one release train), and a portfolio group to manage the investments.
Larger businesses that have product groups with multiple release trains will need the value stream level, and the largest may have multiple portfolios. For example, a large retailer might put the website, store operations, and store credit card in entirely different groups, each managed separately.
That leaves us with the ability to tailor SAFe adoption by company and team size. But it still leaves questions about other aspects having to do with context. For example: Should a video game company develop and deploy software the same as a company making embedded software for automobiles? Or a bank?
What about a company that is already high performing in DevOps or in modern software development practices such as continuous delivery versus a company that still primarily uses waterfall practices? And what about companies experiencing massive changes in their industry compared to companies in industries that are more stable?
For more advice on context, I turned to three experts in SAFe: Em Campbell-Pretty, based in Melbourne, Australia; Martin Burns, who operates out of Edinburgh, Scotland; and Eric Willeke, currently in the United States. Please read on.
The expert opinion
Eric Willeke is an advisor of enterprise agility at Rally Software, now a division of CA Techonologies. He challenged the idea that SAFe needs to be “big bang, convert all at once.” Instead, he believes, SAFe must be rolled out one release train at a time, working within the team-of-teams unit, about 60 to 150 people. For an organization with more than 1,000 software developers, that is 6 to 15 percent at a time.
After each program increment of 8 to 12 weeks, the release train performs an inspect-and-adapt exercise to decide what to change. The outcomes of that exercise can be added to the backlog for the next increment, leading to incremental improvement.
Which leads to Willeke’s next point, about how to fund those improvement ideas. Often, those are technical improvements, to build systems, test tooling, and so on. If the agile product owners are in the business of shipping features, those can be easily forgotten. SAFe provides the idea of capacity allocation, a practice for reserving a percentage of work for technical features in every program increment and sprint.
But what if you have a healthy, sane organization?
SAFe's capacity allocation practice solves the problems between “the business” and “the technical people” when they are unable to agree on priorities. But what if they actually collaborate well? What if the organization has a healthy, balanced attitude toward long-term performance and leadership, and a collaborative culture that works effectively to decide what should fit in the next program increment? Wouldn’t that be better than working in silos, with 85 percent of new work being new features and 15 percent technical work (or some other pair of numbers)?
The answer is yes. Which is why Willeke (and SAI, Inc., the parent company of the method) views SAFe's capacity allocation piece as optional.
Em Campbell-Pretty is a partner at Context Matters. She's a SAFe trainer and the author of “Tribal Unity: Getting From Teams to Tribes by creating a One Team Culture.” She points to how things actually get done in larger organizations, and the answer is networks. One company she worked with had over 100 people in a “product team,” yet outside of a few work mates, no one knew one another’s name. PI planning, the two-day kick-off event between major sprints, puts the entire team of teams in one room for two days. Over time, PI planning creates these networks. If relationships are a problem, Campbell-Pretty suggested other, similar events, held more often, such as Unity Day.
Tailoring the optional SAFe pieces
Willeke suggests the best way to tailor SAFe is to go back to the principles of quality, transparency, alignment, and program execution. He points out that the first three are similar to Scrum, but program execution makes a tradeoff, favoring the velocity of the program over that of any one team. After the principles, Willeke points to SAFe's Lean-agile mindset, which includes respect for people, flow, innovation, and continuous improvement.
Those might seem like buzzwords, but they can help with not only what to do, but in what order. Many teams Willeke has worked with wanted to “get things right” before they implemented the big picture at once—a symptom of the waterfall thinking they were trying to walk out of.
Continuous integration
If a group believes it needs continuous integration (CI) setup before it can start with SAFe, it may be correct. SAFe values innovation and continuous improvement and includes reflection and adaptation. If the team doesn’t have CI in place, there will be a lot of pain.
The need for more frequent integration will emerge as a high priority from the inspect-and-adapt outcome from the first program increment—and get done for one of two reasons: because capacity allocation guarantees that the technical backlog gets done, or because the team can collaborate and doesn’t need capacity allocation.
Transparency and communication
Martin Burns, a transformation consultant at Rally, pointed to a time when he was working with LEGO on a SAFe adoption. As part of PI planning, each team does a show and tell regarding what they will be working on during the next PI. For a team-of-teams working on one product, having face-to-face time can be critical in improving communication, knowing whom to contact when dependencies emerge, and overall coordination.
At LEGO, however, while the teams were working on related problems, they were less intertwined. Instead of taking time for ten or more teams to present, one at a time, the group was arranged like a science fair. Each team left someone behind in the big room to explain what they were working on, while the other team members went to find groups that were interesting or relevant. Time spent on “pitching and listening” went down, while actual learning per minute and collaboration went up.
As critical as we tend to be of by-the-book concepts, Burns has a warning for us: The book is there for a reason. The implementation road map includes training at specific levels and times. So far, he has worked with two organizations that wanted to rush adoption, skip training, and customize heavily, based on what they read on the website. They have struggled. “You say you’re doing SAFe, and you are not,” Burns says. “Let’s pull things more toward the book.”
“By the book” means to Burns that the SAFe implementation road map, shown below, which insists on training leaders in a specific order before rushing to implementation. Even in implementation, the road map leaves time for the teams to figure out how they will implement SAFe within guidelines, instead of trying a cookie-cutter or wildly compromised approach.
The SAFE 4.0 implementation road map.
Tailoring SAFe, in the final analysis
Campbell-Pretty sums it up best: “Release trains solve the problem of team-of-team communication, coordination, predictability, and velocity. Everything else solves other specific problems and is optional. So the next two steps are to figure out what problem you have, and to figure out what pieces of SAFe could be combined to help solve them.”
Diagrams: Scaled Agile, Inc. All rights reserved. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
