SlideShare a Scribd company logo
SAFe and LeSS
Different solutions to the
challenge
of scaling Scrum
Stanisław Matczak,
SAFe @Space conference, 2018.11.06
The starting point
Our company develops IT system.
Our system is large and is developed by hundreds persons.
We introduced Scrum in team X or area Y – and it worked very well 
What we can do to be agile for development of big system – not only on team
level?
A framework!
Answers for the questions (i.e. „how many POs do we need?”)
Good and proven practices
Some frameworks for scaling Scrum
• 1995 – Scrum is presented on OOPSLA conference
• 2001 – Agile Manifesto
• 2010 – Scrum Guide (first edition)
• 2011 – Scaled Agile Framework
http://www.scaledagileframework.com
• 2012 – Disciplined Agile (DA)
http://www.disciplinedagiledelivery.com
• 2014 – LeSS (Large-Scale Scrum)
https://less.works
• 2015 – Nexus
https://www.scrum.org/resources/nexus-guide
• 2018 – Scrum@Scale
https://www.scrumatscale.com
The frameworks
4 layers
4 configurations
LeSS (up to 8 teams)
LeSS Huge
SAFe & LeSS – what is similar?
Scrum inside
Bigger unit over Scrum Team: ART (SAFe) or Requirement Area (LeSS)
Include CI / CD
Synchronized sprints
Let’s talk about differences
Difference 1 – scope of the framework
From single team to Enterprise From single team to set of teams that
build common product
Ask yourself...
What scope of the framework do I really need?
Do I want to use the framework to organize my company?
Do I want to use the framework to organize development my product?
Difference 2 – number of elements
Over 80 elements About 20 elements
„barely sufficient framework”
Ask yourself...
Do I want tailor down or extend the framework?
What is maturity of my organization?
What is risk of leaving not redundand elements in my organization?
Difference 3 – backlogs
Program Backlog
Team Backlogs
LeSS: one common Product Backlog
LeSS Huge:
- Product Backlog
- Requirement Area Backlogs
Ask yourself...
How much effort is needed for maintaining common backlog for several teams?
How does work on Team Backlog affect moving between the teams?
How does work on Team Backlog affect understanding of whole system?
What tool is needed for maintaining Program Backlog and many Team backlogs?
How much effort is needed for maintaining Program Backlog and many Team
backlogs?
Difference 4 – number of Product Owners
Product Owner per 1-2 teams Product Owner per 1-8 teams
(Requirement Area)
Ask yourself...
What is accessibility of Product Owners to team members?
What is the need of synchronization between Product Owners?
What is the risk of making local optimizations?
Difference 5 – cadences
Cadences No Cadences
Ask yourself...
How to organize long-term planning with cadences?
How to organize long-term planning without candences?
What is the risk of staying at „we deploy ate end of cadence” approach?
What is the cost of changing the direction in the middle of the candence?
Difference 6 – System Team
There is System Team at ART level or
at Solution Train level (or both).
No support groups such as
configuration management,
continuous integration support, or
“quality and process”.
The System Team’s primary responsibilities are:
• Building Development Infrastructure
• System Integration
• End-to-End and Solution Performance Testing
• System and Solution Demos
• Release
Ask yourself...
Do we believe we can spread all the function over Development Teams?
Which setup is easier to create?
What is needed maturity level in both models?
What is the risk of bottlenecks in both models?
What is the risk of blaming game („it’s not my responsibility”) in both models?
Difference 7 – components vs feature teams
„To ensure highest feature
throughput, SAFe generally
recommends a mix of perhaps 75-
80% feature teams and 20-25%
component teams”
Strong emphasis on feature teams
Ask yourself...
Do we believe that we can have features teams only?
Can we have shared code ownership?
What is the impact of the setup to number of dependencies?
What is the impact of the setup to Time-To-Market?
Difference 8 – co-location
Co-location is desirable, but not
mandatory.
Co-location is required.
Team-based LeSS organization has the following structure:
• Dedicated teams – Each team member is dedicated for 100%
of his time to one and only one Team
• Cross-functional teams – Each team contains all functional
skills needed to produce a shippable product.
• Co-located teams – Each team is co-located in the same
room.
• Long-lived teams – A Team stays together ‘forever.’
(...) If at all possible, teams are collocated to facilitate hourly
and daily communication. (...)
Ask yourself...
What is the cost of creation co-located team?
What is the cost of working in distributed team?
Difference 9 – role of managers
A lot of responsibilities... „Managers are capacity builders.”
• Understand customer needs and validate solutions
• Understand and support portfolio work
• Develop and communicate the program vision and roadmap
• Manage and prioritize the flow of work
• Participate in PI planning
• Define releases and program increments
• Work with System Architect/Engineering to understand
Enabler work
• Participate in demos and Inspect and Adapt (I&A)
• Build an effective Product Manager/Product Owner team
Ask yourself...
Which model is closer to my expectation about manager’s role?
What is impact of the model to self-organization of the team?
What is maturity level of the team in my organization?
Difference 10 – the place of Scrum
The upper layer for merging work of
many Scrum teams
One Scrum for many teams
Ask yourself...
Do we want to have coordination layer above Development Teams or as part of
Development Teams?
The bonus difference – trainings and badges
...plus 3 BETA Courses
• SAFe for Government
• SAFe Agile Software Engineering
• SAFE System and Solution Architect
Certified LeSS Practitioner:
Principles to Practices
Certified LeSS for Executives:
Principles, Organization, and
Change
Certified LeSS Basics: Short one-
day Teaser to LeSS
Ask yourself...
How important is accessibility of the trainings and consultants?
As the summary...
Frameworks are different.
It’s good to know more than one framework.
Let’s use the differences as opportunity to ask the questions and develop our
organizations!
“There are no such things as best practices. There are only practices that are good
within a certain context”

