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...
David 
Anderson 
“This approach fits right in with 
the requirements in CMMI ML3 for 
process tailoring. It could be 
stra...
Neil 
Killick 
“I’ve just watched a presentation 
that’s made me so angry it’s 
prompted me to write my first 
blog post i...
Chris 
“Matts 
Someone just shot the Agile brand 
in the back of the head… 
"Two Legs Good." by Chris Matts (30.08.2013, 
...
Dave 
Snowden 
“Put brutally SAFe seemed to be PRINCE II 
camouflaged in Agile language. … SAFe is not 
only a betrayal of...
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 Ag...
Peter 
Hundermark 
“… contains a lot of “process voodoo” that 
will not be required in most cases. … 
confusingly complica...
“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 
implementi...
interactive knowledge base for SAFe 
implementing agile practices at enterprise 
scale 
Scaled Agile Framework it’s a 
Agi...
roles 
all of them, e.g., business owners, release 
train engineer, product managers, system 
architects, UX professionals...
some 
diagrams SAFeScaled Agile Framework
a governed, hybrid approach that DAD 
provides a solid foundation from which to 
scale agile solution delivery within 
ent...
roles 
primary (stakeholder, product owner, 
team member, team lead, architecture 
owner) and secondary (specialist, domai...
DAD 
Disciplined Agile Delivery 
some 
diagrams 
DAD Exploratory Lifecycle 
About this lifecycle: 
Copyright 2014 Discipli...
EBMgt … is an approach to managing EBMgt 
software organisations for the value they 
deliver to the organisation as a whol...
roles 
SM, PO, Change Team (Single Enterprise and 
several Domain Agility Teams) 
EBMgt 
Evidence-Based Management™ 
home ...
EBMgt 
Evidence-Based Management™ 
some 
diagrams
The Enterprise Transition Framework ETF 
… leads and supports an organisation 
through the process of becoming more 
Agile...
roles 
leadership team 
http://www.agile42.com/en/agile-transition/etf 
pilot projects 
train internal coaches 
Agile stra...
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 appl...
roles 
Scrum roles plus 
Area PO (only in >10) 
http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum 
two fra...
some 
diagramsLeSSLarge-Scale Scrum
SA@S I made this acronym up! 
Scaling Agile @ Spotify it’s a 
Scaling Agile @ Spotify 
with Tribes, Squads, Chapters & Gui...
roles 
dedicated PO per squad; Agile coaching as needed; 
stable feature teams; chapter lead; tribe lead 
home 
SA@S I mad...
SA@S I made this acronym up! 
Scaling Agile @ Spotify 
some 
diagrams 
“Big Projects” 
57 
https://dl.dropbox.com/u/101896...
it’s a 
a set of guiding principles 
ScALeD Woohoo, it’s a recursive acronym! 
ScALeD Agile Lean Development 
autonomy, ma...
… 
roles 
ScALeD Woohoo, it’s a recursive acronym! 
ScALeD Agile Lean Development 
http://scaledprinciples.org 
principles...
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 manufact...
… 
roles 
PDFbyR I made this acronym up! 
Product Development Flow by Reinertsen 
http://reinertsenassociates.com 
major t...
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 sp...
Comparison: Commercialisation 
How massively has this scaling approach been commercialised, i.e. exploited in a way design...
Comparison: Scaling 
How does this scaling approach actually handle scaling, i.e. a linear transformation that enlarges ob...
Comparison: Celebrity 
How famous, well known, and often used is this scaling approach in the Agile community on a scale f...
How likely is it that I (Bernd Schiffer) would recommend this scaling approach to a customer of mine, on a scale 
10 
8 
6...
Don’t Scale! Very often the No 1 option for people looking at scaling approaches. 
awesome article “Recruit 
Do Things tha...
‣@berndschiffer 
‣@bold_mover 
‣ coaching@berndschiffer.com 
‣ http://slideshare.net/berndschiffer 
‣ http://berndschiffer...
Upcoming SlideShare
Loading in …5
×

Comparing Ways to Scale Agile at Agile Product and Project Manager Meetup

38,905 views

Published on

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)

Published in: Software, Business
6 Comments
55 Likes
Statistics
Notes
  • If you are aiming high in life, these stories will definitely motivate you to take a big leap http://catking.in/2015/07/22/inspiring-stories/ #TargetIIM #TargetJBIMS #CET2017 #CAT2017
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • All those who are clueless about how to ace the GD PI, here is a useful link http://catking.in/2017/01/12/how-to-crack-gd-and-pi/ #TargetIIM #CAT2017 #IIMorNothing 
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • What is 100% agile: http://www.slideshare.net/ishmelev/agileeng
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I think the question that needs to be answered in the Agile community is what level do we scale to... team or enterprise level? While I found your presentation informative and useful, i think comparing these approaches is mixing apples and oranges. For example, SAFe and DaD (whether or like them or not) are true enterprise level, approaches, with LeSS following on thier heels. SA@S scales teams, ETF is a transformation framework, and I wasn't aware that Don Rienertsen was trying to present a scaling methodology in his book, Product Development Flow. So, of the appraoches you listed, LeSS, SA@S, and Scaled really are the three that can be compared straight up. Overall, regardless of what you think of SAFe, it has changed the conversation in the Agile world for the better, because its brought corporate leadership into it. Before that, Agile was that dirty word that excluded management from participating in the conversation. The reality is that Agile adoption is growing becuase of SAFe... so before we all jump down Dean's throat about it not being agile, we need to consider the reality that unless Agile is funded from those very same "management types" in corporate America that are looking for thier place within these appraoches... because they are not going away any time soon and that is the "Reality of Agile" that we all face as Agilests.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Most of these frameworks assume problem can be solved intrinsically to SW dev. From the perspective of enterprise IT management generally, there is far too little attention to external constraints. Simply saying "don't scale" is not a helpful suggestion to the General Motors and Bank of Americas. The most useful study I have seen for enterprise Agile is the work at Maersk that Josh Arnold led, applying Reinertsen's Cost of Delay theories.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
38,905
On SlideShare
0
From Embeds
0
Number of Embeds
19,892
Actions
Shares
0
Downloads
562
Comments
6
Likes
55
Embeds 0
No embeds

No notes for slide

Comparing Ways to Scale Agile at Agile Product and Project Manager Meetup

  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

×