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

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 )

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 )

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 )

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 )

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 )

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 )

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 )

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

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

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 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

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

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

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

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

EBMgt
Evidence-Based Management™
some
diagrams

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

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 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

some
diagramsLeSSLarge-Scale Scrum

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

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

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

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

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

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

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

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

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

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

‣@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