This presentation is a summary of analysis between the popular large scale agile frameworks SAFe, LeSS and DAD.

1. Large-scale Agile Frameworks
A COMPARATIVE ANALYSIS

2. Table of Contents
 Large- scale Agile: An overview
 What are the available scaling frameworks?
 The Less SAFe DAD: An introduction
 How do they differ?
 Any similarities?
 Which one should you choose?
 Appendix

3. Large-scale Agile: An overview

4. The Golden Circle of What, Why & How
What is it?
Application of Agile practices across an entire
organization can be termed as large scale
Agile.
Why is it?
The need for businesses to respond quickly
to changing market is forcing them to bring
agility at its core.
How to do it?
Several large-scale agile frameworks
available in the market can help
organizations achieve the goal.

5. What are the available frameworks?

6. Most popular ones….
*
*
*
* In scope for details in further slides.

7. The LeSS SAFe DAD

8. Large-scale Scrum
• Conceptualized by Bas Vodde & Craig Larman in 2013.
• Extends Scrum with scaling rules and guidelines without losing its original purpose.
• Idea is to solve organizational complexity in simpler ways with less roles, less
management, and less structures.
• More with Less is the mantra, meaning a less defined process leads to more situational
learning.
• Pros: Considered to be the most easily adaptable Agile scaling method. Teams already
doing Scrum will view this practice as natural and familiar.
• Cons: The least prescriptive method which leaves gaps for organizations to fill in.
1

9. Scaled Agile Framework
• Latest version 5.0 was released in 2019.
• Application of lean-agile practices at enterprise level.
• Designed to meet the needs of all stakeholders in an organization while promoting
transparency at all levels.
• Bringing in business agility is the mantra with a focus to help organizations respond
quickly to changing market conditions.
• Pros: Involves all levels in an organization while promoting collaboration across
horizontal well as vertical structures.
• Cons: Can be criticized as being overly prescriptive. In the pressure of delivery,
hardening sprint is sometimes considered wasteful.
2

10. Disciplined Agile (Delivery)
• Latest version 4.0 was released in 2018.
• Promoted by PMI since 2019.
• Extends the development-focused lifecycle of Scrum to address the full, end-to-end
delivery lifecycle.
• Agile teams should build their own processes, therefore Choose your WoW (Ways of
working) is the mantra.
• Pros: Focus on architecture and design may lead to building a better and scalable
product.
• Cons: This approach has less market share as compared to others. Therefore, it may not
be very easy to find assistance and training for specialized roles.
3

11. How do they differ?

12. Core Principles
1

13. Core Principles
1
4
3
2
1
2
1
3
4
Close matches
Emphasis on different things

14. Configuration options
2
LeSS:
Suitable for 2-8 teams.
LeSS Huge:
Suitable for 8+ teams.
Applying lean strategies is team’s responsibility. No
recommendation on investment and governance.
No recommendation for enterprise-level agile.
Essential SAFe:
Includes team and program level. Suitable for
one ART and one solution.
Large Solution SAFe:
Allows for coordination across multiple
programs. Suitable for more than one ART and
one solution.
Portfolio SAFe:
Incorporates strategic direction, investment
funding and lean governance.
Full SAFe:
Combines all the three levels.
Disciplined Agile Delivery (DAD):
Addresses all aspects of solution delivery.
Disciplined DevOps:
Attempts to streamline deployment activities.
Covers the aspect of team & scaled agile in DAD only.
Disciplined Agile IT (DAIT):
Applies agile and lean strategies to portfolio management
and IT governance.
Disciplined Agile Enterprise (DAE):
Caters to bringing in agile-friendly organizational structure
and culture.

