The document outlines various approaches to scaling agile methodologies, including the Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS), and the Spotify model. It provides an overview of how these frameworks help organizations synchronize collaboration, enhance transparency, improve code quality, and ensure alignment among multiple teams while promoting self-organization and continuous improvement. Key principles focus on value delivery, effective communication, lean practices, and adapting processes to meet organizational needs.

1. Approaches to Scaling Agile
Srinath Ramakrishnan

2. Approaches to Scaling Agile
 Scaled Agile Framework (SAFe)
 Disciplined Agile Delivery (DAD)
 Large Scale Scrum (LeSS)
 Scaling Agile at Spotify (SA@S)

3. Scaled Agile Framework (SAFe)

4. Scaled Agile Framework
A framework for applying
Lean and Agile practices at enterprise scale
ScaledAgileFramework.com
Synchronizes
alignment,
collaboration and
delivery for large
numbers of teams
CORE VALUES
1. Program Execution
2. Alignment
3. Code Quality
4. Transparency

6. Team Level
▸ Valuable, fully-tested software increments every two weeks
▸ Empowered, self-organizing, self-managing cross-functional teams
▸ Teams operate under program vision, architecture
and user experience guidance
▸ Scrum project management and XP-inspired technical practices
▸ Value delivery via User Stories

7. Program Level
▸ Self-organizing, self-managing team-of-agile-teams
▸ Working, system increments every two weeks
▸ Aligned to a common mission via a single backlog
▸ Common sprint lengths and estimating
▸ Face-to-face release planning cadence for collaboration, alignment,
synchronization, and assessment
▸ Value Delivery via Features and Benefits

8. Portfolio level
▸ Centralized strategy, decentralized execution
▸ Lean-Agile budgeting empowers decision makers
▸ Kanban systems provide portfolio visibility and WIP limits
▸ Enterprise architecture is a first class citizen
▸ Objective metrics support governance and kaizen
▸ Value description via Business and Architectural Epics

9. Goal: Speed, Quality,Value
The Goal
 Sustainably shortest lead time
 Best quality and value to
people and society
 Most customer delight, lowest
cost, high morale, safety
All we are doing is looking at the timeline, from the where
the customer gives us an order to where we collect the
cash. And we are
reducing the time line by reducing the
non-value added wastes. —Taiichi Ohno
We need to figure out a way to
deliver software so fast that our customers
don’t have time to change their minds.
—Mary Poppendieck
Most software problems will exhibit
themselves as a delay. —Al Shalloway

10. Respect for People
 Your customer is whoever
consumes your work
 Don’t trouble them
 Don't overload them
 Don't make them wait
 Don't impose wishful thinking
 Don't force people to do
wasteful work
 Equip your teams with problem-
solving tools
 Form long-term relationships
based on trust
People
 Develop individuals and
teams; they build products
 Empower teams to
continuously improve
 Build partnerships based
on trust and mutual respect

11. Kaizen
Become Relentless In:
 Reflection
 Continuous improvement as
an enterprise value
 A constant sense of danger
 Small steady, improvements
 Consider data carefully, implement
change rapidly
 Reflect at milestones to identify and
improve shortcomings
 Use tools like retrospectives, root
cause analysis, and value stream
mapping
 Protect the knowledge base by
developing stable personnel and
careful succession systems

12. Product Development Flow
Don Reinertsen
Principles of Product
Development Flow
1. Take an economic view
2. Actively manage queues
3. Understand and exploit variability
4. Reduce batch sizes
5. Apply WIP constraints
6. Control flow under uncertainty:
cadence and synchronization
7. Get feedback as fast as possible
8. Decentralize control

13. Lean Foundation: Leadership
 Management is trained in
lean thinking
 Bases decisions on this
long term philosophy
1. Take a Systems View
2. Embrace the Agile Manifesto
3. Implement Product
Development Flow
4. Unlock the Intrinsic Potential
of Knowledge Workers

14. Disciplined Agile Delivery (DAD)

15. A High Level Lifecycle
© Disciplined Agile Consortium 15

16. Process Goals
© Disciplined Agile Consortium 16

