This presentation gives an overview of the 4 approaches to Scaling Agile - Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS) and Scaling Agile at Spotify (SA@S).
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
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)
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.
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).
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.
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.