15. Prescribed roles: Team Level
3
Area Product Owner:
Prioritizes items in the backlog. However, the
clarification of items is done directly between team
and customers. One Product Owner takes care of 1-8
teams.
Scrum Master:
Assists the team in meeting delivery goals. Must be a
dedicated role for one team.
Development Team:
Responsible for providing value to business.
Stakeholders are not dedicated part of any team, but
the team clarifies detailed requirements with them
only.
Product Owner:
Prioritizes and clarifies items in backlog. One
PO can be shared between 1-2 teams.
Scrum Master:
Assists the team in meeting delivery goals. Can
be a shared role across teams.
Agile Team:
Responsible for providing value to business.
Product Owner takes care of clarifying
requirements.
Product Owner:
Prioritizes and clarifies items in backlog. Must be a
dedicated role for one team.
Architecture Owner/Team Leader:
Owns architecture decisions for the team. This person is
usually the senior most developer of the team and can
additionally play the role of Scrum master. Recommended
to be a dedicated role for one team.
Team:
Responsible for providing value to business.
Stakeholders:
Ensures that the solution being developed meets needs.
Could be anyone from business.

16. Prescribed roles: Program Level
4
Product Owner:
Overviews the overall direction of product along with
Area Product Owners.
Undone Department:
Focuses on building and testing the entire system end
to end.
Teams, supported by communities of practice, are
responsible for building the right architecture.
Line Manager:
Focuses on the whole and help teams build great
products.
Product Management:
Responsible for defining and supporting
building of a desirable product.
Release Train Engineer:
Facilitates program level events and assists
teams in delivering value.
System & Enterprise Architect:
Defines and communications a technical vision
for group of teams.
Lean Portfolio Management:
Aligns strategy and execution by applying Lean
and systems thinking approaches.
Domain Expert/Subject Matter Expert:
Responsible for explaining the vision and clarifying high-
level requirements.
Independent Testers & Integrators:
Focuses on building and testing the entire system end to
end.
Technical Expert:
Guides the teams and works on enterprise-level architect
concerns.
Specialists:
Could be a program manager who coordinates with other
teams via team leads.

17. Ceremonies: Program Level
5
Sprint Planning (part 1):
Frequency: Once in every sprint.
Duration: 2 hours for a 2-week sprint.
Attended by: Representatives of all dev teams &
Product Owners.
Purpose: PO highlights high-priority items and teams
pick what they will work on.
Backlog Refinement Meeting:
Frequency: Once/twice in a week.
Duration: 1 hour for a 2-week sprint.
Attended by: Representatives of all dev teams &
Product Owners.
Purpose: PO highlights high-priority items and teams
pick what they will work on.
PI Planning:
Frequency: Once in every Program Increment.
Duration: 2 full days.
Attended by: All development teams,
stakeholders, Product & Program Managers.
Purpose: Stakeholders highlights high-priority
items and teams pick what they will work on.
Refinement of items happens during PI Planning
only.
Supports both approaches.
Supports both approaches.

18. Ceremonies: Program Level (Contd.)
5
Review Bazaar:
Frequency: No recommendation.
Duration: No recommendation.
Attended by: Representatives of all dev teams, Product
Owners and stakeholders.
Purpose: Items developed are explored with users.
Demos are avoided with the notion that they don’t
engage users.
Overall Retrospective:
Frequency: Once in every sprint
Duration: 1.5 hours.
Attended by: Representatives of all dev teams &
Product Owners
Purpose: PO highlights high-priority items and teams
pick what they will work on.
Product Owner Sync:
Frequency: Once in every sprint.
Duration: 1 hour for a 2-week sprint.
Attended by: All development teams,
stakeholders, Product & Program Managers.
Purpose: Functionalities developed are demoed
to stakeholders.
Scrum Master Sync:
Frequency: Once in every Program Increment
Duration: No recommendation.
Attended by: All development teams,
stakeholders, Product & Program Managers.
Purpose: Focus on gathering feedback and
improving the process.
Supports both approaches.
Supports both approaches.

19. Ceremonies: Program Level (Contd.)
5
No special meeting suggested.
Scrum of Scrums:
Frequency: 2-3 times every week.
Duration: 1 hour.
Attended by: RTE and Scrum Masters.
Purpose: Review progress towards milestones and
remove inter-team dependencies.
Product Owner Sync:
Frequency: Once every week.
Duration: 1 hour.
Attended by: Product Owners & Program
Managers.
Purpose: Track progress towards vision on the
program level.
Scrum of Scrums:
Frequency: Once every week.
Duration: 1 hour.
Attended by: RTE and Scrum Masters.
Purpose: Review progress towards milestones
and remove inter-team dependencies.
Supports both approaches.
Supports both approaches.

