comparing ways to scale agile at last conference 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.


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

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


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.


Business Value

Identify, prioritize, and select projectsIdentify, prioritize, and select projectsIdentify, prioritize, and select projects


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.


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


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)


Envision the future

Business Roadmap, Technology Roadmap


Backlog

Work Items

Iteration planning session to select work items and identify work tasks for current iteration

Iteration

Work Items




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


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



“Big Projects”

57

https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf

a set of guiding principles


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



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


some diagrams




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


some diagrams


DAD Exploratory Lifecycle


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


Options


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.


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

Daily work

Retrospective

Demo

Release

solution

Coordination

Meeting

Construction T

Continuous stream of development

Sufficient functionality

New

Work

Feedback

Learnings

Strategy

Production ready


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


Proven architecture


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.


Business Value

Identify, prioritize, and select projectsIdentify, prioritize, and select projectsIdentify, prioritize, and select projects


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.


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


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)


Envision the

future

Business Roadmap, Technology Roadmap


Backlog

Work Items

Iteration planning

session to select work

items and identify work

tasks for current iteration

Iteration

Work Items




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


http://ebmgt.orghome

some diagrams


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


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



some diagrams



“Big Projects”

57

https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf

a set of guiding principles


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



some diagrams




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



some diagrams




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


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


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


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!

http://slideshare.net/berndschiffer

http://agiletrail.com

comparing ways to scale agile at last conference 2014

Leadership & Management