Author: Jurgen Appelo

Introduction

“What is the difference between SAFe and unFIX?” - (many people)

Well…

Scaled Agile introduced the Scaled Agile Framework (SAFe) in 2011. In those ten years, the framework had five major releases. SAFe has its focus on medium to large software-driven enterprises.

I first introduced a preliminary version of the unFIX model in September 2021. The first significant release happened in January 2022. The audience for unFIX is small to medium-sized businesses, not limited to software.

Needless to say, SAFe is much older and more extensive than unFIX. SAFe has accumulated more than ten years of (good and bad) experience, while unFIX still needs to prove itself as a valuable model for organization design. But it's worth noting that 70 percent of people in the world work for small to medium-sized companies. Large enterprises span only a fraction of all markets! And besides, not everyone builds software. What can you do with SAFe when you bake cakes or make furniture?

I created unFIX because, for most people in the world, SAFe is either oversized or irrelevant.

However, it is still worth investigating how SAFe compares to unFIX. The question keeps coming up so let's tackle it. Let's unfix SAFe!

Note: This article is based on Essential SAFe Essential. Let’s leave the larger configurations of SAFe for another day.

Agile Release Train (ART)

The Agile Release Train (ART) is called "the heart of SAFe" and SAFe refers to it as a long-lived "team of Agile teams". Agile Release Trains are groups of typically 50 to 125 people who are dedicated full time to the ART and aligned to a shared mission.

Conceptually, an ART in SAFe is the same as a Base in unFIX. It even includes the same reference to Team Topologies with several team types to choose from. (With unFIX, I have extended the four standard types to seven Crew types.)

The crucial difference between an ART and a Base is that SAFe assumes that everyone on the ART is working on the same solution. In unFIX terms, an ART is always a Fully Integrated Base. You could say that the defining purpose of SAFe is to explain how to work with multiple software teams who all contribute to one solution.

But most small to medium-sized companies don't work that way. In many organizations, teams are not fully integrated but only strongly aligned, loosely aligned, or even fully segregated. That's why I describe four Base types with unFIX, and I allow for a Base to occasionally change strategy from one Base type to another. The unFIX model keeps the Base type unfixed! When there's no reason to integrate all teams, it's better to keep them autonomous.

Agile Teams

Agile Teams in SAFe are fully cross-functional. They include all necessary people to produce a working, tested increment of the solution. These teams can apply ScrumXP, Team Kanban, or other agile methods (or derivatives) to organize their work.

In unFIX, the equivalent is the Crew (usually the Value Stream Crew), although a minor difference is that I suggest an optimum team size of 3 to 7 people, while SAFe sets this at 5 to 11 individuals. Even at the team level, SAFe aims for bigger. 😉 I want unFIX to be future-proof, and in remote and hybrid settings, there is an increased need to keep teams small. Three to seven Crew members is a good range.

Somewhat confusingly, SAFe distinguishes technical teams (for the solution) and business teams (for their support), and SAFe also embraces the four team types of Team Topologies. In unFIX, there are seven Crew types, four of which correspond directly with Team Topologies; the other three are special cases. There seems no need for a distinction between technical and business teams. Drawing such a boundary is too complicated and adds little value.

Product Owner (PO)

In SAFe, each Agile team has one Product Owner (PO)—typically full-time per team—who manages the team backlog, maximizes the value produced by the team and maintains the integrity of the team's work. This Product Owner serves as a proxy when working with Product Management and other stakeholders in the ART.

In unFIX terms, the Product Owner would probably be the Value Stream Crew's Captain. The Captain is defined as a Crew's proxy to the outside world and a tie-breaker for difficult decisions. However, in the unFIX model, the Captain role is context-dependent. For example, one person could be Captain for product meetings, and another Crew member could be Captain in technical discussions. This setup makes the role more flexible—less fixed!—as the best person to act as a proxy could depend on circumstances.

Product Management (PM)

In SAFe, Product Management is responsible for defining products that meet customer needs. The PM sits between the customer and the Product Owners of the various Agile teams in the ART. This means that Product Owners don’t own an entire Product Backlog but only their own Team Backlog, which is then filled from the Program Backlog by the Product Manager.