20. Ceremonies: Team Level
6
Sprint Planning (part 1):
Team-level planning of functionalities that need to be
delivered. Multiple teams with related deliverables can
do this meeting together too.
Daily Scrum:
Collaborating with everyone on the team to ensure
team is on track. Might invite participants from other
teams too.
Team Retrospective:
Focus is on improving the process and collect
feedback for Overall Retrospective meeting conducted
immediately after.
Sprint Demo:
Teams showcase their deliverables.
Sprint Planning:
Team-level planning of functionalities that
need to be delivered.
Daily Scrum:
Collaborating with everyone on the team to
ensure team is on track. Recommended for
team members only.
Sprint Retrospective:
Focus is on improving the process at team
level.
Sprint Demo:
Teams showcase their deliverables.
Supports both approaches.
Supports both approaches.
Supports both approaches.
Supports both approaches.

21. Requirement gathering & refinement
7
Customer interaction:
Product Owner prioritizes, and teams work directly
with the stakeholders to get details on requirements.
Backlog Management:
One central product backlog for all teams.
Also, each team has its individual sprint backlog. No
team-specific backlog exists.
Prioritization techniques:
No guidance.
Customer interaction:
Product Owner prioritizes and works directly
with the team. He/she is also responsible for
getting further details from Product Manager.
Backlog Management:
One central product backlog for all teams.
Also, each team has its individual team and
sprint backlog as well.
Prioritization techniques:
Weighted Shortest Job First (WSFJ) is
recommended for backlog prioritization.
Customer interaction:
Product Owner prioritizes and works directly with the team.
He/she is also responsible for representing the needs of
stakeholder community.
Backlog Management:
One core Requirements Backlog plus Formal Change
Management Log exists for all teams. Eech team has its own
Work Item List and Work Item Pool.
Prioritization techniques:
Supports prioritization via business value, risk, cost of delay,
WSJF, operational emergency and dependency.

22. Development cycle
8
Methodology:
Scrum, XP
Process:
For smaller teams (2-8): PO defines user stories and
adds them to Product Backlog. Every sprint, teams
conduct a multi-team sprint planning to pick items
from backlog. Regular scrum meetings help them to
track sprint goals.
For larger teams (8+): Teams are divided into
Requirement Areas, which is a business-view
categorization of items in product backlog. Each area
includes a set of 4-8 teams and one PO who defines
as well as prioritizes user stories for teams.
Methodology:
Scrum, XP, Kanban
Process:
For smaller teams (1 ART): Product Manager
defines features and adds them to Program
Backlog. Every PI and sprint, PO creates user
stories and helps dev teams to clarify and
deliver items. Regular scrum meetings help
them to track sprint goals.
For larger teams (more than 1 ART): Solution
manager feeds in requirements in Solution
Backlog which then becomes a source of
requirements for Program Backlog.
Furthermore, items from Program Backlog are
taken up in PI planning and transported to
Team’s Backlog in terms of user stories.
Methodology:
Scrum, XP, Kanban, Lean Startup, Waterfall, SAFe
Process: (Irrespective of size)
Inception: This can also be termed as pre-construction
phase where the goal is to align to a enterprise direction,
secure funding and setup a team.
Construction: At this point, PO helps teams to discover
solution details along with stakeholders. Further delivery is
done in increments. Riskier architecture implementations
are taken up first.
Transition: At this step, readiness of solution for production
is ensured. When all is good, it is deployed and released.

23. Artifacts
9
Team-level:
Potentially shippable product increment
Sprint Backlog for each team
Sprint Goals
Program-level:
Requirement Areas
Area Product Backlog
Product Backlog
Product Vision & Roadmap
Team-level:
Working Software
Team & Sprint Backlog for each team
Sprint Goals & PI Objective
Program, Solution & Portfolio-level:
Value Stream
Program & Solution Backlog
Portfolio Backlog
Product Vision & Roadmap
Architecture Runway
Team-level:
Consumable Solution
Initial Requirements & Iteration Backlog
Sprint Goals & Release Plan
Large Solution-level:
Business Roadmap
Initial Requirements
Technology Roadmap
Initial Architectural Vision

