SAFe vs LeSS vs DaD: Comparing the Three Frameworks to Scale Agile

Oct 9, 2019 6:16:00 PM

SAFe vs LeSS vs DaD

Software development methodologies have come a long way. From Spiral to Waterfall to Agile, there is a significant shift in team roles, ceremonies, planning, and delivery activities. 

And if we talk about the pace at which software applications are brought to market these days, Agile seems to have made an impact and is considered the most relevant approach to manage the SDLC cycle. 

Further, Agile frameworks like Scrum, Kanban enable specific teams to plan, manage, and deliver software on time. At a team level, these Agile frameworks have a history of success. But when it comes to adopting them for multiple teams at an enterprise level, these approaches need to scale up. This is where Agile scaling frameworks (LeSS, SAFe, DaD) come into the picture.

Amongst these three scaling frameworks, SAFe (Scaled Agile Framework) is the one that can extend to the best possible level, while strictly maintaining the Agile principles. The later segment discusses all three frameworks in detail and compares them to understand the basic differences between SAFe vs LeSS vs DaD.

Scaling Agile Frameworks: What are they and How do they Work? 

Let’s start by understanding the purpose of scaling an Agile Framework.

Consider this. Your team (say 2 scrum teams with 7 members each) is developing a software product. Developers, product owners, and scrum masters collaborate through daily scrum (stand-up) to ensure on-time delivery of the project. It’s a simple case of small-scale product development using Scrum methodology. Here, the teams work at a single geo-location, can manage dependencies by collaborating, and ensure a seamless integration.

Now, think of a large-scale product, wherein 10 scrum teams of 6-9 members each are working (2 of them from a different geographical area). Every team has developers, a product owner, a scrum master, and other engineers working to deliver high-quality releases. Each team, in this case, will be following the scrum methodology to plan, manage, and deliver part of the solution. But, there will be a challenge when they have to collaborate to discuss blockers, delays, early completion, integrations, dependencies, and more.

In this case, the Agile teams look beyond day planning, iterations, and release. They also involve product and portfolio planning, which somehow makes management of the SDLC cycle complex. The Agile model, in such a case, will look something like this: 

large scale solutionsLarge-Scale Solutions: Example

To deal with such scenarios, Scrum of Scrums is considered as a solution by many. Scrum of Scrums is a multi-team standup wherein scrum masters and product owners meet to keep the rest of the team abreast about important issues across the portfolio. It’s not a status meeting nor is it a meeting for iteration planning or discussing Agile processes.

However, this Scrum of Scrums meeting does not define ideal practices to make teams collaborate and deliver a quality release. This is when frameworks to scale Agile are needed (LeSS, DaD, SaFe). 

Scaling Agile at Organizational Level: SAFe vs LeSS vs DaD

Scaled Agile Framework (SAFe)

SAFe is one of the leading frameworks for scaling Agile at the enterprise-level. It follows lean-Agile principles to help businesses continuously and efficiently deliver value on a regular and estimated schedule. 

SAFe provides guidance at all levels of software development: Team, Program, LargeScale Solution (Value Stream), and Portfolio, so as to align enterprise-level strategies with the team working on a solution. Here is how it manages development agility at the enterprise level. 

Scaled Agile Framework Diagram

Scaled Agile Framework (SAFe) Levels

In a general Agile framework, there is a Scrum and Kanban team that comprises a development team, scrum master, and product owner. Such a framework works when there are 2-3 teams with 5-9 team members.

When the number of teams extends (say there are 10 teams), a single product owner and a scrum master for a team are not sufficient enough to manage requirements and facilitate the teams. To handle multiple teams at a larger scale, there is a program layer in the SAFe framework. The program layer has roles like Product Manager who provides guidelines to all the product owners working for individual teams. Then, there are Release Train Engineers who act like chief impediment officers for all the teams. A System Architect defines, communicates, and shares an architectural and technical vision for the Agile Release Train (ART).

Agile Release Team (ART) is a name given to multiple development teams at the program level. These teams deliver their work incrementally in 8-12 weeks long sprints. This time box during an Agile Release Train is called Program Increment (PI).    

At a large stream level, there is a value stream engineer to manage Agile Release Trains (ARTs), a Solution Manager to define vision and roadmap for the solution, and a Solution Architect for the technical and architectural vision of the solution under development.

