SAFe vs LeSS: Understanding the Difference

This article was originally published here.

History & Origins

SAFe was created by Dean Leffingwell, a successful entrepreneur and software development methodologist, who has consulted with many companies including Rational Software, Rally Software, as well as many others. Dean’s LinkedIn profile displays “Chief Methodologist'' in the title. LeSS was co-founded by Craig Larman and Bas Vodde, both of whom are hands-on software developers with many years (up until today) of experience in large-scale, multi-site product development environments, including product companies, large telecom, and investment banking. Both co-founders have experience with organizational design and system modeling (a big part of LeSS). Interestingly, Craig’s LinkedIn profile states “public safety, junior programmer” and Bas’ is “team member.” The irony is in the modesty of their titles since both co-founders have made a monumental investment in the industry in the area of agile product development during the last few decades.

The initial release of the SAFe program was in 2011 with five major releases that followed.

Although LeSS was announced as an *official* framework in only 2015, its history goes back decades. The three Large Scale Scrum product development books were written in 2008, 2010, and 2016 respectively with many field experiments collected over the years prior to 2008. Essentially, LeSS has been a huge body of knowledge, collected over many years, before it became known as the framework.

Market Share, Framework Versioning, and Certifications

SAFe is widely known. Its market share in the world of scaling is by far the highest of all known frameworks. The consultancy market is dominated by Certified SAFe Product Consultants (SPC) that hold at least one of many SAFe badges. Because there are so many versions of SAFe (2.0, 4.0, 4.5, 4.6, 5.0), naturally, certification holders are driven to come back for an upgrade training to remain up-to-date. Since SAFe supports a number of roles that are aligned to traditional organizational roles, many SAFe courses are role-specific. The number of instructors who can deliver SAFe courses is also high, with many course-reselling companies being actively involved in marketing, promoting, and reselling.

LeSS is not as widely known. Its market share in comparison to SAFe is low. There are only three main types of LeSS certifications (Basics, Practitioner, and Executives), with the other few types mainly being online versions of the three types. LeSS training/certification is not ‘role-specific LeSS adoptions are deep and narrow (as opposed to being broad & shallow). According to field experts, there is no expectation that LeSS will become mainstream in the foreseeable future. This is most likely because LeSS has high expectations for organizational design improvements (see below) that many companies are not yet ready for. Today, there are very few LeSS-trained/certified people because the number of accredited LeSS instructors is also relatively low (slightly over 20 people, globally). LeSS, just like Scrum, does not have any versions. There are two LeSS frameworks: [simple] LeSS framework (up to 8 teams) and LeSS Huge (stacks of LeSS, totaling hundreds or more people, if required).

Influence by Large Consultancies

Many large consultancies recommend SAFe to its clients as a framework of choice (Note: As a corollary, many companies-clients, to officially remain framework-agnostic, adopt their own flavor of SAFe, essentially using their own internal terminology while mimicking/mapping to SAFe terminology, structure, etc). For large consultancies, this ensures a more profitable and prolonged engagement, since SAFe implementation involves many people, processes, and tools (see below). Dave Snowden refers to this type of engagement as an ‘industrial model’ since it ensures a “massive roll-out, with lots of people, over a long period of time.” (also, see this “Triple Taxation” illustration to understand a financial impact on companies-clients). Another reason why SAFe happens to be a framework of choice by large consulting companies is because the framework itself does not require any major changes to a traditional organization design and as such, does not put large consultancy representatives in an uncomfortable position of purists-radicals who have to challenge their clients’ ways of working (not too much status quo challenging ensures a longer and more profitable engagement).

LeSS does not have much recognition by large consultancies for the following three suspected reasons: (1) organizational design of large consultancies [themselves] is inconsistent with LeSS teaching and therefore, there are no internal success stories to share with clients; 2) consultants don’t have enough LeSS adoption knowledge to comfortably support their clients with LeSS adoptions; and 3) risk aversion, as stated above (fear to challenge radically, and therefore lose business), makes LeSS a bad choice.

Business Partnership with Tooling Companies

Today, almost any workflow management or bug tracking tool (e.g. VersionOne, Rally, VSTS/TFS, Jira, etc.) is very closely aligned (some are also strategically partnered) with SAFe. This makes SAFe adoption especially convenient, since practically any large company today has at least one of the above-mentioned tools in its arsenal, and considers them as a big part of the agile transformation journey. Practically, every tool that has the word *agile* in its name also has a module/layer(s) that could be easily mapped (configured) to a multi-layered structure of SAFe. This gives a sense of comfort to a company about its own ‘agility fitness,’ since now a company can conveniently fit its workload and organizational structure into a tool and framework. This also creates great opportunities for SAFe and tooling companies to cross-sell and cross-promote each other.