17. Disciplined Agile Delivery: Basic Lifecycle
© Disciplined Agile Consortium 17
Iteration based
Uses non Scrum terminology (iteration instead of Sprint)
Work item list – instead of a Product backlog
Includes explicit milestones (governance)

18. Disciplined Agile Delivery: Lean Lifecycle
18
Supports continuous flow of delivery – not iteration based
Has a work item pool (value driven, risk value driven or date
driven)

19. DAD supports a robust set of roles
 Team Lead
◦ Agile process expert, keeps team focused on
achievement of goals, removes impediments
 Product Owner
◦ Owns the product vision, scope and priorities of the
solution
 Architecture Owner
◦ Owns the architecture decisions and technical priorities,
mitigates key technical risks
 Team Member
◦ Cross-functional team members that deliver the
solution
 Stakeholder
◦ Includes the customer but also other stakeholders such
as Project Sponsor, DevOps, architecture, database
groups, governance bodies
© Disciplined Agile Consortium 19

20. DADTeams Are Enterprise Aware
 DAD teams strive to
leverage and enhance the
existing organizational
eco system wherever
possible
 Implications:
◦ Work closely with
enterprise groups
◦ Follow existing
roadmap(s) where
appropriate
◦ Leverage existing assets
◦ Enhance existing assets
© Disciplined Agile Consortium 20

21. Governance is Built Into DAD
 Governance strategies built into DAD:
◦ Risk-value lifecycle
◦ Light-weight milestone reviews
◦ “Standard” opportunities for increased visibility and to
steer the team provided by agile
◦ Enterprise awareness
◦ Robust stakeholder definition
© Disciplined Agile Consortium 21

22. Large Scale Scrum(LeSS)

24. Large Scale Scrum (LeSS)
 Two Agile Scaling Frameworks
◦ LeSS: Up to eight teams (of eight people each).
◦ LeSS Huge: Up to a few thousand people on
one product.
 Scaling elements of LeSS focused on
directing the attention of all of the teams
onto the whole product instead of “my part.”
 Global and “end-to-end” focus are perhaps
the dominant problems to solve in scaling.

25. LeSS Principles

26. LeSS
 Scaled up version of one-team Scrum, and it
maintains many of the practices and ideas of one-
team Scrum
 AllTeams are in a common Sprint to deliver a
common Potentially Shippable Product Increment
(PSPI)
◦ a single Product Backlog
◦ one Definition of Done for all teams
◦ one PSPI at the end of each Sprint
◦ one (overall) Product Owner,
◦ many complete, cross-functional teams (with no
specialist teams),
◦ one Sprint

27. LeSS - Features
 Sprint Planning Part 1 has the same maximum duration as in
single-team Scrum, one hour per week of Sprint, but
participation is limited to two members per team plus the
one overall Product Owner
 Sprint Planning Part 2 is held independently (and usually in
parallel) by eachTeam, though sometimes a member of Team
A may observe Team B‟s meeting and make suggestions when
there is a coordination issue between the teams.
 Daily Scrum is also held independently by each Team, though
a member of Team A may observe Team B‟s Daily Scrum, to
increase information sharing.
 Team representatives may hold an Open Space,Town Hall
Meeting, or Scrum of Scrums several times a week to
increase information sharing and coordination.

28. LeSS - Features
 The Overall Product Backlog Refinement meeting is attended by two representatives /
team -concentrates on splitting, lightweight analysis and estimation for upcoming PBIs.
 Use cross-team estimation to ensure a common baseline for estimation across teams.
 Product Backlog Refinement: Similar to single-team Scrum, but for co-located teams, hold
this at the same time in one big room with all team members present, with each team
facing a separate wall with their own learning tools (whiteboards, projectors, …).
 Sprint Review
◦ Same as single-team Scrum but limited to two members per team plus the Product Owner and
other stakeholders.
◦ Stakeholders visit areas of interest and team members record their feedback.
◦ However, begin and end the Sprint Review with everyone in a common discussion to increase
overall feedback and alignment.
 Overall Retrospective
◦ Maximum duration: 45 minutes per week of Sprint
◦ Retrospective is held early in the first week of the subsequent Sprint.
◦ ScrumMasters and one representative of each Team meet to identify and plan improvement
experiments for the overall product or organization.

