Comparing the LeSS and SAFe frameworks

Now agile project management is gaining traction and more and more teams are considering it as the new default, companies are looking to the horizon in search of a new frontier. For many of our clients, the next challenge for iterative development lies in scaling agile – moving from agile as a way of working for a single team, to a way of working for an entire department, collaborating within an ecosystem of other departments. Several frameworks have emerged to describe a cure, most notable are the Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS). But which framework should you choose – what are each framework’s positives and negatives? Are they alike, complementary, or do they propose something entirely different?

Describing the SAFe and LeSS frameworks


To start discussing the complexity of both frameworks, the style and attitude portrayed by each framework’s website say more than words ever could: the LeSS website uses colourful free-form drawings to explain its workings, while the SAFe website is more reminiscent of technical drawings used in engineering. The tone is set: judging by their presentation, you would assume the SAFe framework relies a lot more on structure and processes than LeSS.

And you would be right – as its acronym implies, LeSS is a framework that deliberately strives for simplicity and ease of understanding. In fact, LeSS offers controversial advice for anyone with the ambition to scale agile development: don’t scale – but if you have to, use LeSS. They posit that smaller, co-located teams creating products together are more successful than enormous software products involving hundreds of resources. Admittedly, we can all name at least one mastodont of a software project that failed miserably – so there may be some truth to this.

The SAFe framework is much less adventurous than LeSS and tries to describe an all-encompassing solution to scaling agile. However, dependent on the size of the organization, only specific levels of SAFe’s multi-level approach can be implemented. The Team and Programme level, for instance, make for a good starting point for most organizations. Speaking of the Programme level, a key difference between SAFe and LeSS is that SAFe actually has programme management processes and roles built-in. An area in which LeSS is clearly lacking.

Team roles

In line with its principle of simplicity, LeSS involves the roles of Product Owner, Scrum Master and Team – the traditional scrum roles. SAFe describes more roles and assigns different responsibilities to each role when compared to LeSS.

For instance, SAFe favours the traditional Product Owner role for representing the end user perspective. In LeSS, the team is encouraged to interact directly with end users, hence bypassing this traditional Product Owner role.  The Product Owner in LeSS, now with more time on his hands for other tasks, is burdened with managing project priorities and project scope for multiple teams. Similar responsibilities lie with the Program Manager in SAFe.

Organisational structure

As far as aligning organizations with the frameworks, LeSS is much more an advocate of re-aligning an entire structure to fit a simplified model supporting the agile way of working. For up to eight teams, LeSS prescribes three supporting teams:  the Product Owner team, the Undone Department, and the Head of Product Group. All the teams, the Undone Department and Product Owner team are on the same level within the hierarchy, and all are managed by the Head of Product Group – the hierarchy is essentially flat.

There are no separate silos for development, testing and other disciplines – every team is supposed to carry the full weight of delivering the end-product to the end-user, throughout the entire software development lifecycle. Teams need to have a range of skillsets on board, and maturing teams can be hard as the team member not only need to be more self-reliant in their roles but also need to align with the other members within the team to ensure smooth work transitions smoothly from one team member to the next.

We all know that team development is no easy feat – developing a well-oiled team takes multiple years and in that timespan, external issues and team churn definitely don’t help in achieving team formation. The Undone Department is LeSS’s solution to this problem: the Undone Department basically accounts for all skills not yet available or fully mastered within each of the agile teams – coming to each team’s aid for specific tasks or issues. As each team matures, the roles fulfilled by the Undone Department will slowly diminish as they’re integrated into the teams themselves.

SAFe doesn’t emphasize on organizational change to fit its model and allows for much more leniency for incumbent organisations that want to adopt the framework. LeSS emphasizes organizational change and aligning structure so much because it posits that culture follows organizational structure.

Sprint planning

SAFE groups several sprints in a so-called programme increment. While each sprint has the objective of finishing work committed, only at the end of the programme increment are teams expected to deliver end results to market. Releases in the middle of a PI remain an option for features that are finished early.

A programme increment is planned during a two-day session at the beginning of the increment, and each sprint is planned at the beginning of the sprint – no real surprises there. What makes SAFe compelling though, is the fact that all teams work together during programme increment planning sessions – SAFe uses a concept called agile release trains (ARTs), where multiple teams commit to delivering a specific set of features. Just as sprint plannings, retrospectives are also elevated to a larger scale at the end of each increment.

In LeSS, both sprint planning and retrospectives occur in two stages. For planning, the first stage involves each team delegating two representatives that will help decide what backlog items each time will take up. The second stage is not unlike a normal sprint planning,  where all team members are now involved and are able to provide input or feedback.

For the retrospective, the two-stage approach involves an initial scrum-like meeting, followed by a report-out of progress made from the product perspective.

Deciding on a strategy to scale

LeSS versus SAFe

The choice for a framework to implement will obviously be heavily influenced by decision makers an organisation, although we can make an educated guess as so what framework is likely to be preferred based on the type of organisation doing the assessment.

For smaller, flexible organisations looking for a more radical solution, LeSS is probably the best fit. It’s simple to understand from the roots up, and provides a direct approach to implementing large-scale agile development. LeSS is simple and direct, but deliberately leaves gaps in its approach that organizations are meant to fill in themselves – applying creativity to adapt the framework to the working context of the organisation. This creates a certain level of uncertainty, as businesses will have to accept that embracing LeSS will, initially at least, also mean embracing the unknown.

SAFe, on the other hand, is much more about incremental change and provides a rich framework that allows existing organisations to tailor their processes in a quest to align with whatever SAFe prescribes. The framework tries to describe an end-to-end solution to scaling agile, covering all bases and creating a lot more certainty for organisations willing to make the jump. The terms and methods applied are reminiscent of traditional project management methods, and are supposedly easier to understand by top management.

Fear of losing performance and uncertainty avoidance might make larger organisations shy away from radical approaches, which makes SAFe the preferred candidate. If uncertainty and radical change are no issue, LeSS can be a good alternative.


In closing, let’s reframe the discussion with the knowledge that implementing a framework is never the goal – changing the way we deliver projects is. From this perspective, the nature of your organisation will strongly dictate which framework is more aligned from the get-go: in case you work in a more fluid organisational structure, where direct approaches are encouraged and simplicity is key – LeSS is likely to be a good starting point for scaling your agile workflow. The approach appears to be ideal for smaller agile organisations that are growing and want to scale up.

SAFe, on the other hand, is ideal if your incumbent organisation already has lots of processes in place, and wants to start implementing agile in a (presumably larger) organisational structure. Your mileage may vary with both approaches, however – and this article is only a brief comparison of both frameworks. Please visit either framework’s website for more in-depth explanations of all processes.