LeSS is completely silent on what tools should be used to visualize work. There are no strategic partnerships with tooling companies. The only recommendation LeSS gives is that whatever tooling is used, it should be very flat (simple) and easy to operate (e.g. no more than three levels of work decomposition; no commingling product and sprint backlogs, etc).

Framework ‘Size’ and Traditional Organizational Design

SAFe involves many people, teams, and departments. One of the main reasons why so many organizations are comfortable adopting SAFe is that it does not really challenge a status quo of first- mid-level management and traditional organizational design. In one of his early webinars, recorded with VersionOne, Dean Leffingwell clearly stated: “…We don’t typically mess with your organizational structure because that is a pretty big deal…” In SAFe, many traditional organizational layers (programs, portfolios) and roles (solutions architects, enterprise architects, various types of managers have a place to exist. SAFe provides a very comfortable environment for traditional managers; everyone has a role and some responsibilities. Notably, on a SAFe diagram, “agile teams” is illustrated at the very bottom of the SAFe overall picture, with many management layers coming over the top.

The LeSS product group consists of 2-8 teams (maximum 70 developers, assuming a maximum recommended number of developers in Scrum is nine), with a minimal number of additional roles involved (Product Owner, Scrum Masters, users, stakeholders). LeSS Huge adoptions, with hundreds to thousands of people involved have a very minimal add-on to organizational complexity in the form of [product] Requirement Areas, prioritized by Area Product Owners.

LeSS explicitly challenges traditional organizational design and calls for organization DE-scaling (flattening) as a means of scaling agility and Scrum. In LeSS, a Team of developers is the key organizational building block. In LeSS, middle and first-line managers are not required. Managers in LeSS, if remain, radically change their focus from individuals and work-assignment management to capability-building and teams’ enablement. In LeSS, programs and portfolios cease to exist. LeSS is Scrum, applied to many teams, working together on one large product, and therefore, LeSS is best to use for product-centric development, where a product centricity is really important (Note: In LeSS, a product could be a combination of software and hardware).

Team Structure and Coordination

SAFe includes various types of teams: agile teams, Kanban teams, XP teams, DevOps teams, architecture teams, etc. In practice, these are single-functional specialty teams and component teams that are inherited from traditional organizational design and, therefore, still require a lot of additional coordination, integration of work, and dependency management. As such, there is a need for release managers (e.g. Release Train Engineers), Solutions Architects, and other types of coordination managers – people that are responsible for bringing everything together.

In LeSS, all coordination between teams (each team is a cross-functional feature team) is done by teams themselves (not even Scrum Masters). Each team in LeSS is fully capable of delivering a product-centric backlog item (feature) from start to finish. In LeSS, teams are responsible for coordination and integration. Dependencies in LeSS are viewed as something highly undesirable (hard, asynchronous dependencies are viewed as a sign of organizational weakness), internal contracts (“us vs. you”) and unwillingness to work closely together – something that must be minimized in favor of close collaboration among teams. In LeSS, emphasis is made on communication through code, mentorship, community learning, and other lateral (horizontal) knowledge-sharing techniques.

Backlogs and Product Centricity

In SAFe, there are many different types of backlogs: team (private) backlogs, program backlogs, solution backlogs, portfolio backlogs, etc. – each representing a respective organizational structure (people that are compartmentalized/departmentalized in their reporting verticals, ways of working, and communication) and aligned with a specific team type at various layers of the framework (e.g. essential, program, solution, portfolio). In order to keep all backlogs in sync and relevant, there is a lot of coordination and management required.

In LeSS, there is only one Product Backlog – shared by all (2-8) teams that work on the same product, while servicing the same Product Owner. As stated above, there are no programs or portfolios in LeSS – these traditional layers of WBS management are discontinued in favor of a widened product definition. There is a lot of direct coordination between teams in LeSS (intra- and cross-teams) by team members.

Product Ownership

The SAFe Product Owner is a team member who is responsible for defining/detailing and prioritizing team backlog items (frequently, component items). The SAFe PO can support, at most, 1 to 2 teams because focusing too much on details and tactical implementation requires a lot of time. In practice, a SAFe PO is often an ex-business analyst, ex-project manager, or a tech-lead – something that works well because the majority of teams in SAFe are [technical] component teams.

The LeSS Product Owner is conceptually the same as in one-team Scrum. However, in LeSS, the PO focuses on an overall strategy and ensures maximum return on investment (ROI) in the product. The LeSS PO puts all of their focus on prioritization, whereas clarification, as much as possible, flows through users/stakeholders (see below). In practice, a LeSS PO is usually a product manager or a head of business operations (e.g. head of marketing, sales) for external product development OR an experienced, hands-on individual from one of the major user departments, who is interested in taking on the role and is political savvy for internal product development.

Proximity of Customers, Users, and Stakeholders

In SAFe, it is less likely that business people will interact directly with developers because there are specific, dedicated roles for such interaction. For example, Epic Owners (portfolio-level business people) interact directly with ART (Agile Release Team) / RTE (Release Train Engineers) and Solution Train / STE (Solution Train Engineers). Similarly, Business Owners (Essential SAFe level) that are responsible for governance and compliance also interact with ART.

In LeSS, users and stakeholders are brought in direct contact with teams, and this is clearly defined in LeSS organizational design and rules of engagement, defined during the initial (preparatory) phase of LeSS adoption (up to two months, prior to sprinting). For the most part, all clarification and details about product backlog items flow to teams directly from users and stakeholders. In LeSS, there are no individuals or teams responsible for architecture only, solutions only, or releases only – all these responsibilities reside within teams of LeSS Product Group, where all teams work on features in a customer-centric way.

Integration and Release Management

In SAFe, the System Team is responsible for the development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. It is also responsible for the integration of code produced by delivery (agile) teams. ART (Agile Release Team), spearheaded by RTE (Release Train Engineer) is responsible for releases.

In LeSS, teams (2-8 teams in LeSS Product Group) share the same Definition of Done (DoD) and are responsible for their own integration and production deployment. Teams may take turns from sprint to sprint in leading these activities while closely coordinating with other teams and cross-pollinating each other with knowledge on how to do it successfully. There are no full-time dedicated teams to handle these special activities only. If there is any work that teams are not able to complete by sprint-end, it is qualified as ‘Undone’ department work (highly undesirable) and is considered as an organizational impediment.

Conclusion

“All models are wrong, but some are useful.“ ~ George Box

It is probably impractical to debate which framework is best to use. In order to decide on the best choice, we need to understand what strategic goals and objectives an organization wants to achieve.

SAFe can provide a top-down mandatory structure and control over an existing organizational disarray without challenging significantly traditional roles, responsibilities, hierarchies (reporting and WBS), processes, and tools. Most likely, organizational complexity will not be simplified with SAFe, but it might be worth it if benefits of order outweigh the expected complexity. If an organization wants to do a major, large-scale rollout involving thousands of people at once and prefers a well-structured, change management process based on playbooks, templates, prescriptive execution, and compliance, then SAFe could be a good choice.

LeSS, just like Scrum, is based on empirical process control and continuous inspection, adaptation, and experimentation. If LeSS is adopted, with its minimal rules and guidelines, it can provide an array of deep systemic improvements, but not every company might be ready to accept them. LeSS would also require a significant change to a sphere of control by traditional roles, responsibilities, hierarchies, processes, and tools (LeSS adoption principle #1). LeSS will challenge the status quo of some people, and therefore, the success of LeSS adoption is strongly dependent on support by senior management (LeSS adoption principle #2) that must ensure job safety and career opportunities for impacted people. LeSS adoptions will not be fruitful if they are mandatory and based on compliance. Instead, LeSS adoptions require a genuine commitment and are based on volunteering (LeSS adoption principle #3). For example, the oldest, biggest, and most active global LeSS (NYC) Meetup is based on the principle of volunteering. One of the most powerful tools (also an effective coaching tool) that is used in LeSS is System Thinking – something that helps understand various aspects of organizational design (e.g. local optimization) that may not be otherwise obvious.

Looking for more topics about scaling? Check out this collection of articles and videos.

 

Gene Gendel is a Scrum Alliance Certified Enterprise Coach® (CEC®) and Certified Team Coach® (CTC®) with 15 years of experience. Gene also holds the Certified LeSS Trainer (CLT) and Certified LeSS Coach designations. He is dedicated to working with companies of various sizes and lines of business, trying to help them improve internal dynamics, organizational structure, and becoming a better place to work. Gene engages at all organizational levels: senior- and mid-level management, teams, and individuals. In his work, Gene uses various methods, tools, and techniques to amplify learning by others and to ensure that people gain autonomy after Gene "coaches himself out of the job.”

Get the Skills and Knowledge to Scale Sustainably

Scrum Alliance's scaling certification course will focus on training that is not another framework but instead explores aspects of multiple frameworks and provides practical scaling skills for any industry and companies of all sizes.

If you're interested in learning more about our newest product, Certified Agile Skills - Scaling 1, visit our product page.