29. LeSS Structure
 Each team is self-managing, cross-functional, co-located and long-lived.
 ScrumMasters
◦ are responsible for a well-working LeSS adoption.Their focus is towards theTeams,
Product Owner, organization, and development practices.A ScrumMaster does not
focus on just one team but on the overall organizational system.
◦ A ScrumMaster is a dedicated full-time role.
◦ One ScrumMaster can serve 1-3 teams.
 In LeSS there is no „manager‟ role, but managers may exist and they can
have a useful role.
◦ Their focus is the value-delivering capability of the product development system
rather than the specific scope of a product.
◦ Managers role is to improve the product development system by practicing Go See
and Help, encouraging Stop & Fix, and “experiments over conformance”.
 For the product group, establish the complete LeSS structure “at the start”;
this is vital for a LeSS adoption.
 For the larger organization beyond the product group, adopt LeSS
evolutionary using Go and See to create an organization where
experimentation and improvement is the norm.

30. LeSS Product
 There is one Product Owner and one Product Backlog for
the complete shippable product.
 The Product Owner shouldn‟t work alone on Product
Backlog refinement; he is supported by the multiple Teams
working directly with customers/users and other
stakeholders.
 All prioritization goes through the Product Owner, but
clarification is as much as possible directly between the
Teams and customer/users and other stakeholders.
 One shared Definition of Done for the whole product.
 Each teams can have their own expanded Definition of Done.
 The perfection goal is to improve the Definition of Done so
that it results in a shippable product each Sprint (or even
more frequently).

31. Less Sprint
 There is one product-level Sprint, not a different Sprint for each
Team.
 EachTeam starts and ends the Sprint at the same time. Each Sprint
results in an integrated whole product.
 Sprint Planning consists of two parts: Sprint Planning Part One is
common for all teams while Sprint Planning PartTwo is usually
done separately for each team.
 Sprint Planning Part One is attended by the Product Owner and
Team representatives.They together tentatively select the items
that each team will work on the next Sprint. TheTeams identify
opportunities to work together and final questions are clarified.
 EachTeam has their own Sprint Backlog.
 Sprint Planning PartTwo is forTeams to decide how they will do
the selected items. This usually involves design and the creation of
their Sprint Backlogs.TheTeam forecasts how many items they
believe they can complete during the next Sprint.

32. LeSS Sprint
 Each Team has their own Daily Scrum.
 Cross-team coordination is decided by the teams.
 Product Backlog Refinement (PBR) is done per team for the
items they are likely going to do in the future.
 There is one product Sprint Review; it is common for all
teams. Ensure that enough stakeholders join to contribute
the information needed for effective inspection and
adaptation.
 Each Team has their own Sprint Retrospective.
 A Overall Retrospective is held after the Team
Retrospectives to discuss cross-team and system-wide issues,
and create improvement experiments.This is attended by
Product Owner, ScrumMasters,Team Representatives, and
managers (if there are any).

33. LeSS Huge

34. LeSS Huge
 LeSS Huge is the second LeSS Framework, which is
suitable for LeSS adoptions of more than eight teams.
 Conceptually is it LeSS scaled up further by having
multiple (smaller) LeSS frameworks stacked on top of
each other.
 Same
◦ One Product Backlog, one Definition of Done, one
Potentially Shippable Product Increment, one (overall)
Product Owner, one Sprint.All Teams in one Sprint with
one delivery.
 Different
◦ Area PO,Area Backlog, set of parallel LeSS sprint
executions

35. LeSS Huge Structure
 LeSS Huge applies to products with “8+” teams.
 All LeSS rules apply to LeSS Huge, unless otherwise stated.
 Customer requirements that are strongly related from a
customer perspective are grouped in Requirement Areas.
 Each Team specializes in one Requirement Area.Teams are
there “long term”; this won‟t change each Sprint but Teams
will change Requirement Area when others grow in value.
 Each Requirement Area has one Area Product Owner.
 Each Requirement Area has between “4-8” teams.
 LeSS Huge adoptions, including the structural changes, are
