Essentially, all models are wrong, but some are useful.”        – George Box, Statistician

Dear all,

fostered by a rainy May Day, this WR has become a much longer post than intended. If it feels tl;dr, just skip down to the reads.

What we do – mostly – at go3consulting is develop what we dub „working models.“ Essentially ways to orchestrate teams to successfully deliver (digital-) products to strategies (or at least project goals) effectively.

In doing so, we work with our clients to customize and apply frameworks, heuristics, and learnings from almost half a century of Lean and Agile innovation and product development.

Recently, there have been some updates in the scaling frameworks department. SAFe 6.0 just got dropped, and Jurgen Appelo’s unFIX is starting to make waves — time to look at the frameworks landscape again.

Why do we Need Scaling Agile Frameworks at all?

When the Agile Manifesto was written, it was created with small teams that have direct customer access in mind. Partially from a somewhat artisan and anarchist reaction to the „waterfall“ attempts to „manage“ software projects starting in the 1980s, partly because software teams that could deliver a value stream were still comparably small at the time.

With „Software eating the world“ and an ever-increasing size of software projects came more technical and other dependencies between „agile“ teams and the rest of the organizations. It also became clear quickly that the de-facto Agile standard, Scrum, is insufficient to develop customer-facing digital products or manage large corporate software undertakings that require more than one team to capture a value stream.

Trying to manage these challenges gave rise to the scaling frameworks we know today.

A Brief History of Agile Scaling Frameworks

Scaling models began to appear within a few years after the publication of the Agile Manifesto 2001. Bas Vodde and Craig Larman started to work on LeSS (Large Scale Scrum) in 2005 at Nokia-Siemens. Dean Leffingwell published „Scaling Software Agility“ 2007 and released SAFe (Scaled Agile Framework) 1.0 in 2011. Henrik Kniberg and Anders Ivarsson wrote „Scaling Agile @ Spotify“ in 2012, giving rise to what is known as the „Spotify Model.“ In 2021 Jurgen Appelo released „unFIX,“ which he claims is not a scaling framework.

And in between, there are Disciplined Agile (DA) by Scott Ambler and Mark Lines (2013), NEXUS by Scrum.org (2015), FAST (2021), and Enterprise Kanban, which we rarely see applied by our clients and will therefore largely ignore in this WR.

No Scaling Framework Seems Measurably Superior

There are many discussions about the „agileness“ and „effectiveness“ of the frameworks in the industry that sometimes border on religious disputes. SAFe, in particular, has a bad reputation among Agile practitioners. Age of Product’s Stefan Wolpers, e.g. reports a low NPS of -56 for SAFe from a sample of 505 survey participants.

The reality is that there seem to be no measurable differences in terms of team effectiveness and stakeholder satisfaction between scaling approaches. Christian Verwijs concludes from his quantitative study analyzing nearly 2000 Scrum teams applying SAFe and other scaling approaches: “The quality of the core factors that make Scrum teams effective is not meaningfully different between the scaling approaches.”

This may also mean that the surveyed organizations have chosen, developed, or adapted the model to fit them. Verwijs suggests that it may be more important to „…focus our energy more on ensuring the quality of these processes rather than the adherence to some idealized framework.“

Which Scaling Model to Start from?

At go3consulting, we consider scaling frameworks reference designs or patterns for the customized models we develop in collaboration with our clients. They provide context and reference for clients who are usually uneasy about change. In addition, starting from a referenceable model usually also simplifies communication with a client’s management.

When contemplating a model as a reference design, we consider various factors. For instance, we determine whether the model is sufficiently outcome-driven in the client’s context or will lead to undue overhead. Additionally, we assess whether the model can handle the observed complexity or dependency structures. Conversely,we also consider the level of complexity introduced by the model itself. On top,we determine whether the model will significantly impact the organization, such as requiring extensive changes to roles or structures. Finally, we consider cultural fit.

While we are considering this case by case, we believe that the models as such have different use cases:

LeSS (Large Scale Scrum)

LeSS is completely Scrum based. Therefore its base cadence is the Sprint, which makes it a very nimble scaling model. LeSS, in its basic form, is suggested for up to 8 cross-functional teams of +/- 7 members working on separate areas of the same product. All teams are fully x-functional feature teams and share one PO and one backlog. Beyond the typical Scrum events, LeSS relies heavily on (informal) interpersonal information sharing between the teams („just talk“) for anything beyond refinement and planning. From a Scrum practitioner’s perspective, LeSS appears simple and straightforward, but introducing it into a traditional organization is highly disruptive as it completely relies on Scrum roles. With dedicated and fully x-functional feature teams, LeSS also assumes team structures that often are difficult to attain. In addition, it relegates middle managers purely to capability management and explicitly requires them to stay out of product development.

Our assessment is that LeSS‘ product focus and lean model can be extremely beneficial when there is a cultural alignment. From our observations, LeSS can be particularly effective for small to mid-size products and up to department level if management prioritizes results and considers themselves servant leaders. It requires strong product leads, qualified well beyond typical Scrum POs, and benefits from formalizing inter-team dependency management further.

SAFe (Scaled Agile Framework)

The Scaled Agile Framework (SAFe) focuses on orchestrating value-prioritized feature delivery across multiple value streams. Its base cadence is the PI („Planning Interval“ per SAFe 6.0), typically a 3-month period. This leads to comparably long plan-to-outcome intervals and limited organizational agility. However, itselaborate planning process (Pre-PI-, PI-, and Post-PI planning) ensures the reliable handling of dependencies and complex component relationships. Building from typical Agile/Scrum team structures that are virtually grouped into Agile Release Trains for delivery, it introduces several additional roles that hierarchically replicate (Product Manager, Solution Manager, …) and expand in responsibility with scaling level. While being hierarchical, SAFe’s roles are notably different from typical corporate roles. For this reason, implementing SAFe entails a major change project. With its drive to incorporate recent methods and trends from Design Thinking to OKRs, SAFe has, in part, become unwieldy and requires some rightsizing for implementation.