Placing Product Managers between customers and POs is considered an anti-pattern among many agilists as this increases the number of hand-offs. Some of the strongest concerns about SAFe are about the issue of Agile Teams and their POs being reduced to simple executors of program priorities and then losing sight of their actual customers.

The role of the Product Owner is reduced to writing stories and checking acceptance criteria instead of being the single point of accountability for product leadership that was the original intention for the role. - Sean Dexter, “Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness”

At its most fundamental, the critical notion of a dedicated product team (aka squad) has been gutted. In SAFe, this concept of a true product team has been undermined and demoted, and the core concept is now a Program, which has a top-down model of a product manager, an architect, and a release train manager, and these people make all the key decisions, and then some number of engineering teams with a low-level product owner are assigned various parts to build. - Marty Cagan, “Revenge of the PMO”

My proposal does not have the infamous PM-PO problem. The unFIX model does not recognize separate roles for individual managers outside the Crews. The Captains sit only in Crews, not outside of them, and either they talk directly with customers themselves or agree that another Crew member acts as the customer proxy.

In Fully Integrated and Strongly Aligned Bases, coordination and integration of work between Crews should be managed by an Experience Crew. These teams consist of representatives from the various Crews who oversee the entire Product Backlog together. A Captain can be appointed (or elected) as the leader of such a Crew and as the “first among equals”, an honorable position indeed. The Product Manager in SAFe would then be comparable to the Captain of the Experience Crew. Still, their power would be reduced (depending on the delegation level applied by the Chiefs), and the POs retain their direct communication link with their customer (s) in their own Crews.

With seven delegation levels, seven crew types, and four base types, unFIX offers many more options for implementing Product Management across multiple crews. The model keeps Product Management unfixed!

Scrum Master (SM) and Release Train Engineer (RTE)

The aforementioned issue in SAFe around Product Owners vs. Product Managers repeats itself when discussing Scrum Masters vs. Release Train Engineers.

Scrum Masters are servant leaders and coaches for Agile teams. They help educate them on agile practices, ensure that the agreed-upon processes are followed, and help remove impediments for high-performance and continuous flow. It is typically a part-time job per team.

The Release Train Engineer (RTE) is also described as a servant leader and acts as a coach for the entire Agile Release Train. The RTE’s responsibilities are facilitating ART events, assisting teams in delivering value, and driving relentless improvement.

Having the RTE as a dedicated role outside the teams is also considered an anti-pattern because it makes people remember the days of ivory tower process committees.

Release Train Engineers define consistent cross-team process and cadence, and handle many operational tasks. Ultimately this leaves less room for individual teams to modify, improve, or experiment with their own practices in any way that deviates from established standards. - Sean Dexter, “Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness”

In unFIX, there are no roles outside Crews. If Scrum Masters feel the need to standardize things across their Crews (and there could be good reasons for doing so), they can establish a Forum, elect a Chair, and get going. In traditional companies, Chairs could be appointed by Chiefs, but that shouldn’t change much. The Chair of a Forum just moderates the debates and steers the group toward decisions. She is not a separate process manager handing down standards from her ivory tower.

System Architect/Engineering and the Architectural Runway

In almost every ART or Base, teams need architectural guidelines that enhance solution design, performance, and usability. On top of that, when the teams work on one solution (in a Fully Integrated Base), they need direction for cross-team design and integration.

In SAFe, System Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART). These people help explain the technology infrastructure, decompose systems into components and subsystems, and define and manage interfaces and APIs.

The Architectural Runway consists of the existing code, components, and technical infrastructure necessary to support the implementation of high-priority, near-term features. It is one of the primary tools used to implement the Agile Architecture strategy of SAFe.

In SAFe, the teams that build the runway iterate like every other Agile team in the ART. They could have (temporary) assistance from more specialized System Teams that help build the environments and assist with system and solution integration.