done with an evolutionary incremental approach.

36. LeSS Huge Product
 Each Requirement Area has one Area Product Owner.
 One (overall) Product Owner is responsible for
product-wide prioritization and deciding which teams
work in which Area. He works closely with Area
Product Owners.
 Area Product Owners act as Product Owners
towards their teams.
 There is one Product Backlog; every item in it
belongs to exactly one Requirement Area.
 There is one Area Product Backlog per Requirement
Area.This backlog is conceptually a more granular
view onto the one Product Backlog.

37. LeSS Huge Sprint
 There is one product-level Sprint, not a different
Sprint for each Requirement Area. It ends in one
integrated whole product.
 All Sprint LeSS rules apply for each Requirement
Area.
 The Product Owner and Area Product Owners
synchronize frequently. Before Sprint Planning
they ensure the Teams work on the most valuable
items. After the Sprint Review, they enable
product-level adaptations.
 A Overall Review is held per Requirement Area.
 A Overall Retrospective is held per Requirement
Area.

38. Scaling Agile at Spotify (SA@S)

39. Scaling Agile@Spotify

40. Squads
 A Squad is similar to a Scrum team, and is
designed to feel like a mini-startup.
 They sit together, and they have all the skills and
tools needed to design, develop, test, and release
to production.
 They are a self-organizing team and decide their
own way of working – some use Scrum sprints,
some use Kanban, some use a mix of these
approaches
 Squads are encouraged to apply Lean Startup
principles such as MVP (minimum viable product)
and validated learning.This is summarized in the
slogan “Think it, build it, ship it, tweak it”

41. Tribes
 A tribe is a collection of squads that work in related
areas – such as the music player, or backend
infrastructure.
 The tribe can be seen as the “incubator” for the
squad mini-startups. , and have a fair degree of
freedom and autonomy.
 Each tribe has a tribe lead who is responsible for
providing the best possible habitat for the squads
within that tribe.
 The squads in a tribe are all physically in the same
office, normally right next to each other, and the
lounge areas nearby promote collaboration
between the squads.
 Tribes hold gatherings on a regular basis, an informal
get-together where they show the rest of the tribe
(or whoever shows up) what they are working on,
what they have delivered and what others can learn
from what they are currently doing

42. Chapters
 This is the glue that keeps the
company together, providing
economies of scale without sacrificing
too much autonomy.
 The chapter is a small family of people
having similar skills and working within
the same general competency area,
within the same tribe.
 Each chapter meets regularly to
discuss their area of expertise and
their specific challenges - for example
the testing chapter, the web developer
chapter or the backend chapter.

43. Guilds
 A Guild is a more organic and wide-reaching “community of
interest”, a group of people that want to share knowledge, tools,
code, and practices.
 Chapters are always local to a Tribe, while a guild usually cuts
across the whole organization. Some examples are: the web
technology guild, the tester guild, the agile coach guild, etc

44. Coordinating work – Systems
owner
 All systems have a System Owner, or a pair of system owners (pairing).
 For operationally critical systems, the System Owner is a Dev-Ops pair –
that is, one person with a developer perspective and one person with an
operations perspective.
 The system owner is the “go to” person(s) for any technical or
architectural issues related to that system.
 Acts as a coordinator and guides people who code in that system to
ensure that they don‟t stumble over each other.
 Focuses on things like quality, documentation, technical debt, stability,
scalability, and release process.
 The System Owner is not a bottleneck or ivory tower architect.
 Does not personally have to make all decisions, or write all code, or do all
releases - typically a squad member or chapter lead who has other day-to-
day responsibilities in addition to the system ownership.

45. Coordinating work – Chief
Architect
 A person who coordinates work on high-
level architectural issues that cuts across
multiple systems.
 Reviews development of new systems to
make sure they avoid common mistakes, and
that they are aligned with our architectural
vision.
 The feedback is always just suggestions and
input - the decision for the final design of
the system still lies with the squad building
it.

46. Thank you
ramakrishnan.srinath@gmail.com
@rsrinath

47. References
 http://scaledagileframework.com/
 http://disciplinedagiledelivery.com/
 http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
 http://less.works/