Courses

Agile Scaling Frameworks comparison

What is the difference between the most popular agile scaling frameworks and models: SAFe, LeSS, and Spotify model (which doesn't exist ;))?
How do they try to solve different product development problems at the enterprise level?

This content is a part of the Certified Enterprise Agile Coaching course.
Disclaimer: There is no good or bad framework or model - they are different. Context matters.

Problem or focus

Framework/Model focus or optimization goals (authors subjective view)

SAFe

Ease to start, minimal resistance.

LeSS

Customer value and adaptiveness.

Spotify (model)

Startup culture development at scale.

Dependencies resolution (concept)

Partial dependencies elimination by reorganizing company structure into Value Streams and Agile Release Trains.

Manual dependencies resolution by introducing several types of synchronization meetings.

Eliminating dependencies by reorganizing a product development group into feature teams.

Eliminating dependencies by reorganizing product development group into feature squads,
Teams are independent in product delivery.

Dependencies resolution (practices)

Synchronization meetings:

PI Planning,
PO Sync,
Scrum of Scrums,
System Demo.

Frequent integration – System demo.

Feature teams - cross-component cross-functional product teams,
Internal open-source,
Product-level continuous integration.

Feature squads - cross-component cross-functional teams,
Eliminating system dependencies between teams by working with tribe-level dependencies backlog,
Internal open-source,
Independent delivery,
Client App Squad – a team that is focused on making teams release independently.

Common business/product goal focus

PI Planning – a planning meeting which is common for all teams and stakeholders.
PO Sync – Product Owners regular sync meeting.

One Product Backlog and Product Owner for the "whole product" – all teams work with one Product Backlog and one Product Owner.

Cross-team events:

Sprint Review,
Sprint Planning One,
Overall Product Backlog Refinement.

Spotify Rhythm.

Medium-term planning

PI Planning.

Overall and Multi-team Product Backlog Refinement.

Spotify Rhythm.

Requirements management specific

Requirements hierarchy,
Team backlogs,
Synchronization of requirements through common meetings (PO Sync, Scrum of Scrums, PI Planning, etc.).

Multi-team Product Backlog Refinement.

2-8 teams:

One Product,
One Product Backlog.

>8 teams:

Requirement Areas,
Area Product Owners,
Area Product Backlogs.

Team Product Owner,
Team Backlog,
Team is organized around customer experience.

Architecture management

Architect Runway,
Enterprise Architect,
Solution Architect,
System Architect,
Architect Sync.

Communities,
Component Mentors,
Multi-Team Design workshops (architectural).

Chief Architect,
System Owner.

Engineering practices and infrastructure maturity level *

Integration testing environment available for developers daily (System Demo).

* Not explicitly required by the framework, but it will be hard to use this framework without that level of maturity.

Strong focus on engineering practices:

Integration testing environment available for developers daily
Continuous Integration (CI),
Continuous Delivery (CD) – automated e2e tests,
Internal open-source model.

* Not explicitly required by the framework, but it will be hard to use this framework without that level of maturity.

Integration testing environment available for developers daily,
Continuous Integration (CI),
Continuous Delivery (CD) – automated e2e tests,
Teams can release independently,
Internal open-source model.

Maintaining product development process transparency

System Demo, which must be done in maximum-level of integration with other teams results,
Inspect & Adapt Workshop – common event for all teams and stakeholders at the end of the PI.

Eliminating dependencies by reorganizing a product development group into feature teams.

Eliminating dependencies by reorganizing product development group into feature squads,
Teams are independent in product delivery.

Budgeting

Budgeting unit - a Value Stream or an Epic.

Practices:

Lean Budgeting.

Budgeting unit - a product development group.

Budgeting unit - a Tribe.

Practices:

Spotify Rhythm.

Organizational structure

Hierarchy.

Flat structure - PO and teams are at the same level of the organizational hierarchy. They report to the head of the product management group.

Flat structure - there are only two hierarchy levels in the product development group: Tribe Leader, teams.

Team structure

Component or feature teams.

The majority of the teams are customer-focused feature teams.

The majority of the teams are customer-focused feature squads.

Each tribe has two special teams:

Client App Squad,
Infrastructure Squad.

Teams design guidelines

The SAFe Value Stream and ART identification Workshop
Teams self-selection workshop,
Teams self-design workshop.

Teams self-design workshop is recommended.

N/A

Product development synchronization

Synchronization meetings::

Scrum of Scrums,
PO Sync,
System Demo,
I&A.

Communities.

Teams are mostly independent.

Common meetings:

Overall Sprint Planning,
Overall Product Backlog Refinement.

Recommended practices:

Scouts,
Travellers.

Not recommended practices:

Scrum of scrums.

Chapters (competences formal community),
Guilds (problem/solution informal community).

Trio (alliance):

Tribe Lead,
Design lead,
Product Area Lead.

Cross education and learning

Centers Of Excellence,
Communities of Practices.

Component mentors,
Communities.

Chapters (competences formal community),
Guilds (problem/solution informal community).

Org-level continuous Improvement

I&A (once a PI).

Overall Sprint Retrospective (once per sprint).

Tribe-level Dependency Backlog (regular work to minimize system dependencies between teams).

Official website

scaledagileframework.com

less.works

N/A

Download PDF

This content is a part of the Certified Enterprise Agile Coaching course.