Author: Jurgen Appelo

Introduction

In 2005, Craig Larman and Bas Vodde started working on Large Scale Scrum (LeSS) by applying Scrum to large multisite product development. The framework is intended for product groups of anything between two teams up to a few thousand people. Coaches and consultants usually see LeSS as the leading alternative to the Scaled Agile Framework (SAFe). (Also see: "Let's Unfix the Scaled Agile Framework")

The unFIX model was published in January 2022 (with an early version in September 2021). It is a more generic model (not explicitly focused on product development only), and its target audience is small to medium-sized companies with a need for agility and innovation.

So, how do these two approaches compare?

Product Groups

Let's start with an essential difference. The scope of LeSS is the Product Group. That’s everyone who works together to build one product. If an organization makes multiple products, it could have several LeSS implementations.

The scope of unFIX is the Base. Its primary purpose is to offer workers a sense of belonging (a home), a sense of purpose (goals), and a place for recognition (rewards). People could be working on one product, one service, or multiple products and services within the Base. Each Base is either Fully Integrated, Strongly Aligned, Loosely Aligned, or Fully Segregated.

Example of a Fully Integrated Base — Fully Integrated Base

In other words, the starting point is different. If a Base makes one large product (Fully Integrated), the Base in unFIX and the product group in LeSS are almost the same thing. However, when a Base makes three somewhat related products (Loosely Aligned), it could be a wrapper for three separate LeSS implementations. And when a Base makes only a part of a much larger product, the LeSS implementation would cover multiple Bases.

Feature Teams

At first glance, the definition of a team (or feature team) in LeSS is very much the same as a Crew (or Value Stream Crew) in unFIX. They are small groups of goal-driven, customer-focused people working together to accomplish something. However, at a closer look, some differences become evident.

Smaller Team Size

The typical team size in LeSS is defined as 7 plus or minus 2. In unFIX, I suggest a bit smaller: 5 +/- 2. Twelve years ago, I found that (in general) the optimum team size is around five people. Nowadays, the era of remote and hybrid working calls for smaller teams than usual, not larger. Therefore, three to seven Crew members seems like a good rule of thumb to me.

Not Full-Time

LeSS insists that team members are full-time dedicated to one and only one team. In theory, this sounds good, but, in practice, there are always exceptions. Team members may want to work part-time, or they may wish to contribute to communities (see below), which costs time. And what does "full-time" mean anyway in a "results-only work environment" where we evaluate people for their results rather than their time? Neither my spouse and family, nor my book project, nor the unFIX website gets 100% of the time I am awake.

Assisted with technologies, humans get better and better at switching between multiple contexts and communities. That doesn't mean that we are less committed to any of them. In unFIX, there is no such thing as "full-time" because it's not clear what that means anymore. The world has moved on.

Not Co-Located

LeSS strongly advises teams to be co-located and in the same room. To me, this just shows that it's an old framework, created long before people learned how to get work done during the Covid-19 pandemic. At the time of writing (January 2022), the advice has not been updated (yet). Sure, there are important benefits to having the whole team in one room. But companies such as Github, Automattic, and many more have shown that there are also tremendous benefits to working fully remote. The unFIX model takes no sides here: fully co-located, fully remote, or some form of hybrid working, you do what's good for you and your business.

Not Long-Lived

The LeSS documentation repeatedly calls for teams to be long-lived and even staying together "forever"! Again, this seems somewhat archaic. In her book Dynamic Reteaming, Heidi Helfand shows that reforming teams and rotating team members comes with several benefits: improved learning, increased business agility, and better personal development. Chris Smith published multiple articles on Redgate's annual reteaming efforts. On the Serious Scrum blog, you find examples of successful reteaming with fluid Scrum teams, every sprint. And Agile expert Joe Justice has first-hand experience at Tesla with reteaming every three hours!

It seems that the advice to "keep your teams long-lived" is offered by people with no experience in reteaming. They don't know how to do it well, so they'd rather not do it at all. With the unFIX model, I strongly suggest that your organization develops the capability of dynamic reteaming. Maybe not every three hours, and not every sprint, but as often as it makes sense to you.

Product Owner

In LeSS, there is typically one Product Owner (sometimes called the Product Manager) for all teams who work on the same product. However, the LeSS website also says that other product managers could support this person. Either way, they are all peers of each other and of the features teams that make the product.