24. Dependency management
10
Fundamental belief:
Dependencies need to be eliminated, not managed
since they inhibit the free flow of delivery.
Identification:
Once identified in sprint planning meetings, they are
categorized into long-term & short-term.
Tracking:
Short-term dependencies are tracked via threads on
boards whereas long-term are solved by making
teams cross-functional and simplifying architecture.
Fundamental belief:
Dependencies are inevitable, so they must be
well- managed and well-visualized.
Identification:
The first step to do so is done in Program
Increment (PI) Planning. Quite often, they are
categorized into cross-team, cross-ART and
external dependencies.
Tracking:
Program board and Scrum of Scrums are
opportunities to track them closely.
Fundamental belief:
Dependencies should be worked upon just barely enough
to resolve the situation you find yourself in.
Identification:
Discovered in initial release planning and iteration planning
phases, categorization into functional (owned by POs) and
technical dependencies (owned by Architecture Owners) is
done.
Tracking:
Recommended way is to have it resolved by re-prioritizing
deliverables or mocking the work needed.

25. Starting guidelines
11
• Educate everyone
• Define ‘product’
• Define ‘done’
• Have appropriately structured teams
• Ensure that only Product Owner gives work to the
teams
• Keep project managers away from the teams
• Reach tipping point
• Train Lean-Agile change agents
• Train executives, managers and leaders
• Create Lean-Agile Center of Excellence
• Identify value streams and ART
• Create implementation plan
• Prepare for ART launch
• Train teams and launch ART
• Coach ART execution
• Launch more ARTs and value streams
• Extend to portfolio
• Accelerate
• Define iteration cycle
• Work in collaborative manner starting with:
• Requirement and architecture envisioning
• Looking ahead of stated requirements
• Just-in-time design
• Pair Programming
• Improve by adopting retrospectives

26. Recommended coaching
Basic-level:
Certified LeSS Basics
Intermediate-level:
Certified LeSS Practitioner
Expert-level:
Certified LeSS for Executives
Basic-level:
Agile Product and Solution Manager
Lean Portfolio Manager
Product Owner / Product Manager
SAFe® DevOps Practitioner
SAFe® Agilist
Intermediate-level:
SAFe® Architect
SAFe® Agile Software Engineer
SAFe® Scrum Master
SAFe® Practitioner
Expert-level:
SAFe® Program Consultant
SAFe® Release Train Engineer
Basic-level:
Disciplined Agilist
Certified Disciplined Agilist
Intermediate-level:
Disciplined Agile Practitioner
Disciplined Agile Lean Scrum Master
Expert-level:
Disciplined Agile Coach
Disciplined Agile Instructor
12

27. Popular Case studies
13

28. Any similarities?

29. Lean-Agile Roots
1
Lean- Agile Thinking House of Lean Lean Startup Lifecycle

30. Frequent Iterations
2
Shippable product every sprint Release every 8-10 weeks Release after every iteration

31. Lean-Agile Roots
3
Technical excellence at its core Built-in quality practices XP as one of the promoted practices

32. Which one should you choose?

33. Our Recommendation
To be considered when:
• team of 20+ people is involved.
• you have a mid-sized company at hand.
• a minimal set of rules is needed.
• it’s logical to divide product into multiple
business-friendly modules.
• development teams are already practicing agile.
To be considered when:
• team of 50+ people is involved.
• you have a large corporation at hand.
• definition of structures until executive level is
needed.
• multiple large-scale programs are being
developed.
• development teams are already practicing agile.
To be considered when:
• team of 200+ people is involved.
• you have a large corporation at hand.
• guidance for a full-delivery lifecycle is needed.
• agile knowledge of development team is low.

34. Appendix

35. References:
• Wikipedia
• Scaled Agile Framework official website
• Disciplined Agile official website
• LeSS official website
• Large-Scale Scrum (Authored by Bas Vodde & Craig Larman)
• Choose your WoW (Authored by Scott Ambler & Mark Lines)

36. Thank you
www.siddhithakkar.com siddhithakkar@hotmail.com https://www.linkedin.com/in/siddhi-thakkar/