More Related Content

10 differences between SAFe and LeSS

  • 1. SAFe and LeSS Different solutions to the challenge of scaling Scrum Stanisław Matczak, SAFe @Space conference, 2018.11.06
  • 2. The starting point Our company develops IT system. Our system is large and is developed by hundreds persons. We introduced Scrum in team X or area Y – and it worked very well  What we can do to be agile for development of big system – not only on team level? A framework! Answers for the questions (i.e. „how many POs do we need?”) Good and proven practices
  • 3. Some frameworks for scaling Scrum • 1995 – Scrum is presented on OOPSLA conference • 2001 – Agile Manifesto • 2010 – Scrum Guide (first edition) • 2011 – Scaled Agile Framework http://www.scaledagileframework.com • 2012 – Disciplined Agile (DA) http://www.disciplinedagiledelivery.com • 2014 – LeSS (Large-Scale Scrum) https://less.works • 2015 – Nexus https://www.scrum.org/resources/nexus-guide • 2018 – Scrum@Scale https://www.scrumatscale.com
  • 4. The frameworks 4 layers 4 configurations LeSS (up to 8 teams) LeSS Huge
  • 5. SAFe & LeSS – what is similar? Scrum inside Bigger unit over Scrum Team: ART (SAFe) or Requirement Area (LeSS) Include CI / CD Synchronized sprints
  • 6. Let’s talk about differences
  • 7. Difference 1 – scope of the framework From single team to Enterprise From single team to set of teams that build common product
  • 8. Ask yourself... What scope of the framework do I really need? Do I want to use the framework to organize my company? Do I want to use the framework to organize development my product?
  • 9. Difference 2 – number of elements Over 80 elements About 20 elements „barely sufficient framework”
  • 10. Ask yourself... Do I want tailor down or extend the framework? What is maturity of my organization? What is risk of leaving not redundand elements in my organization?
  • 11. Difference 3 – backlogs Program Backlog Team Backlogs LeSS: one common Product Backlog LeSS Huge: - Product Backlog - Requirement Area Backlogs
  • 12. Ask yourself... How much effort is needed for maintaining common backlog for several teams? How does work on Team Backlog affect moving between the teams? How does work on Team Backlog affect understanding of whole system? What tool is needed for maintaining Program Backlog and many Team backlogs? How much effort is needed for maintaining Program Backlog and many Team backlogs?
  • 13. Difference 4 – number of Product Owners Product Owner per 1-2 teams Product Owner per 1-8 teams (Requirement Area)
  • 14. Ask yourself... What is accessibility of Product Owners to team members? What is the need of synchronization between Product Owners? What is the risk of making local optimizations?
  • 15. Difference 5 – cadences Cadences No Cadences
  • 16. Ask yourself... How to organize long-term planning with cadences? How to organize long-term planning without candences? What is the risk of staying at „we deploy ate end of cadence” approach? What is the cost of changing the direction in the middle of the candence?
  • 17. Difference 6 – System Team There is System Team at ART level or at Solution Train level (or both). No support groups such as configuration management, continuous integration support, or “quality and process”. The System Team’s primary responsibilities are: • Building Development Infrastructure • System Integration • End-to-End and Solution Performance Testing • System and Solution Demos • Release
  • 18. Ask yourself... Do we believe we can spread all the function over Development Teams? Which setup is easier to create? What is needed maturity level in both models? What is the risk of bottlenecks in both models? What is the risk of blaming game („it’s not my responsibility”) in both models?
  • 19. Difference 7 – components vs feature teams „To ensure highest feature throughput, SAFe generally recommends a mix of perhaps 75- 80% feature teams and 20-25% component teams” Strong emphasis on feature teams
  • 20. Ask yourself... Do we believe that we can have features teams only? Can we have shared code ownership? What is the impact of the setup to number of dependencies? What is the impact of the setup to Time-To-Market?
  • 21. Difference 8 – co-location Co-location is desirable, but not mandatory. Co-location is required. Team-based LeSS organization has the following structure: • Dedicated teams – Each team member is dedicated for 100% of his time to one and only one Team • Cross-functional teams – Each team contains all functional skills needed to produce a shippable product. • Co-located teams – Each team is co-located in the same room. • Long-lived teams – A Team stays together ‘forever.’ (...) If at all possible, teams are collocated to facilitate hourly and daily communication. (...)
  • 22. Ask yourself... What is the cost of creation co-located team? What is the cost of working in distributed team?
  • 23. Difference 9 – role of managers A lot of responsibilities... „Managers are capacity builders.” • Understand customer needs and validate solutions • Understand and support portfolio work • Develop and communicate the program vision and roadmap • Manage and prioritize the flow of work • Participate in PI planning • Define releases and program increments • Work with System Architect/Engineering to understand Enabler work • Participate in demos and Inspect and Adapt (I&A) • Build an effective Product Manager/Product Owner team
  • 24. Ask yourself... Which model is closer to my expectation about manager’s role? What is impact of the model to self-organization of the team? What is maturity level of the team in my organization?
  • 25. Difference 10 – the place of Scrum The upper layer for merging work of many Scrum teams One Scrum for many teams
  • 26. Ask yourself... Do we want to have coordination layer above Development Teams or as part of Development Teams?
  • 27. The bonus difference – trainings and badges ...plus 3 BETA Courses • SAFe for Government • SAFe Agile Software Engineering • SAFE System and Solution Architect Certified LeSS Practitioner: Principles to Practices Certified LeSS for Executives: Principles, Organization, and Change Certified LeSS Basics: Short one- day Teaser to LeSS
  • 28. Ask yourself... How important is accessibility of the trainings and consultants?
  • 29. As the summary... Frameworks are different. It’s good to know more than one framework. Let’s use the differences as opportunity to ask the questions and develop our organizations! “There are no such things as best practices. There are only practices that are good within a certain context”