It is important to note that the PO in LeSS is a connector, not an intermediary. The teams are still in direct contact and conversation with the actual users and customers. It is not okay for a Product Manager to take a position between a team and the end-users, relaying all the information. (I pointed at this problem in my previous post, "Let's Unfix the Scaled Agile Framework")

In the unFIX model, I believe we have the same construct when we see the Product Owner(s) as an Experience Crew. This crew would then consist of one or more crew members responsible for product management on the Value Stream Crews. Whether that is just one person (as LeSS prefers), or a few people supporting each other, is up to you. Either way, LeSS, and unFIX could be a good enough match here.

However, it's worth pointing out that the Experience Crew in unFIX focuses on the entire customer experience, not just the product. This includes any part of the business that has touchpoints with the customer, such as support, marketing, and finance. When you only focus on the product and not on the whole experience, you're still sub-optimizing!

Scrum Master

LeSS has Scrum Masters "helping people to see beyond their individual perspective to the larger production system". These Scrum Masters might divide their time over two or three teams because most organizations cannot afford a dedicated Scrum Master per team (and the Scrum Masters probably wouldn't have enough to do anyway).

In unFIX, this is precisely why we have Facilitation Crews. The Scrum Masters form their own crew, and they divide their attention across the various Value Stream Crews, making sure that these crews coordinate their work and keep seeing things from the "whole product" perspective. Again, there is a good match here between LeSS and unFIX.

Kaizen and Kaikaku

One area where LeSS and unFIX move apart is on the topic of coordination. In LeSS, multi-team coordination is the responsibility of the teams. LeSS does not allow a project/program organization or project/program management office (PMO) as this would cause "confusion and conflicts of responsibilities". In LeSS, it is clear that the teams themselves are responsible for coordinating their work with other groups.

Likewise, in LeSS, so-called "undone departments" such as Quality Assurance, Architecture, and Business Analysis should not exist. You should fully integrate their work into the teams.

I can agree with these principles, in principle. 😉 However, a difficult, disruptive change from command-and-control to complete self-organization is kaikaku, not kaizen. For many organizations, this is hard to pull off. For this reason, I introduced delegation levels in Management 3.0, and they are also a fundamental aspect of the unFIX model.

With traditional organizations that still have a PMO (or QA department or Architect or Business Analyst), I can imagine that the first step would be to set up a Facilitation Crew that handles this responsibility together with the teams. The Captain of this Facilitation Crew could—in the beginning—be appointed by management (Level 1: Tell). However, over time, nominations for the role of Captain could be collected from its crew members (Level 3: Consult), and later, the crew members could pick their own Captain, maybe with free advice from management (Level 5: Advise). As a final step, the Facilitation Crew that handles coordination (or quality assurance or architecture or business analysis) could be disbanded when teams have learned how to do this work themselves. The result would then be the same as in LeSS.

With Facilitation Crews and delegation levels, you can turn a disruptive, painful break with the past (kaikaku) into more a gradual, continuous change (kaizen). I'm not saying one is better than the other. I like having options, and the unFIX model gives you this choice.

Capability Crews

Sometimes, a product group relies on a couple of experts, and you want their talent to be available to all teams. In LeSS, these experts can become "travelers" by occasionally joining different teams for coaching, pairing, and teaching.

I find that suggestion a bit weak. The Team Topologies book, on which I based the Crew types in unFIX, has a specific solution for this ("complicated subsystem teams"), which has become the Capability Crew in unFIX. Such a crew aims to make rare skills of a few people available to an entire Base. This could be temporary or permanent. Though the solution is somewhat hidden, the LeSS suggestion is an excellent first step, but unFIX has taken the idea two steps further and promoted it to a core feature of the model.

Platform Crews

Where LeSS falls short, in my opinion, is the omission of the platform concept. The Team Topologies book says that it can be helpful (for some organizations) to have a platform team, which has become the Platform Crew in the unFIX model. This Platform Crew acts like a vendor to the other crews in the Base, possibly even supporting them with APIs and SLAs.

LeSS doesn't suggest anything like this. On the contrary, it tells you to add all infrastructure work to the Product Backlog and then treat each infrastructure feature "as if it were a customer-centric feature". I believe this can work for a while. But I know from experience that successful new products and business models can emerge by allowing shared infrastructure to be first split off into a Platform Crew and then later moved into its own separate Base. Sadly, the LeSS framework does not address this business opportunity.

Scrum and Sprints

Because LeSS is based entirely on Scrum, it mandates the standard Scrum practices such as Sprint Planning, Sprint Review, and Sprint Retrospectives.

The unFIX model is (at the time of writing) mainly an organization design tool. There is no concept of specific processes and flow. The Value Stream Crews can follow Scrum and do sprints, but they can also choose Kanban, XP, or any other method or process framework. unFIX takes no sides, as long as the chosen approach favors agility and innovation.

Managers and Matrices

What I particularly appreciate about LeSS is its apparent dislike of matrix organizations. It is mentioned more than once on the website. There is also explicit mention of the role of middle management, which is "to see the whole and build the capability of the organization to build great products". And LeSS insists that managers stay out of the product organization, which is excellent. But sadly, the model doesn't clarify where all those managers should go (although the "Head of Product Group" gives you a hint).

The unFIX model dedicates a specific place for the Chiefs in the Governance Crew and insists that everyone in the Base has a Chief as their manager. The reason is, if you don't do that, you could still end up with a matrix organization. People on the same team could have their line managers in entirely different parts of the organization, which can be a significant problem in terms of conflict resolution. In the unFIX model, any conflict can escalate only one level up and is then caught in the Governance Crew if not resolved within the Crews. It can never shoot up the hierarchy and blow up the whole system like an uncaught exception in a flawed software design.

Forums

LeSS mentions Communities of Practice (CoP) as a great way for people to connect across the organization when they have a passion for learning and contributing. CoPs provide a place and structure to focus on knowledge sharing and ways of working. The coordinator of such a CoP usually emerges from the group because of a passion for the subject.

In unFIX language, this would be a Forum, and its moderator would be the Chair. In many settings, a Forum serves the same purpose as a Community of Practice, with the entire Forum self-organized and independent of management. However, another use for a Forum could be the gradual delegation of functional or divisional management responsibilities.

Traditional organizations need a way to get rid of their functional departments while retaining the possibility for people in a similar job to discuss their roles and learn from each other. Likewise, an organization may not want to abolish a regional division without a way for people in the same region to share their regional knowledge and experience. In such cases, Forums offer a way out. And, as I described above, under "Kaizen and Kaikaku", with delegation levels, the managers can make the transformation a gradual change rather than a disruptive shock.

Conclusion

As a framework, LeSS offers part organization design and part process flow. For more concrete suggestions on how to build a product with multiple teams, LeSS seems like a fine choice, even though, at some points, its advice seems a bit old-fashioned.

There are also things that unFIX offers that are not within the scope of LeSS: delegation levels, Innovation Vortex, business lifecycle stages, Experience Crews, Capability Crews, Platform Crews, and Partnership Crews. This is by design and not intended as criticism. On the contrary, it seems to me that LeSS and unFIX are pretty complementary.

Having said that, a few differences are worth pointing out:

LeSS focuses on the product group; unFIX has its focus on the Base.
LeSS considers only the product; unFIX emphasizes the customer experience.
LeSS suggests 7 +/- members per team; unFIX says 5 +/- members per Crew.
LeSS wants full-time team members; unFIX does not require this.
LeSS prefers co-location of the team; unFIX is for Crews that work anywhere.
LeSS wants long-lived teams; unFIX nudges you toward dynamic reteaming.
LeSS is Scrum-based; unFIX allows for any agile/innovative process method.
LeSS needs a disruptive structural change; unFIX allows a more gradual approach.
LeSS has only feature teams; unFIX has seven different Crew types.
LeSS has many process suggestions; unFIX is silent on that matter.
LeSS leaves the door open to matrix structures; unFIX keeps that door closed.
LeSS offers advice that’s a bit … archaic; unFIX is up-to-date with the trends.

I don't see any of these differences as problematic. It's not that difficult to combine LeSS with unFIX so that you end up with something that's strong in product development and organization design.

What do you think?

Interested? Sign up now!

Let’s Unfix Large-Scale Scrum (LeSS)