In the unFIX model, we can cover the same responsibilities with a Platform Crew (working as a separate team) or a Facilitation Crew (working directly on the Value Stream Crews). Additionally, we might introduce a Capability Crew for sharing some rare technical skills among many Crews. There is no one way of doing this, and the goal of unFIX is not to get stuck in one kind of implementation. It depends!

Business Owners and Managers

SAFe defines the Business Owners as the key managers who guide the ART toward desirable outcomes. Business Owners are the stakeholders responsible for governance, compliance, and return on investment (ROI) of an Agile Release Train. They assign business value to objectives and approve the plans.

SAFe also says that an organization’s managers and Lean-Agile Leadership are responsible for adopting, succeeding, and improving the ARTs. Only the managers have the authority to change and continuously improve the systems that govern how work is performed.

The difference between Business Owners and management/leadership is one of the most confusing parts of SAFe. Officially, Business Owners are not the same as managers because SAFe does not prescribe a reporting structure. In fact, SAFe emphasizes that ARTs are “virtual organizations formed to span functional boundaries”. This is understandable because this makes it possible to offer SAFe to bureaucratic companies without requiring any changes to line management territories. However, a direct result of this approach is that companies become matrix organizations. And the matrix structure was already dismissed years ago by organization design experts as too problematic and too management-heavy.

One key finding from organizations with matrix structures is indeed that higher-level managers become overloaded because lower-level managers are unable to resolve conflicts and therefore refer conflicts to the executives. In other words, an unintended consequence of a matrix structure is actually to make the organization more centralized and to remove accountability from lower-level managers. - Nicolay Worren, Organization Design: Simplifying Complex Systems

In unFIX, I prefer clarity over confusion. When most people are dedicated full time to their Base (same as team members in an ART), why not accept that this requires a management team (the Governance Crew) in the Base? Indeed, this makes unFIX a bit more challenging to sell—it might require changes to line management territories, oh dear!—but at least you keep the matrix out the door. Conflicts can escalate only one level up to arrive at the Governance Crew, where the Chiefs can resolve them.

The crucial difference with SAFe is that nobody in a Base—except those in the Governance Crew—can be someone else’s line manager. The Chiefs have everyone else in the Base as their direct reports. In SAFe, it would be possible for one Agile team member to be the manager of the others, and it would be possible for a Product Manager to be the manager of the POs. With unFIX, I explicitly reject this because managers tend to protect their territories, and it would be tough to keep the structure dynamic and unfixed. And that’s the goal.

In other words, the Business Owners in SAFe correspond to the Governance Crew in unFIX, but we insist that they are managers. At the same time, we use delegation levels to empower the Base and push responsibilities away from the Chiefs toward the self-organizing group of Crews and Forums with their Captains and Chairs.

Cadence and Synchronization

SAFe assumes that all teams work on one solution and requires that they all work in sync. For this reason, in each ART, SAFe insists on a cadence that offers a “steady heartbeat” for the development process. The train departs the station on a known, reliable schedule, and when a feature misses a timed departure, it can catch the next one.

The problem is that this “next departure” is only after 8 to 12 weeks because that’s the length of a Program Increment (PI), and all teams on the train are synchronized to the same PI length. This makes it very hard for teams in an ART to respond fast to changes (the fourth fundamental value of Agile).

With SAFe, you typically receive feedback on working software after the Release Train ends, which takes somewhere between 6 and 10 weeks. This is really late for today’s standards. Sure, SAFe allows you to implement software earlier. But the incentives are to only do this at the end of the Release Train. - Willem-Jan Ageling, “My Issues with SAFe”

As soon as PI planning ends, those plans created based on limited understanding and numerous assumptions will become obsolete as soon as anything new is learned. Teams will be continuously torn between sticking to the plan they’ve learned doesn’t make sense and reorienting expectations for reasons those above them may not be in a position to understand. - Sean Dexter, “Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness”

The unFIX model does not impose a process cadence on a Base. Fully Segregated and Loosely Aligned Bases have no use for a shared rhythm, so why bother? In Fully Integrated and Strongly Aligned Bases, we leave the decision about cadence to the Governance Crew, but the Chiefs might find it wise to delegate that decision to Facilitation Crews. Who would know better whether syncing would be helpful than those who do the actual work?

