Session "Comparing Ways to Scale Agile" at the Agile Product and Project Manager Meetup in Melbourne, Australia. These days organisations are looking for support to scale their Agile environment. There’s a difference between having one Agile team on its own, or to have several Agile teams providing value to the customer and interacting with each other. This session will give an overview and comparison of all the different Agile scaling approaches out there, i.e.: * Scaled Agile Framework (SAFe) * Evidence-Based Management (EBMgt) * Disciplined Agile Delivery (DAD) * Enterprise Transition Framework (ETF) * Large-Scale Scrum (LeSS) * ScALeD Agile Lean Development * Scaling Agile @ Spotify (SA@S) * Product Development Flow by Reinertsen (PDFbyR)

1. Comparing Ways to
Scale Agile
Agile Product and Project Managers Melbourne 28/10/2014
Bernd Schiffer

2. Ken
Schwaber
“A core premise of agile is that the
people doing the work are the
people who can best figure out
how to do it. The job of
management is to do anything to
help them do so, not suffocate
them with SAFe.
"unSAFe at any speed" by Ken Schwaber (06.08.2013, http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed )

3. David
Anderson
“This approach fits right in with
the requirements in CMMI ML3 for
process tailoring. It could be
straight out of a 1990s textbook
on process engineering.
"Kanban - the anti-SAFe for almost a decade already" by David Anderson (31.07.2013,
http://www.djaa.com/kanban-anti-safe-almost-decade-already )

4. Neil
Killick
“I’ve just watched a presentation
that’s made me so angry it’s
prompted me to write my first
blog post in ages! … I’m not a fan of
the “Scaled Agile Framework” to
say the least. … Yuk yuk yuk!
"The Horror Of The Scaled Agile Framework" by Neil Killick (21.03.2012, http://neilkillick.com/2012/03/21/the-horror-of-the-scaled-agile-framework )

5. Chris
“Matts
Someone just shot the Agile brand
in the back of the head…
"Two Legs Good." by Chris Matts (30.08.2013,
http://theitriskmanager.wordpress.com/2013/08/30/two-legs-good )

6. Dave
Snowden
“Put brutally SAFe seemed to be PRINCE II
camouflaged in Agile language. … SAFe is not
only a betrayal of the promise offered by
AGILE but is a massive retrograde step
giving the managerial class an excuse to
avoid any significant change.
"SAFe: the infantilism of management" by Dave Snowden (25.03.2014, http://cognitive-edge.com/blog/entry/6238/safe-the-infantilism-of-management )

7. Mike
“Cohn
L.A.F.A.B.L.E - Large Agile
Framework Appropriate for Big,
Lumbering Enterprises
"L.A.F.A.B.L.E - Large Agile Framework Appropriate for Big, Lumbering Enterprises" by Mike Cohn
(04.2013, http://lafable.com )

8. Peter
Hundermark
“… contains a lot of “process voodoo” that
will not be required in most cases. …
confusingly complicated framework … .
SAFe heightens the risk of just applying
“lipstick to the pig” and not dealing with the
fundamental changes that are required in
every organisation
"Scaling Scrum to the Organisation" by Peter Hundermark (14.01.2014,
http://www.scrumsense.com/blog/scaling-scrum-organisation )

9. “Shitty Agile For Enterprises
Martin
Fowler
17.06.2014 https://twitter.com/berndschiffer/status/478793485642776576

10. Overview These are the scaling approaches I explored and compared so far.
interactive knowledge base for SAFe
implementing agile practices at enterprise
scale
Scaled Agile Framework it’s a
Agile landscape for enterprises with
portfolio Kanban, Scrum teams, and
Dean Leffingwell Extreme Programming techniques + more
Agile Software Requirements
by Dean Leffingwell
idea
people
behind this
main book/article
roles
all of them, e.g., business owners, release
train engineer, product managers, system
architects, UX professionals, development
management, and many more
http://scaledagileframework.com
hierarchy with three levels: epics on portfolio level, features on program level, stories
on team level
minimum unit of people is the Agile Release Train (50-125 persons)
wants to have answers upfront for everything (leadership, architecture, portfolio,
teams, culture, etc.)
key aspects
home
SAFe
Scaled Agile Framework
some
diagrams SAFeScaled Agile Framework a governed, hybrid approach that DAD
Disciplined Agile Delivery it’s a
provides a solid foundation from which to
scale agile solution delivery within
enterprise-class organisations
Building on mainstream methods
is the DAD process decision framework,
providing an end-to-end approach for agile
Scott Ambler and Mark Lines software delivery. + more
Disciplined Agile Delivery
by Mark Lines and Scott Ambler
idea
people
behind this
main book/article
roles
primary (stakeholder, product owner,
team member, team lead, architecture
owner) and secondary (specialist, domain
expert, technical expert, independent
tester, integrator)
home DAD
DAD
Disciplined Agile Delivery
Disciplined Agile Delivery some
http://disciplinedagileconsortium.org
people-first, learning oriented, hybrid, full delivery lifecycle, process goal driven,
solution focused, risk-value lifecycle, enterprise aware
defined life-cycle (inception, construction, transition)
mashes Scrum, XP, Kanban, Lean Startup, Outside-in software development, Agile Data,
Agile Modeling (AM), Unified Process
key aspects
diagrams
DAD Exploratory Lifecycle
About this lifecycle:
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
Observe &
Measure
Deploy
DAD Continuous Delivery Lifecycle
Measure
Productize
Build a
Envision Little
Keep going
Hypothesis
Pivot
Proven
Idea
Disproven
Idea
Fixed Delivery Date
ϓ This lifecycle is followed by agile or lean teams that find themselves in startup or research
situations, typically when their stakeholders do not understand what their potential user base wants.
ϓ Development proceeds via a series of quick learning experiments designed to home in on what
stakeholders actually want.
Options
ϓ This lifecycle is often a replacement for the Inception phase of other DAD life cycles
About this lifecycle:
Replenishment
modeling session
ϓ This lifecycle is best utilized by Product Teams.
ϓ The Inception Phase occured in the distant past, and is, in fact,
an historical artifact unless the product vision changes.
ϓ The Transition Phase has become an activity rather than an
explicit phase through automation and discipline.
ϓ Supports DevOps by streamlining continuous delivery of con-sumable
solutions to stakeholders.
Copyright 2014 Disciplined Agile Consortium
Work items are
pulled when
capacity is available
to address them
Operate and
support solution
in production
Daily work
DAD Advanced/Lean Lifecycle
Enhancement Requests
and Defect Reports
Retrospective
Demo
Release
solution
Coordination
Meeting
Initial
Architectural
Vision
Construction T
Continuous stream of development
Sufficient functionality
New
Work
Feedback
Learnings
Strategy
Production ready
Delighted stakeholders
Expedite
Intangible
New
Features
Business Value
Business Value
Fixed Delivery Date
Expedite
Intangible
Options
Replenishment
modeling session
Work items are
pulled when
capacity is available
to address them
Operate and
support solution
in production
Learnings
Strategy
DAD Basic/Scrum-Based Lifecycle
Enhancement Requests
and Defect Reports
New
Features
Initial
Requirements
Initial
modeling,
planning, and
organization
Daily work
Retrospective
Demo
Release
solution into
production
Coordination
Meeting
New
Features
Feedback
Construction Transition
Continuous stream of development
Inception
Stakeholder vision Sufficient functionality
Daily
Work
Iteration
Production ready
Delighted stakeholders
Proven architecture
Identify, prioritize,
and select projects
Envision the
future
About this lifecycle:
ϓ This lifecycle is best utilized by mature teams who need to release regularly,
leading towards a continuous delivery strategy using a Lean approach.
ϓ Development activities (e.g. demos, retrospectives, requirements elicitation,
...) occur as needed in a continuous manner throughout construction.
ϓ Work is prioritized and pulled into the team on a just-in-time basis.
ϓ Work in progress is minimized.
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
About this lifecycle:
Highest-Priority
Daily Coordination
Meeting
Consumable
Solution
Iteration review &
retrospective: Demo to
stakeholders, determine
strategy for next iteration, and
learn from your experiences
Iteration
Inception Construction Transition
ϓ This Scrum-based lifecycle is typically used by project teams new to agile software
development.
ϓ The team produces a consumable solution at the end of each construction iteration
(typically 1-3 weeks in length).
ϓ Work items are typically prioritized based on a combination of business value and
technical risk.
Operate and
support solution
Initial Vision in production
and Funding
Funding &
Feedback
Tasks
Initial
Requirements
and Release
Plan
Initial
modeling,
planning, and
organization
Initial
Architectural
Vision
Consumable
Solution
Release
solution into
production
One or more short iterations Many short iterations producing a potentially consumable solution each iteration One or more
short iterations
Stakeholder vision
Proven architecture
Sufficient functionality
Production ready
Project viability
(several)
Delighted stakeholders
Envision the
future
Business Roadmap,
Technology Roadmap
Enhancement Requests
and Defect Reports
Backlog
Work Items
Iteration planning
session to select work
items and identify work
tasks for current iteration
Work
Items
Identify, prioritize,
and select projects
Identify, prioritize,
and select projects
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
EBMgt … is an approach to managing EBMgt
software organisations for the value they
deliver to the organization as a whole.
Evidence-Based Management™ it’s a
idea
What Scrum is for software
development, EBMgt is for whole
organisations; using Scrum to change on
Ken Schwaber & Gunther Verheyen organisational level. + more
"The Agility Guide to Evidence-Based
Change" by Ken Schwaber
(2014, http://www.ebmgt.org/portals/agilitypath/The%20Agility
%20Guide%20v1.5.pdf version 1.5 http://www.ebmgt.org/Agility-Guide )
The Agility Guide to
Evidence-Based Change
Using Scrum to Transform Your Enterprise
Version 1.5
Developed and sustained by Ken Schwaber & Scrum.org
people
behind this
main book/article
roles
SM, PO, Change Team (Single Enterprise and
several Domain Agility Teams)
EBMgt
Evidence-Based Management™
home
measure, diagnose, and improve are items in an iterative cycle (inspect and adapt)
different domains addressed by approach: enterprise, process, productivity, quality,
value
measure with metrics time to market, value, and ability to innovate
these metrics are so called "direct evidence of value", hence the name EBMgt, in
contrast to circumstantial evidence like "Are doing all the Scrum meetings?”
metric results are combined in Agile Index (single number)
diagnosis is individual for each organisation
key aspects
http://ebmgt.org
EBMgt
Evidence-Based Management™
some
diagrams
The Enterprise Transition Framework ETF
… leads and supports an organization
through the process of becoming more
Agile.
Enterprise Transition Framework™ it’s a
Assessment, strategy, pilot phase, roll out
as part of an inspect and adapt life cycle
Andrea Tomasini and Martin Kearns + more
Agile Transition - What you need to
know before starting
by Andrea Tomasini and Martin Kearns
idea
people
behind this
main book/article
roles
leadership team
http://www.agile42.com/en/agile-transition/etf
pilot projects
train internal coaches
Agile strategy map
independent of organisation's size
analysis of vision & strategy, organisation & structure, people & skills, products &
technology
key aspects
home
ETF
Enterprise Transition Framework™
some
diagrams ETFEnterprise Transition Framework™
it’s LeSS Large-scale Scrum is regular Scrum
a
Large-Scale Scrum applied to large-scale development.
regular Scrum applied to large-scale
Craig Larman and Bass Vodde development
Scaling Lean And Agile
by Craig Larman and Bas Vodde
idea
people
behind this
main book/article
roles
Scrum roles plus
Area PO (only in >10)
http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum
two frameworks: less or equal 10 teams, and more than 10 teams
pure Scrum - everything else has to be evolved individually per organisation
key aspects
home
LeSS
Large-Scale Scrum
SA@S I made this acronym up!
Scaling Agile @ Spotify it’s a
LeSSLarge-Scaling Agile @ Spotify
with Tribes, Squads, Chapters & Guilds
Henrik Kniberg & Anders Ivars on
some
Scale Scrum Oct 2012
diagramsDealing with multiple teams in a product development organization is always a chal enge!
One of the most impres ive examples we’ve se n so far is Spotify, which has kept an agile mindset despite
having scaled to over 30 teams acros 3 cities.
Spotify is a fascinating company that is transforming the music industry. The company has only existed 6
years and already has over 15 mil ion active users and over 4 mil ion paying. The product itself can be
likened to “a magical music player in which you can instantly find and play every song in the world”.
Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said “Nice -­
I've be n lo king for someone to implement this matrix format since 19 2 :) so it is real y welcome to se .”
So how is this managed?
We have both presented at conferences and be n caught in engaging discus ions around how we work at
Spotify and how the company handles agile with hundreds of developers. Many people are fascinated by
this, so we decided to write an article about it.
Disclaimer: We didn’t invent this model. Spotify is (like any go d agile company) evolving fast. This article
is only a snapshot of our cur ent way of working -­ a journey in progres , not a journey completed. By the
time you read this, things have already changed.
1/14
One of the most impressive examples [for dealing with multiple
teams in a product development organization] … is Spotify
autonomy, mastery, purpose
result in high-performance teams
all of Spotify's employees (spreading the word:
Henrik Kniberg, Anders Ivarsson, and Joakim Sundén)
Scaling Agile @ Spotify by Henrik Kniberg and
Anders Ivarsson (10.2012, https://dl.dropboxusercontent.com/u/
1018963/Articles/SpotifyScaling.pdf )
idea
people
behind this
main book/article
roles
dedicated PO per squad; Agile coaching as needed;
stable feature teams; chapter lead; tribe lead
home
SA@S I made this acronym up!
Scrum, Kanban, XP, hybrids at team level (teams are free to chose)
autonomous squads
special interest groups called chapters to address mastery
several squads form tribes (20-100 ppl)
measurable quarterly goals for squads
key aspects
…
Scaling Agile @ Spotify
SA@S I made this acronym up!
Scaling Agile @ Spotify
some
diagrams
“Big Projects”
57
https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf
it’s a
a set of guiding principles
ScALeD Woohoo, it’s a recursive acronym!
ScALeD Agile Lean Development
autonomy, mastery, purpose
result in high-performance teams
Peter Beck, Markus Gärtner, Christoph
Mathis, Stefan Roock, Andreas Schliep …
idea
people
behind this
main book/article
…
roles
ScALeD Woohoo, it’s a recursive acronym!
ScALeD Agile Lean Development
http://scaledprinciples.org
principles in the categories excited customers, happy and productive employees, global
optimisation, supportive leadership, continuous improvement
reads like a manifest for Agile scaling
key aspects
home
ScALeD Woohoo, it’s a recursive acronym!
ScALeD Agile Lean Development
some
diagrams
sorry, no
diagrams
so far
it’s a idea
a new paradigm
…the dominant paradigm for managing product
development … is as wrong as we were in manufacturing,
before the Japanese unlocked the secret of lean
manufacturing. I believe that a new paradigm is emerging,
one that challenges the current orthodoxy of product
development.
Don Reinertsen
Product Development Flow
by Don Reinertsen
Product Development Flow by Reinertsen
people
behind this
main book/article
PDFbyR I made this acronym up!
…
roles
PDFbyR I made this acronym up!
Product Development Flow by Reinertsen
http://reinertsenassociates.com
major themes are economics, queues, variability, batch size, WIP constraints, cadence
& synchronisation & flow control, fast feedback, decentralised control
several principles for each of the major themes
key aspects
home
PDFbyR I made this acronym up!
some
diagrams
sorry, no
diagrams
so far
Product Development Flow by Reinertsen
SAFe
DAD
EBMgt
ETF
LeSS
SA@S
ScALeD
PDFbyR

11. interactive knowledge base for SAFe
implementing agile practices at enterprise
scale
Scaled Agile Framework it’s a
Agile landscape for enterprises with
portfolio Kanban, Scrum teams, and
Dean Leffingwell Extreme Programming techniques + more
Agile Software Requirements
by Dean Leffingwell
idea
people
behind this
main book/article

12. roles
all of them, e.g., business owners, release
train engineer, product managers, system
architects, UX professionals, development
management, and many more
http://scaledagileframework.com
hierarchy with three levels: epics on portfolio level, features on program level, stories
on team level
minimum unit of people is the Agile Release Train (50-125 persons)
wants to have answers upfront for everything (leadership, architecture, portfolio,
teams, culture, etc.)
key aspects
home
SAFe
Scaled Agile Framework

13. some
diagrams SAFeScaled Agile Framework

14. a governed, hybrid approach that DAD
provides a solid foundation from which to
scale agile solution delivery within
enterprise-class organisations
Disciplined Agile Delivery it’s a
Building on mainstream methods
is the DAD process decision framework,
providing an end-to-end approach for agile
Scott Ambler and Mark Lines software delivery. + more
Disciplined Agile Delivery
by Mark Lines and Scott Ambler
idea
people
behind this
main book/article

15. roles
primary (stakeholder, product owner,
team member, team lead, architecture
owner) and secondary (specialist, domain
expert, technical expert, independent
tester, integrator)
home DAD
Disciplined Agile Delivery
http://disciplinedagileconsortium.org
people-first, learning oriented, hybrid, full delivery lifecycle, process goal driven,
solution focused, risk-value lifecycle, enterprise aware
defined life-cycle (inception, construction, transition)
mashes Scrum, XP, Kanban, Lean Startup, Outside-in software development, Agile Data,
Agile Modeling (AM), Unified Process
key aspects

16. DAD
Disciplined Agile Delivery
some
diagrams
DAD Exploratory Lifecycle
About this lifecycle:
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
Observe &
Measure
Deploy
DAD Continuous Delivery Lifecycle
Measure
Productize
Build a
Envision Little
Keep going
Hypothesis
Pivot
Proven
Idea
Disproven
Idea
Fixed Delivery Date
‧ This lifecycle is followed by agile or lean teams that find themselves in startup or research
situations, typically when their stakeholders do not understand what their potential user base wants.
‧ Development proceeds via a series of quick learning experiments designed to home in on what
stakeholders actually want.
Options
‧ This lifecycle is often a replacement for the Inception phase of other DAD life cycles
About this lifecycle:
Replenishment
modeling session
‧ This lifecycle is best utilized by Product Teams.
‧ The Inception Phase occured in the distant past, and is, in fact,
an historical artifact unless the product vision changes.
‧ The Transition Phase has become an activity rather than an
explicit phase through automation and discipline.
‧ Supports DevOps by streamlining continuous delivery of con-sumable
solutions to stakeholders.
Copyright 2014 Disciplined Agile Consortium
Work items are
pulled when
capacity is available
to address them
Operate and
support solution
in production
Daily work
DAD Advanced/Lean Lifecycle
Enhancement Requests
and Defect Reports
Retrospective
Demo
Release
solution
Coordination
Meeting
Initial
Architectural
Vision
Construction T
Continuous stream of development
Sufficient functionality
New
Work
Feedback
Learnings
Strategy
Production ready
Delighted stakeholders
Expedite
Intangible
New
Features
Business Value
Business Value
Fixed Delivery Date
Expedite
Intangible
Options
Replenishment
modeling session
Work items are
pulled when
capacity is available
to address them
Operate and
support solution
in production
Learnings
Strategy
DAD Basic/Scrum-Based Lifecycle
Enhancement Requests
and Defect Reports
New
Features
Initial
Requirements
Initial
modeling,
planning, and
organization
Daily work
Retrospective
Demo
Release
solution into
production
Coordination
Meeting
New
Features
Feedback
Construction Transition
Continuous stream of development
Inception
Stakeholder vision Sufficient functionality
Daily
Work
Iteration
Production ready
Delighted stakeholders
Proven architecture
Identify, prioritize,
and select projects
Envision the
future
About this lifecycle:
‧ This lifecycle is best utilized by mature teams who need to release regularly,
leading towards a continuous delivery strategy using a Lean approach.
‧ Development activities (e.g. demos, retrospectives, requirements elicitation,
...) occur as needed in a continuous manner throughout construction.
‧ Work is prioritized and pulled into the team on a just-in-time basis.
‧ Work in progress is minimized.
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
About this lifecycle:
Highest-Priority
Daily Coordination
Meeting
Consumable
Solution
Iteration review &
retrospective: Demo to
stakeholders, determine
strategy for next iteration, and
learn from your experiences
Iteration
Inception Construction Transition
‧ This Scrum-based lifecycle is typically used by project teams new to agile software
development.
‧ The team produces a consumable solution at the end of each construction iteration
(typically 1-3 weeks in length).
‧ Work items are typically prioritized based on a combination of business value and
technical risk.
Operate and
support solution
Initial Vision in production
and Funding
Funding &
Feedback
Tasks
Initial
Requirements
and Release
Plan
Initial
modeling,
planning, and
organization
Initial
Architectural
Vision
Consumable
Solution
Release
solution into
production
One or more short iterations Many short iterations producing a potentially consumable solution each iteration One or more
short iterations
Stakeholder vision
Proven architecture
Sufficient functionality
Production ready
Project viability
(several)
Delighted stakeholders
Envision the
future
Business Roadmap,
Technology Roadmap
Enhancement Requests
and Defect Reports
Backlog
Work Items
Iteration planning
session to select work
items and identify work
tasks for current iteration
Work
Items
Identify, prioritize,
and select projects
Identify, prioritize,
and select projects
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org

17. EBMgt … is an approach to managing EBMgt
software organisations for the value they
deliver to the organisation as a whole.
Evidence-Based Management™ it’s a
idea
What Scrum is for software
development, EBMgt is for whole
organisations; using Scrum to change on
Ken Schwaber & Gunther Verheyen organisational level. + more
"The Agility Guide to Evidence-Based
Change" by Ken Schwaber
(2014, http://www.ebmgt.org/portals/agilitypath/The%20Agility
%20Guide%20v1.5.pdf version 1.5 http://www.ebmgt.org/Agility-Guide )
The Agility Guide to
Evidence-Based Change
Using Scrum to Transform Your Enterprise
Version 1.5
Developed and sustained by Ken Schwaber & Scrum.org
people
behind this
main book/article

18. roles
SM, PO, Change Team (Single Enterprise and
several Domain Agility Teams)
EBMgt
Evidence-Based Management™
home
measure, diagnose, and improve are items in an iterative cycle (inspect and adapt)
different domains addressed by approach: enterprise, process, productivity, quality,
value
measure with metrics time to market, value, and ability to innovate
these metrics are so called "direct evidence of value", hence the name EBMgt, in
contrast to circumstantial evidence like "Are you doing all the Scrum meetings?”
metric results are combined in Agile Index (single number)
diagnosis is individual for each organisation
key aspects
http://ebmgt.org

19. EBMgt
Evidence-Based Management™
some
diagrams

20. The Enterprise Transition Framework ETF
… leads and supports an organisation
through the process of becoming more
Agile.
Enterprise Transition Framework™ it’s a
Assessment, strategy, pilot phase, roll out
as part of an inspect and adapt life cycle
Andrea Tomasini and Martin Kearns + more
Agile Transition - What you need to
know before starting
by Andrea Tomasini and Martin Kearns
idea
people
behind this
main book/article

21. roles
leadership team
http://www.agile42.com/en/agile-transition/etf
pilot projects
train internal coaches
Agile strategy map
independent of organisation's size
analysis of vision & strategy, organisation & structure, people & skills, products &
technology
key aspects
home
ETF
Enterprise Transition Framework™

22. some
diagrams ETFEnterprise Transition Framework™

23. it’s LeSS Large-scale Scrum is regular Scrum
a
Large-Scale Scrum applied to large-scale development.
regular Scrum applied to large-scale
Craig Larman and Bass Vodde development
Scaling Lean And Agile
by Craig Larman and Bas Vodde
idea
people
behind this
main book/article

24. roles
Scrum roles plus
Area PO (only in >10)
http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum
two frameworks: less than or equal to 10 teams, and more than 10 teams
pure Scrum - everything else has to be evolved individually per organisation
key aspects
home
LeSS
Large-Scale Scrum

25. some
diagramsLeSSLarge-Scale Scrum

26. SA@S I made this acronym up!
Scaling Agile @ Spotify it’s a
Scaling Agile @ Spotify
with Tribes, Squads, Chapters & Guilds
Henrik Kniberg & Anders Ivarsson
Oct 2012
Dealing with multiple teams in a product development organization is always a challenge!
One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite
having scaled to over 30 teams across 3 cities.
Spotify is a fascinating company that is transforming the music industry. The company has only existed 6
years and already has over 15 million active users and over 4 million paying. The product itself can be
likened to “a magical music player in which you can instantly find and play every song in the world”.
Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said “Nice -­
I've been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see.”
So how is this managed?
We have both presented at conferences and been caught in engaging discussions around how we work at
Spotify and how the company handles agile with hundreds of developers. Many people are fascinated by
this, so we decided to write an article about it.
Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article
is only a snapshot of our current way of working -­ a journey in progress, not a journey completed. By the
time you read this, things have already changed.
1/14
One of the most impressive examples [for dealing with multiple
teams in a product development organisation] … is Spotify
autonomy, mastery, purpose
result in high-performance teams
all of Spotify's employees (spreading the word:
Henrik Kniberg, Anders Ivarsson, and Joakim Sundén)
Scaling Agile @ Spotify by Henrik Kniberg and
Anders Ivarsson (10.2012, https://dl.dropboxusercontent.com/u/
1018963/Articles/SpotifyScaling.pdf )
idea
people
behind this
main book/article

27. roles
dedicated PO per squad; Agile coaching as needed;
stable feature teams; chapter lead; tribe lead
home
SA@S I made this acronym up!
Scrum, Kanban, XP, hybrids at team level (teams are free to choose)
autonomous squads
special interest groups called chapters to address mastery
several squads form tribes (20-100 ppl)
measurable quarterly goals for squads
key aspects
…
Scaling Agile @ Spotify

28. SA@S I made this acronym up!
Scaling Agile @ Spotify
some
diagrams
“Big Projects”
57
https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf

29. it’s a
a set of guiding principles
ScALeD Woohoo, it’s a recursive acronym!
ScALeD Agile Lean Development
autonomy, mastery, purpose
result in high-performance teams
Peter Beck, Markus Gärtner, Christoph
Mathis, Stefan Roock, Andreas Schliep …
idea
people
behind this
main book/article

30. …
roles
ScALeD Woohoo, it’s a recursive acronym!
ScALeD Agile Lean Development
http://scaledprinciples.org
principles in the categories: excited customers, happy and productive employees, global
optimisation, supportive leadership, continuous improvement
reads like a manifest for Agile scaling
key aspects
home

31. ScALeD Woohoo, it’s a recursive acronym!
ScALeD Agile Lean Development
some
diagrams

32. it’s a idea
a new paradigm
…the dominant paradigm for managing product
development … is as wrong as we were in manufacturing,
before the Japanese unlocked the secret of lean
manufacturing. I believe that a new paradigm is emerging,
one that challenges the current orthodoxy of product
development.
Don Reinertsen
Product Development Flow
by Don Reinertsen
Product Development Flow by Reinertsen
people
behind this
main book/article
PDFbyR I made this acronym up!

33. …
roles
PDFbyR I made this acronym up!
Product Development Flow by Reinertsen
http://reinertsenassociates.com
major themes are economics, queues, variability, batch size, WIP constraints, cadence
& synchronisation & flow control, fast feedback, decentralised control
several principles for each of the major themes
key aspects
home

34. PDFbyR I made this acronym up!
some
diagrams
sorry, no
diagrams
so far
Product Development Flow by Reinertsen

35. Comparison: Blueprint vs. Principles
Where is the scaling approach’s focus
on a scale from 0 (very much blueprint and specs) to 10 (all about principles)?
10
8
6
4
2
0
9 10 10 8
5 5
0 0
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR

36. Comparison: Commercialisation
How massively has this scaling approach been commercialised, i.e. exploited in a way designed to make a profit,
on a scale from 0 (looks very much like it) to 10 (not at all)?
9
7.2
5.4
3.6
1.8
0
8
7
9
8
5
3
0 0
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR

37. Comparison: Scaling
How does this scaling approach actually handle scaling, i.e. a linear transformation that enlarges objects, on a scale
from 0 (does not scale, i.e. works only with super big orgs) to 10 (does scale, i.e. works with very small orgs)?
What I mean is: does it work with 2 teams?
10
8
6
4
2
0
10 10 10 10
5 5
0 0
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR

38. Comparison: Celebrity
How famous, well known, and often used is this scaling approach in the Agile community on a scale from 0 (not at
all) to 10 (ubiquitous)?
10
8
6
4
2
0
10
1
10
8
3 2
5
10
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR

39. How likely is it that I (Bernd Schiffer) would recommend this scaling approach to a customer of mine, on a scale
10
8
6
4
2
0
Comparison: Recommendation
from 0 (very unlikely) to 10 (very likely)?
10 10 10 10
1
3
1
3
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR

40. Don’t Scale! Very often the No 1 option for people looking at scaling approaches.
awesome article “Recruit
Do Things that Don’t Scale
by Paul Graham
( http://paulgraham.com/ds.html )
Fragile
Delight
Experience
Consult

41. ‣@berndschiffer
‣@bold_mover
‣ coaching@berndschiffer.com
‣ http://slideshare.net/berndschiffer
‣ http://berndschiffer.com
‣ http://boldmover.com
‣ http://agiletrail.com
Thank
you!
Comparing
Ways to
Scale Agile
Bernd Schiffer
Agile Product and Project Managers
Melbourne 28/10/2014