We consider SAFe a modern version of software project management that incorporates many proven Agile and Lean practices. Well-implemented, it is strong on scaling aligned planning and dependency management but has weaknesses in customer orientation and execution speed. SAFe can improve the outcomes of complex enterprise projects, but the transformation effort required for its implementation should not be underestimated. Driven by the right organization- and technology architecture strategy, SAFe can also be used as a tool to transform hierarchical project organizations into agile product organizations. Implementing SAFe requires top-level management backing, time, and experienced consultants.

The Spotify Model

The „Spotify Model was never meant to be a „model“ in the first place: „This article is only a snapshot of our current way of working – a journey in progress, not a journey completed. By the time you read this, things have already changed.“ (Kniberg/Ivarsson 2012)

The „Spotify Model“ is enticing because it is a highly product-centric and learning scaling model that is still light on process. As Henrik Kniberg says elsewhere: „Rules are a good start, but then break them when needed.“

At the same time, the „Spotify Model“ balances outcome focus with technical excellence. Spotify’s Squads are conceived to be mission-driven agile product- or product component teams, each guided by a PO. The POs are loosely coupled through a high-level roadmap pursued by their subject area Tribe. Beyond the PO, the model stipulates Agile Coaches, System Owners as go-to persons for technical and architectural issues, Tribe Leads, and a Chief Architect. At the same time, the specialists that make up the squads are members of a „Chapter“ that manages them as resources and facilitates the development of concepts and capabilities. The model also introduces the idea of „Trios,“ combining a Tribe Manager, a Product Lead, and a Design Lead to ensure all relevant perspectives of the product are covered. These Trios are encouraged to flexibly form Alliances with other Tribes‘ Trios to pursue goals beyond the scope of one Tribe.

In addition, the defining article explains a dependency management concept that fosters regrouping squads into new Tribe structures to reduce inter-Tribe dependencies, somewhat akin to domain-driven models. Also, surveys are integral to continuously improving the model and its organizational structures.

We believe the “model” holds many vital clues for building flexible organizations that deliver fast-evolving digital products. The model explicitly acknowledges the need for management and provides more structure than, e.g., LeSS, but is simultaneously designed for continuous evolution. When using it as a reference design, we consider it essential to preserve this evolutionary component as it otherwise quickly degrades into a mere matrix organization, with all the adverse effects associated. For this reason, cultural fit is essential when considering the model, particularly in corporate environments.

Jurgen Appelo’s unFIX

Jurgen Appelo has been an Agile thought leader for more than a decade. His tools-focused Management 3.0 approach to agile management has built a large following in the international Lean and Agile community.

Per its website, the unFIX model was first published in 2022 and is  „…a simple tool that helps you with versatile organization design. Unlike many agile scaling frameworks and self-management methods, unFIX has its focus on continuous innovation and the human experience. It facilitates gradual change, dynamic teams, and an important role to play for managers.

unFix is best described as a library of organization patterns that takes many clues from Manuel Pais‘ and Matthew Skelton’s groundbreaking work „Team Topologies“ (see also this WR), the „Spotify Model,“ and the organizations of fast-moving companies like Haier and Tesla. Appelo himself describes it as „…an aggregation of common sense ideas already in use at countless businesses worldwide.“

unFIX maintains a set of these patterns (Crews, Forums, Turfs, Tribes,…), role attributes (Chief, Captain, Enabler, Guide,…), models (teaming options, lifecycle stages, dependency breakers, …), and a dynamic set of principles like e.g. „Balance high cohesion with low coupling.“ The „Innovation Vortex“ is an iterative and incremental „process model“ based on a combination of Design Thinking and Lean Startup principles that can serve both for designing organizations and as a generic process blueprint.

We regard the unFIX model as a handy, Lego-like toolkit for (re-)structuring organizations. It intelligently integrates many patterns and practices that have evolved over the past decade into a consistent and applicable model. At this point, it is light on process, referencing agile practices described elsewhere. With its „Spotify-like“ dynamic approach to organizations, it lends itself to small to medium size outcome-focused product- or innovation organizations, not stopping at software development. Much like the Spotify model, it acknowledges the role of management in putting boundaries around self-organization. Appelo sees the model as non-disruptive, facilitating gradual change. As with the Spotify model, we consider cultural fit a possible challenge, particularly for enterprise organizations.

None of the Models Should be Used „Out of the Box“

Effective implementation of Scaling Agile models requires careful selection and adaptation to meet the specific needs of a given context. Based on our observations, many organizations are meanwhile accomplishing this, regardless of whether they begin with SAFe or one of the other models discussed. This is also evidenced by the significant number of „custom“ survey responses (e.g. Koblenz University, C-Prime) received when inquiring about scaling models implemented.

Here are some more perspectives on scaling:

Is SAFe® Really That Bad?

No scaling framework appears to be measurably superior. Link to the study by Christian Verwijs mentioned above.

Click to view!

Scaling Pipedrive Engineering — From Teams to Tribes

A great example of a “homegrown” approach using the “Spotify Model” and other inputs (two articles!)
Click to view!

Click to view!

Why Agile is Better than Waterfall (Based on the Standish Group Chaos Report 2020)

In case it had not registered – still worthwhile reading!

Click to view!

Have a great start into a hopefully less rainy week

All the best,
Godehard