Three reasons why Equal Experts doesn’t recommend the SAFe framework

Scaled Agile Framework (SAFe®) is an enterprise agile framework. Our advice is ‘don’t do SAFe’, and it’s based on customer and consultant feedback in the Equal Experts network. I’m a certified SAFe 6.0 Agilist, and my colleague Steve Smith and I would like to explain why SAFe usually fails to deliver business agility.

At Equal Experts, we’ve helped enterprise organizations with 10 to 100 teams in achieving business agility. Our Scale service is based on the knowledge of our customers and consultants, and that includes in-depth experiences with SAFe. It’s an enterprise agile framework incorporating industry practices like OKRs and Continuous Delivery, and proprietary practices like PI planning and release trains.

We empathize with senior technology leaders when they ask us about SAFe. They’re often under pressure to closely manage stakeholders and teams to deliver results, like the digital director who told us “I want to get the business in a room, and force them to tell me what they want.” And as a delivery framework, SAFe is well marketed, well documented, and well known in the IT industry.

But if you’re playing on an American football team, you should warn your coach if the playbook isn’t going to work. Equal Experts’ advice is ‘don’t do SAFe’, because so many of our customers and consultants have had negative experiences. From their feedback, we believe SAFe has serious limitations:

• SAFe doesn’t accelerate delivery speed
• SAFe doesn’t satisfy product demand
• SAFe doesn’t create adaptive architectures

And we always do what’s best for our customers! If you implement SAFe, we’ll leverage our expertise to ensure the best outcomes. Positive experiences do exist, like Rupert Woolmer-Tyler at a financial services company: “SAFe was used to move from 5 year plans to quarterly planning. It forced teams to collaborate, and try new ways of working. We ended up in a better place.”

SAFe doesn’t accelerate delivery speed

Increasing delivery speed requires aligned, autonomous teams:

• Alignment is a shared understanding of business goals. It steers team decisions towards a single direction, which reduces unplanned work and delivery speed
• Autonomy is the capability and confidence to act. It drives intrinsic motivation and problem solving within teams, which increases team productivity and speed

SAFe achieves alignment through PI planning – a two day, quarterly session where teams and stakeholders set business goals, integrate dependent backlogs into release trains, and vote on deliverables. This results in a programme board with product objectives and delivery dates. This does produce alignment, and it can be reassuring to see teams committed to a single plan.

However, this approach massively slows teams down. In why you need alignment with autonomy at scale, we showed organizations need contextual alignment and autonomy to succeed. SAFe doesn’t do this. It couples teams together and tells them to build solutions, which drags down productivity and speed. It’s an autocracy, full of top-down approvals and cross-team handoffs. You need to lead with context, but SAFe leads with command and control.

I (Louise) once worked as a delivery manager at a retailer using SAFe. Teams were forced into certain ways of working, couldn’t make decisions, and work was assigned without considering tech skills or system knowledge. These all affected morale and speed. Other negative experiences in the Equal Experts network include:

• A CTO in finance: “SAFe is a gigantic, chaotic, three-legged race you want to avoid.”
• Liis Laulik was a delivery lead at a bank: “There was no innovation because teams were just given solutions to build. There was no autonomy with so many dependencies. PI planning would overrun beyond two days, and people didn’t have the psych safety to vote down deliverables.”

There’s plenty of industry critiques of SAFe. Steve Denning said in Forbes, “It subordinates the agile teams to the bureaucracy, rather than doing what is necessary to achieve business agility.”

SAFe doesn’t satisfy product demand

Product demand can be satisfied by embedding continuous learning and experimentation into teams. Constantly assessing market conditions and user needs fosters a strong yet flexible product vision, providing clear direction while allowing for course corrections. This enables a gradual refinement and reprioritization of the product roadmap, to maximize business value and streamline feedback loops.

SAFe centers product management on value stream coordination. Every quarter, PI planning brings together the teams and stakeholders in a value stream. Product managers align on outcomes with business owners and customers, prioritize the release train backlog, and communicate agreed solutions to their teams. This does encourage teams to build relationships, and think holistically about product delivery.

