Comparing Ways to Scale Agile Bernd Schiffer LAST Conference Melbourne 11/07/2014
Comparing Ways to Scale Agile
Bernd SchifferLAST Conference Melbourne 11/07/2014
“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.
KenSchwaber
"unSAFe at any speed" by Ken Schwaber (06.08.2013, http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed )
“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.
DavidAnderson
"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 )
“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!
NeilKillick
"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 )
“Someone just shot the Agile brand in the back of the head…
ChrisMatts
"Two Legs Good." by Chris Matts (30.08.2013,http://theitriskmanager.wordpress.com/2013/08/30/two-legs-good )
“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.
DaveSnowden
"SAFe: the infantilism of management" by Dave Snowden (25.03.2014, http://cognitive-edge.com/blog/entry/6238/safe-the-infantilism-of-management )
“L.A.F.A.B.L.E - Large Agile Framework Appropriate for Big, Lumbering Enterprises
MikeCohn
"L.A.F.A.B.L.E - Large Agile Framework Appropriate for Big, Lumbering Enterprises" by Mike Cohn(04.2013, http://lafable.com )
“… 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
PeterHundermark
"Scaling Scrum to the Organisation" by Peter Hundermark (14.01.2014,http://www.scrumsense.com/blog/scaling-scrum-organisation )
“Shitty Agile For Enterprises
Martin Fowler
17.06.2014 https://twitter.com/berndschiffer/status/478793485642776576
OverviewThese are the scaling approaches I explored and compared so far.
SAFeinteractive knowledge base for implementing agile practices at enterprise scale
Agile landscape for enterprises with portfolio Kanban, Scrum teams, and Extreme Programming techniquesDean Leffingwell + more
Agile Software Requirementsby Dean Leffingwell
Scaled Agile Framework
it’s a
idea
people behind this
main book/article
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.)
all of them, e.g., business owners, release train engineer, product managers, system architects, UX professionals, development management, and many more
roles
key aspects
http://scaledagileframework.comhome
SAFeScaled Agile Framework
some diagrams
SAFe Scaled Agile Framework
DADa governed, hybrid approach that provides a solid foundation from which to scale agile solution delivery within
enterprise-class organisations
Building on mainstream methodsis the DAD process decision framework, providing an end-to-end approach for agile
software delivery.Scott Ambler and Mark Lines+ more
Disciplined Agile Deliveryby Mark Lines and Scott Ambler
Disciplined Agile Delivery
it’s a
idea
people behind this
main book/article
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
primary (stakeholder, product owner, team member, team lead, architecture owner) and secondary (specialist, domain expert, technical expert, independent
tester, integrator)
roles
key aspects
http://disciplinedagileconsortium.orghome
DADDisciplined Agile Delivery some
diagrams
DADDisciplined Agile Delivery
DAD Exploratory Lifecycle
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
Observe & Measure
Deploy
Measure
Productize
Build a LittleEnvision
Keep going
Hypothesis
Pivot
ProvenIdea
DisprovenIdea
ϓ This lifecycle is followed by agile or lean teams that find themselves in startup or researchsituations, 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.ϓ This lifecycle is often a replacement for the Inception phase of other DAD life cycles
About this lifecycle:
Options
Copyright 2014 Disciplined Agile Consortium
DAD Continuous Delivery Lifecycle
ϓ 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.
About this lifecycle:
Work items are pulled when capacity is available to address them
Replenishment modeling session
Copyright 2014 Disciplined Agile Consortium
Operate and support solution
in production
Enhancement Requests and Defect Reports
Daily work
Retrospective
Demo
Release solution
CoordinationMeeting
Construction T
Continuous stream of developmentSufficient functionality
New Work
Feedback
Learnings
Strategy
Production ready
Delighted stakeholders
Expedite
Fixed Delivery Date
Intangible
New Features
Business Value
Options
Expedite
Fixed Delivery Date
Intangible
Work items are pulled when capacity is available to address them
Replenishment modeling session
Operate and support solution
in production
Enhancement Requests and Defect Reports
New Features
Initial Requirements
Initial Architectural Vision
Initial modeling,
planning, and organization
Daily work
Retrospective
Demo
Release solution into production
CoordinationMeeting
Construction Transition
Continuous stream of developmentStakeholder vision Sufficient functionality
New Features
Feedback
Learnings
Strategy
Inception
Production ready
Delighted stakeholdersProven architecture
Identify, prioritize, and select projects
Envision the future
ϓ 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.
About this lifecycle:
Business Value
Identify, prioritize, and select projectsIdentify, prioritize, and select projectsIdentify, prioritize, and select projects
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
DAD Advanced/Lean Lifecycle
ϓ 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.
About this lifecycle:
Highest-Priority
Inception Construction Transition
Operate and support solution in productionInitial Vision
and Funding
Iteration
DailyWork
Consumable Solution
Daily CoordinationMeeting
Iteration review & retrospective: Demo to stakeholders, determine strategy for next iteration, and learn from your experiences
Funding & Feedback
TasksInitial Requirementsand ReleasePlan
Initial modeling,
planning, and organization
Initial Architectural Vision
ConsumableSolution
Release solution into production
One or more short iterations Many short iterations producing a potentially consumable solution each iteration One or moreshort iterations
Stakeholder vision
Proven architecture
Sufficient functionalityProduction 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
Iteration
Work Items
Identify, prioritize, and select projects
Identify, prioritize, and select projects
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
DAD Basic/Scrum-Based Lifecycle
EBMgtEBMgt … is an approach to managing software organisations for the value they deliver to the organization as a whole.
What Scrum is for software development, EBMgt is for whole organisations; using Scrum to change on
organisational level.Ken Schwaber & Gunther Verheyen+ 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
Evidence-Based Management™
it’s a
idea
people behind this
main book/article
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
SM, PO, Change Team (Single Enterprise and several Domain Agility Teams)
roles
key aspects
EBMgtEvidence-Based Management™
http://ebmgt.orghome some
diagrams
EBMgtEvidence-Based Management™
ETFThe Enterprise Transition Framework … leads and supports an organization through the process of becoming more
Agile.
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
Enterprise Transition Framework™
it’s a
idea
people behind this
main book/article
pilot projects train internal coaches Agile strategy map independent of organisation's size analysis of vision & strategy, organisation & structure, people & skills, products & technology
leadership teamroles
key aspects
http://www.agile42.com/en/agile-transition/etfhome
ETFEnterprise Transition Framework™
some diagrams
ETF Enterprise Transition Framework™
LeSSLarge-scale Scrum is regular Scrum applied to large-scale development.
regular Scrum applied to large-scale developmentCraig Larman and Bass Vodde
Scaling Lean And Agile by Craig Larman and Bas Vodde
Large-Scale Scrumit’s a
idea
people behind this
main book/article
two frameworks: less or equal 10 teams, and more than 10 teams pure Scrum - everything else has to be evolved individually per organisation
Scrum roles plus Area PO (only in >10)
roles
key aspects
http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrumhome
LeSSLarge-Scale Scrum
some diagrams
LeSS Large-Scale ScrumScaling Agile @ Spotifywith Tribes, Squads, Chapters & Guilds
Henrik Kniberg & Anders IvarssonOct 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 despitehaving scaled to over 30 teams across 3 cities.
Spotify is a fascinating company that is transforming the music industry. The company has only existed 6years and already has over 15 million active users and over 4 million paying. The product itself can belikened 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 atSpotify and how the company handles agile with hundreds of developers. Many people are fascinated bythis, 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 articleis only a snapshot of our current way of working - a journey in progress, not a journey completed. By thetime 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 )
Scaling Agile @ Spotify
it’s a
idea
people behind this
main book/article
SA@SI 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
dedicated PO per squad; Agile coaching as needed; stable feature teams; chapter lead; tribe lead
roles
key aspects
…home
Scaling Agile @ SpotifySA@S
I made this acronym up!
some diagrams
Scaling Agile @ SpotifySA@S
I made this acronym up!
“Big Projects”
57
https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf
a set of guiding principles
autonomy, mastery, purpose result in high-performance teams
Peter Beck, Markus Gärtner, Christoph Mathis, Stefan Roock, Andreas Schliep …
ScALeD Agile Lean Developmentit’s a
idea
people behind thismain book/article
ScALeDWoohoo, it’s a recursive acronym!
principles in the categories excited customers, happy and productive employees, global optimisation, supportive leadership, continuous improvement reads like a manifest for Agile scaling
…
roles
key aspects
http://scaledprinciples.orghome
ScALeD Agile Lean DevelopmentScALeD
Woohoo, it’s a recursive acronym!
some diagrams
ScALeD Agile Lean DevelopmentScALeD
Woohoo, it’s a recursive acronym!
sorry, no diagrams so far
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 Flowby Don Reinertsen
Product Development Flow by Reinertsen
it’s a
idea
people behind this
main book/article
PDFbyRI made this acronym up!
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
…
roles
key aspects
http://reinertsenassociates.comhome
Product Development Flow by ReinertsenPDFbyR
I made this acronym up!
some diagrams
sorry, no diagrams so far
Product Development Flow by ReinertsenPDFbyR
I made this acronym up!
SAFeDAD
EBMgtETF
LeSSSA@S
ScALeDPDFbyR
SAFeinteractive knowledge base for implementing agile practices at enterprise scale
Agile landscape for enterprises with portfolio Kanban, Scrum teams, and Extreme Programming techniquesDean Leffingwell + more
Agile Software Requirementsby Dean Leffingwell
Scaled Agile Framework
it’s a
idea
people behind this
main book/article
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.)
all of them, e.g., business owners, release train engineer, product managers, system architects, UX professionals, development management, and many more
roles
key aspects
http://scaledagileframework.comhome
SAFeScaled Agile Framework
some diagrams
SAFe Scaled Agile Framework
DADa governed, hybrid approach that provides a solid foundation from which to scale agile solution delivery within
enterprise-class organisations
Building on mainstream methodsis the DAD process decision framework, providing an end-to-end approach for agile
software delivery.Scott Ambler and Mark Lines+ more
Disciplined Agile Deliveryby Mark Lines and Scott Ambler
Disciplined Agile Delivery
it’s a
idea
people behind this
main book/article
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
primary (stakeholder, product owner, team member, team lead, architecture owner) and secondary (specialist, domain expert, technical expert, independent
tester, integrator)
roles
key aspects
http://disciplinedagileconsortium.orghome
DADDisciplined Agile Delivery
some diagrams
DADDisciplined Agile Delivery
DAD Exploratory Lifecycle
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
Observe &
Measure
Deploy
Measure
Productize
Build a
LittleEnvision
Keep going
Hypothesis
Pivot
Proven
Idea
Disproven
Idea
ϓ This lifecycle is followed by agile or lean teams that find themselves in startup or researchsituations, 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.ϓ This lifecycle is often a replacement for the Inception phase of other DAD life cycles
About this lifecycle:
Options
Copyright 2014 Disciplined Agile Consortium
DAD Continuous Delivery Lifecycle
ϓ 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.
About this lifecycle:
Work items are
pulled when
capacity is available
to address them
Replenishment
modeling session
Copyright 2014 Disciplined Agile Consortium
Operate and
support solution
in production
Enhancement Requests
and Defect Reports
Daily work
Retrospective
Demo
Release
solution
Coordination
Meeting
Construction T
Continuous stream of development
Sufficient functionality
New
Work
Feedback
Learnings
Strategy
Production ready
Delighted stakeholders
Expedite
Fixed Delivery Date
Intangible
New
Features
Business Value
Options
Expedite
Fixed Delivery Date
Intangible
Work items are
pulled when
capacity is available
to address them
Replenishment
modeling session
Operate and
support solution
in production
Enhancement Requests
and Defect Reports
New
Features
Initial
Requirements
Initial
Architectural
Vision
Initial
modeling,
planning, and
organization
Daily work
Retrospective
Demo
Release
solution into
production
Coordination
Meeting
Construction Transition
Continuous stream of development
Stakeholder vision Sufficient functionality
New
Features
Feedback
Learnings
Strategy
Inception
Production ready
Delighted stakeholders
Proven architecture
Identify, prioritize, and select projects
Envision the future
ϓ 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.
About this lifecycle:
Business Value
Identify, prioritize, and select projectsIdentify, prioritize, and select projectsIdentify, prioritize, and select projects
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
DAD Advanced/Lean Lifecycle
ϓ 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.
About this lifecycle:
Highest-Priority
Inception Construction Transition
Operate and
support solution
in productionInitial Visionand Funding
Iteration
Daily
Work
Consumable Solution
Daily Coordination
Meeting
Iteration review &
retrospective: Demo to
stakeholders, determine
strategy for next iteration, and
learn from your experiences
Funding & Feedback
TasksInitial Requirementsand ReleasePlan
Initial
modeling,
planning, and
organization
Initial Architectural Vision
ConsumableSolution
Release
solution into
production
One or more short iterations Many short iterations producing a potentially consumable solution each iteration One or moreshort iterations
Stakeholder vision
Proven architecture
Sufficient functionalityProduction 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
Iteration
Work Items
Identify, prioritize, and select projects
Identify, prioritize, and select projects
Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org
DAD Basic/Scrum-Based Lifecycle
EBMgtEBMgt … is an approach to managing software organisations for the value they deliver to the organisation as a whole.
What Scrum is for software development, EBMgt is for whole organisations; using Scrum to change on
organisational level.Ken Schwaber & Gunther Verheyen+ 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
Evidence-Based Management™
it’s a
idea
people behind this
main book/article
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
SM, PO, Change Team (Single Enterprise and several Domain Agility Teams)
roles
key aspects
EBMgtEvidence-Based Management™
http://ebmgt.orghome
some diagrams
EBMgtEvidence-Based Management™
ETFThe Enterprise Transition Framework … leads and supports an organisation through the process of becoming more
Agile.
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
Enterprise Transition Framework™
it’s a
idea
people behind this
main book/article
pilot projects train internal coaches Agile strategy map independent of organisation's size analysis of vision & strategy, organisation & structure, people & skills, products & technology
leadership teamroles
key aspects
http://www.agile42.com/en/agile-transition/etfhome
ETFEnterprise Transition Framework™
some diagrams
ETF Enterprise Transition Framework™
LeSSLarge-scale Scrum is regular Scrum applied to large-scale development.
regular Scrum applied to large-scale developmentCraig Larman and Bass Vodde
Scaling Lean And Agile by Craig Larman and Bas Vodde
Large-Scale Scrumit’s a
idea
people behind this
main book/article
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
Scrum roles plus Area PO (only in >10)
roles
key aspects
http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrumhome
LeSSLarge-Scale Scrum
some diagrams
LeSS Large-Scale Scrum
Scaling Agile @ Spotifywith Tribes, Squads, Chapters & Guilds
Henrik Kniberg & Anders IvarssonOct 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 despitehaving scaled to over 30 teams across 3 cities.
Spotify is a fascinating company that is transforming the music industry. The company has only existed 6years and already has over 15 million active users and over 4 million paying. The product itself can belikened 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 atSpotify and how the company handles agile with hundreds of developers. Many people are fascinated bythis, 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 articleis only a snapshot of our current way of working - a journey in progress, not a journey completed. By thetime 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 )
Scaling Agile @ Spotify
it’s a
idea
people behind this
main book/article
SA@SI 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
dedicated PO per squad; Agile coaching as needed; stable feature teams; chapter lead; tribe lead
roles
key aspects
…home
Scaling Agile @ SpotifySA@S
I made this acronym up!
some diagrams
Scaling Agile @ SpotifySA@S
I made this acronym up!
“Big Projects”
57
https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf
a set of guiding principles
autonomy, mastery, purpose result in high-performance teams
Peter Beck, Markus Gärtner, Christoph Mathis, Stefan Roock, Andreas Schliep …
ScALeD Agile Lean Developmentit’s a
idea
people behind thismain book/article
ScALeDWoohoo, it’s a recursive acronym!
principles in the categories: excited customers, happy and productive employees, global optimisation, supportive leadership, continuous improvement reads like a manifest for Agile scaling
…
roles
key aspects
http://scaledprinciples.orghome
ScALeD Agile Lean DevelopmentScALeD
Woohoo, it’s a recursive acronym!
some diagrams
ScALeD Agile Lean DevelopmentScALeD
Woohoo, it’s a recursive acronym!
sorry, no diagrams so far
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 Flowby Don Reinertsen
Product Development Flow by Reinertsen
it’s a
idea
people behind this
main book/article
PDFbyRI made this acronym up!
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
…
roles
key aspects
http://reinertsenassociates.comhome
Product Development Flow by ReinertsenPDFbyR
I made this acronym up!
some diagrams
sorry, no diagrams so far
Product Development Flow by ReinertsenPDFbyR
I made this acronym up!
0
2
4
6
8
10
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR
101098
55
00
Comparison: Blueprint vs. PrinciplesWhere is the scaling approach’s focus
on a scale from 0 (very much blueprint and specs) to 10 (all about principles)?
0
2
4
6
8
10
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR
8798
53
00
Comparison: CommercialisationHow 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)?
0
2
4
6
8
10
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR
10101010
55
00
Comparison: ScalingHow 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?
0
2
4
6
8
10
SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR
10101010
13
13
Comparison: RecommendationHow likely is it that I (Bernd Schiffer) would recommend this scaling approach to a customer of mine, on a scale
from 0 (very unlikely) to 10 (very likely)?
Don’t Scale!Very often the No 1 option for people looking at scaling approaches.
Do Things that Don’t Scale by Paul Graham
( http://paulgraham.com/ds.html )
awesome article“Recruit
Fragile Delight Experience Consult
Comparing Ways to
Scale AgileBernd Schiffer
LAST Conference Melbourne 11/07/2014
‣@berndschiffer ‣@bold_mover ‣ [email protected] !‣ http://slideshare.net/berndschiffer ‣ http://berndschiffer.com ‣ http://boldmover.com ‣ http://agiletrail.com
Thank you!