Business Lifecycle

One thing that sets unFIX apart from every other framework is acknowledging the importance of the business lifecycle. Business models typically follow the curve of the ten lifecycle stages. The entire Base should focus on a specific stage, or the individual Value Stream Crews work in several stages.

SAFe does indeed pay lip service to a more simplistic version of product lifecycle stages, but the concept has not found its way into any of the SAFe practices.

In unFIX, the business lifecycle is a core concept, and every practice that I might add to the model later will be held up against the ten lifecycle stages. Everything is context-dependent, and the way we manage a young, startup business model should be completely different from how we treat a mature, profitable line of business. I prefer to keep all practices unfixed.

Delegation Levels

Another thing that sets unFIX apart from others is the concept of delegation levels.

Maybe the Captains of Crews are appointed by the Chiefs (level 1: Tell); perhaps they are picked after proposals from their fellow Crew members (level 3: Consult). Maybe Captains are elected by their Crews after suggestions from the Chiefs (level 5: Advise), or the Crews self-organize without the Chiefs having any say in the process (level 7: Delegate).

What I just described for the selection of Captains can also be applied to key decision areas such as Chair selection, Crew formation, Forum participation, cadence selection, and so on, and so on. Why should one framework make all these decisions for everyone on the planet? I am against one-size-fits-all approaches, and I recognize the need for all Bases to define their own constraints on self-organization. Let the Chiefs and the members in their Base figure out the appropriate delegation levels for which key decision areas. They're adults. They can handle it. Don't ask me to do the thinking for everyone.

Innovation Vortex

The feedback cycle in SAFe is another area where I feel bewildered. SAFe defines iterations wrapped up in increments. The iterations consist of Iteration Planning, Iteration Execution, Iteration Review, and Iteration Retrospectives, which are likened to the traditional Plan-Do-Check-Act model. Okay, so far, so good.

However, the framework also repeatedly refers to the so-called Continuous Delivery Pipeline, which consists of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand (RoD). On top of that, SAFe includes Design Thinking with yet another iterative model consisting of Discover, Define, Develop, Deliver.

It seems as if SAFe embraces and assimilates every iterative model out there without actually synthesizing them all into something cohesive.

With unFIX, I use just one iterative/incremental model: the Innovation Vortex. I consider every other model to be a variant of it. The Innovation Vortex merges and subsumes the models of Design Thinking, Lean Startup, Agile, PDCA, and many others. If you prefer, you can swap one for the other. It shouldn't matter that much. However, in the unFIX model, I stick to the one I like best.

Experience Over Product

Last but not least—and this is a pet peeve of mine—I see the need to move away from products toward experiences. We are not in the business of making products and solutions consisting of bytes or atoms; we are in the business of delighting users and customers and making them happier by offering value and getting their jobs done. Our products and solutions are just the means to that end.

And yet, the Scaled Agile Framework is written entirely around products and solutions. The glossary mentions the word product 21 times and the word solution 67 times. Sadly, the word experience gets only three mentions. To be fair, this is not a problem of SAFe particularly but a pervasive issue in the entire software development industry.

For this reason, I added the Experience Crew as managers of the output experience (users, customers) and the Partnership Crew as managers of the input experience (vendors, freelancers, gig workers). You can consider them to be specialized Facilitation Crews, but I feel they deserve being called out explicitly to remind everyone in the Base that we are creating experiences, not just products and solutions.

Continuous Transformation

One major issue remains after this long list of differences between SAFe and unFIX. And I believe it is the most important one: SAFe suggests the rollout of one extensive transformation, with one organization design, and then you’re done. You’re SAFe!

With unFIX, it is the opposite. I believe in an endless stream of small changes with no end in sight because tomorrow’s organization design should be different from yesterday’s. The organization is never done. There’s always something to unfix!

SAFe involves simultaneous changes to a huge new process across an enormous ecosystem— a massive risk. - Sean Dexter, “Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness”