In Escaping the Build Trap, Melissa Perri warns against focussing on static stakeholder requirements rather than dynamic user value, and SAFe plunges into that build trap. It emphasizes outputs instead of outcomes, and assumes three months of unchanging market conditions and user needs. It leaves teams working on yesterday’s features instead of today’s objectives, which results in painful prioritization conflicts, unplanned work, and less time for actual product development. You need to be product-centric, but SAFe is project-centric.

At the retailer, I saw product managers with teams during PI planning, but there wasn’t much experimentation during a release train. We had to make extra efforts to keep teams aligned on business goals, and they didn’t know if they were making a difference. Other Equal Experts experiences include:

• Marcel Britsch was a product manager at a finance company: “SAFe didn’t create a product-led culture, control scope, or manage overheads. We had 20 people working full-time on PI planning.”
• Werner Smit was a delivery lead at a logistics company: “Business people continually changed direction outside the release train, so we had outdated plans with no scope control. And SAFe was only in the digital division, so commitments dependent on heritage systems weren’t on time.”

Industry product experts have been extremely critical of SAFe. Marty Cagan said in SVPG, “I don’t know a single strong product company using SAFe”, while Jeff Gothelf said “all the principles we’ve built into Lean UX don’t seem to exist in SAFe”.

SAFe doesn’t create adaptive architectures

Engineering excellence relies on teams building and running adaptable software services. The Accelerate book by Dr. Nicole Forsgren et al highlighted software architecture as a key predictor of delivery outcomes. Teams designing domain-driven, well-architected services can independently build and deploy their changes, accelerating development cycles and ensuring teams can react to changing circumstances.

In large enterprise organizations, there’s often badly defined business domains split across multiple services, which produces a lot of dependencies. SAFe addresses this through the programme board during PI planning. Teams identify features that can’t be delivered in isolation, and dependencies are marked on the board. Managing visible dependencies does facilitate more collaboration between teams.

Unfortunately, SAFe only has band-aids for tough engineering challenges. Guardrails like value stream reconfiguration defer problems without solving them. Brittle failure modes and time-consuming team handoffs create unplanned work, and steer teams away from engineering excellence. There needs to be an investment in re-architecting services, and activities like rescoping business contexts and reducing temporal decoupling are beyond SAFe. You need to escape dependency hell, but SAFe only endures it.

At the retailer, I saw plenty of engineering challenges. Our dependency problems were visible, but they were tolerated because SAFe made the status quo seem comfortable. Other experiences include:

• Olly Shaw was a technical architect at a media company: “Multiple teams worked daily on three large Java monoliths. Adopting SAFe was supposed to improve the flow of work, but there was no change. Features still trickled out because they touched all the monoliths.”
• Beth Piner-Francis was a delivery lead at a bank: “Release trains were functional areas, not value streams, so with no end-to-end ownership of user journeys we had a lot of dependency problems.”

Conclusion

We understand why senior technology leaders ask us about SAFe. Its structured approach to large-scale planning, product management, and engineering looks compelling, and it lacks clear commercial alternatives. But the range of negative feedback from Equal Experts customers and consultants means our advice is ‘don’t do SAFe’. It’ll help with parts of your journey, but you won’t reach your destination.

We recommend forming your own contextual structures around similar practices. An engineering director described this as “don’t bother with SAFe, adopt big room planning and modern engineering, and talk to your customers”. Although this approach appears slower and more costly than SAFe, it’ll yield better long-term results. That’s why it’s part of our Scale service.

And we’re pragmatists, not purists. If you implement SAFe in your business, we’ll use our expertise to work within its boundaries, as my team did at the above retailer. We delivered urgent needs on time, with a high degree of customer satisfaction and team net promoter score improving from -33 to +75. We built strong stakeholder relationships, adopted You Build It You Run It to increase team autonomy, and used a steel thread to deliver business value three times a week.

Thanks to Ambika Ashok, Beth Piner-Francis, Brian Mason, Jon Fulton, Katie Coleman, Liis Laulik, Marcel Britsch, Michael Pajak, Olly Shaw, Rupert Woolmer-Tyler, Sarah Godsell, Sally Whittle, Werner Smit, and the many other customers and consultants worldwide who shared their lived SAFe experiences with us.