Moving up, at the portfolio level there are epic owners and enterprise architects who define the base for a portfolio of solutions. For this, a Portfolio Kanban is used that defines an MVP of the solution, a lean business case, and starts implementation on approval. An enterprise architect works across value streams and programs to help provide the strategic technical direction that can optimize portfolio outcomes. The enterprise architect often may act as an epic owner for enabler epics.

SAFe is a prescriptive framework. It organizes and structures how software development activities should be performed and in what order. The SAFe framework can be adopted for large scale projects that have at least 50-125 team members in it. 

Large Scale Scrum (LeSS)

LeSS is a scaled version of a one-team Scrum, which focuses on directing the attention of all the teams towards the product. It maintains basic practices of Scrum but has some basic differences from regular Scrum meetings: 

  • There is a product backlog, but for the product and not for the team 
  • There is only one Definition of Done for all the teams 
  • All teams are in a common sprint to deliver a common shippable product

Each sprint starts with Sprint Planning1 wherein team members along with the product owner divides their product backlog items. This is followed by Sprint Planning2 wherein the team discusses their strategies for feature development. Each self-managing team develops the features that they selected and coordinates with other teams for integrating their potentially shippable product increment altogether.

In LeSS, coordination amongst the teams is the responsibility of the teams itself and there are no assigned coordinators for it (like we have in the case of SAFe). These teams coordinate through scrum meetings which include product owners, scrum masters, and rotating representatives from each team.


Once there is an increment by teams, a shared session amongst the teams happens where teams and customers explore what is done and discuss the next increment to develop. This session is called the Sprint Review. After this, each team retrospects its product increment, followed by an overall retrospection session where teams, scrum masters, product owners, and managers determine any impediments that affect the delivery of the product.

Depending upon how large the team is, there are two LeSS frameworks available for adoption: 

  1. LeSS: Up to eight teams (of eight members each)
  2. LeSS Huge: Up to a few thousand members on one product

Disciplined Agile Delivery (DaD)

Scrum defines the most efficient strategies for leading Agile teams. However, it is only a part of what’s needed to build a complete, scalable solution. The Disciplined Agile Delivery (DaD) framework works around the gaps that Scrum has in Agile solution delivery.

DaD is a hybrid approach to software development that extends the strategies from various Agile frameworks- Kanban, LeSS, Lean development, Extreme Programming, Agile Modeling, etc. 

Unlike Scrum, which is a prescriptive approach to software development, DaD is a goal-driven approach. DaD provides contextual advice regarding viable alternatives and trade-offs that address the different situations and problems one may find himself in. By describing what works, what doesn’t, and why, Disciplined Agile Delivery increases the possibility of adopting strategies that will work to deal with a situation.

There are 10 roles that a DaD project has. While five of them are primary, five are secondary. The primary roles will occur, regardless of the scale that a project has; while the secondary roles are added to the primary roles as the demand or scalability expands.

  1. DaD roles

Disciplined Agile Delivery Roles 

The reason why the number of members in a Scrum and DaD varies is the difference in scope that both the frameworks handle. Scrum has its focus on leadership and change management while DaD focuses on the entire delivery lifecycle. Thus, with a larger scope, there are more roles in DaD.

SAFe vs LeSS vs DaD: Which one to Choose? 

SAFe would be my first choice. With its training academy, licensed trainers, and traditional management-friendly approach, it is clearly resonating well and is poised to do well in the market.

Today, DaD has more trainers than SAFe, but hardly anyone has actually taken the course, so is it really resonating with the market? The other question I have is whether its practitioners have really left their RUP days behind them. Do they really believe their newfound values? However, given the choice between SAFe and DaD, I would clearly choose DaD, especially if your coaches really understand Agile and the values it represents.

For small scale products, Scrum and Kanban are the most efficient models for managing software development. Agile scaling is nothing but utilizing these basic Agile frameworks to handle large-scale product development.

The three Agile scaling frameworks- SAFe, LeSS, and DaD can be chosen according to a number of factors: team size, the rigidity of rules or structure followed for development, product scalability, solution complexity, time-to-market, and more. 

Archna Oberoi

Written by Archna Oberoi

Content strategist by profession and blogger by passion, Archna is avid about updating herself with the freshest dose of technology and sharing them with the readers. Stay tuned here as she brings some trending stories from the tech-territory of mobile and web.