Attempting to apply one blanket process to the entire company, a process that is focused strictly on delivery rather than continuous discovery and course correction, only hardens traditional ways of working. SAFe is compelling because it seems to offer a one-size-fits-all recipe for agility at scale. - Jeff Gothelf, “SAFe Is Not Agile”

Indeed, the Scaled Agile Framework is a one-size-fits-all solution. It is an extensive, static framework that needs to be rolled out as a complete organization redesign. You cannot try SAFe in only one team. You cannot have several teams figure out their own SAFe approach. With its top-down, cross-team cadence, the ART is an essential feature of SAFe.

The unFIX model is the opposite of one-size-fits-all. unFIX is like LEGO. It consists of just a few elements that you can combine and recombine in countless ways, and nearly all of them are optional. One Value Stream Crew in one Base is already a valid unFIX structure. Twenty independent Crews with two Forums in a Fully Segregated Base is also valid. And fifty Crews of all seven types, combined with eight Forums, working on one solution, in a synchronized cadence, in a Fully Integrated Base? Yup, that can be valid as well. It’s your business, your design.

Combine this modularity of unFIX with the idea of the Business Lifecycle, which says that business models (and Bases) come and go in a never-ending cycle of evolution and self-renewal, and you will realize that you’ve achieved continuous transformation. Every Base is different. Each has its own (temporary) organization design, depending on the value delivered to its customers. No structure is permanent. Everything is unfixed.

Conclusion

To summarize, there are many differences between SAFe and unFIX:

SAFe is more than ten years old; unFIX is just getting started;
SAFe is for medium to large companies; unFIX is for small to medium-sized companies;
SAFe is specifically about software; unFIX can also apply to non-software businesses;
SAFe assumes a fully integrated ART; unFIX offers four different Base types;
SAFe teams are 5 to 11 people; unFIX suggests 3 to 7 members per Crew;
SAFe has one PO per team; unFIX allows the Captain role to be shared;
SAFe has Product Management between the customer and PO; unFIX doesn’t allow that;
SAFe has a Release Train Engineer making processes; unFIX makes this a Forum thing;
SAFe allows managers everywhere, which leads to a matrix; unFIX insists they are Chiefs;
SAFe requires a cadence across all teams; unFIX leaves a rhythm as optional;
SAFe has no notion of lifecycle stages; unFIX has this as a fundamental concept;
SAFe defines specific accountabilities; unFIX allows levels of delegation everywhere;
SAFe describes a multitude of iterative cycles; unFIX has adopted only one;
SAFe has a focus on products and solutions; unFIX has its emphasis on experience;
SAFe is a one-size-fits-all framework; unFIX is like LEGO: you can make anything.

On top of this, SAFe offers many practices for product management and product development. unFIX doesn’t provide any of that (yet). But that doesn’t mean that SAFe has more to offer.

I don’t personally know of a single leading tech product company that is using SAFe. [...] All the examples I have found are big IT, project-mindset organizations – big banks and insurance companies – not technology-powered product-mindset companies. [...] I can’t imagine any of the strong tech product companies I know choosing to move to SAFe, and if for some reason they did, I’m pretty certain their top talent would leave. - Marty Cagan, “Revenge of the PMO”

After all the criticism, perhaps I should end with a compliment. The Scaled Agile Framework knows how to sell itself very well. In most organizations, managers are the ones who decide what to buy and, therefore, managers need to understand where they will end up in any organization redesign. Frameworks and organization design models ignore managers at their own peril.

The key ‘buyers’ of scaled Agile approaches are managers – and SAFe speaks to management and gives them a role as “Lean/Agile Leaders” in a way that other approaches don’t. - David Hicks, “SAFe and LeSS: Much Ado About Nothing”

The unFIX model does not ignore management. On the contrary, the model clearly defines where the managers should go: in the Governance Crew, and—more importantly—it says where they should stay out: everywhere else!

And that’s it.

No, wait! There’s one more difference:

unFIX is prettier.

😁

Become a Free Member Now!

Let’s Unfix the Scaled Agile Framework (SAFe)