Comparing Ways to Scale Agile at LAST Conference 2014

5,925 views

Published on

Session "Comparing Ways to Scale Agile" at the LAST Conference 2014 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, e.g.:

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

3 Comments
42 Likes
Statistics
Notes
No Downloads
Views
Total views
5,925
On SlideShare
0
From Embeds
0
Number of Embeds
413
Actions
Shares
0
Downloads
229
Comments
3
Likes
42
Embeds 0
No embeds

No notes for slide

Comparing Ways to Scale Agile at LAST Conference 2014

  1. 1. Comparing Ways to Scale Agile BerndSchiffer LASTConferenceMelbourne11/07/2014
  2. 2. “ Acorepremiseofagileisthatthe peopledoingtheworkarethe peoplewhocanbestfigureout howtodoit.Thejobof managementistodoanythingto helpthemdoso,notsuffocate themwithSAFe. Ken Schwaber "unSAFe at any speed" by Ken Schwaber (06.08.2013, http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed )
  3. 3. “ Thisapproachfitsrightinwith therequirementsinCMMIML3for processtailoring.Itcouldbe straightoutofa1990stextbook onprocessengineering. David Anderson "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. 4. “I’vejustwatchedapresentation that’smademesoangryit’s promptedmetowritemyfirst blogpostinages!…I’mnotafanof the“ScaledAgileFramework”to saytheleast.…Yukyukyuk! Neil Killick "The Horror OfThe Scaled Agile Framework" by Neil Killick (21.03.2012, http://neilkillick.com/2012/03/21/the-horror-of-the-scaled-agile-framework )
  5. 5. “ SomeonejustshottheAgilebrand inthebackofthehead… Chris Matts "Two Legs Good." by Chris Matts (30.08.2013,
 http://theitriskmanager.wordpress.com/2013/08/30/two-legs-good )
  6. 6. “ PutbrutallySAFeseemedtobePRINCEII camouflagedinAgilelanguage.…SAFeisnot onlyabetrayalofthepromiseofferedby AGILEbutisamassiveretrogradestep givingthemanagerialclassanexcuseto avoidanysignificantchange. Dave Snowden "SAFe: the infantilism of management" by Dave Snowden (25.03.2014, http://cognitive-edge.com/blog/entry/6238/safe-the-infantilism-of-management )
  7. 7. “ L.A.F.A.B.L.E-LargeAgile FrameworkAppropriateforBig, LumberingEnterprises Mike Cohn "L.A.F.A.B.L.E - Large Agile Framework Appropriate for Big, Lumbering Enterprises" by Mike Cohn
 (04.2013, http://lafable.com )
  8. 8. “ …containsalotof“processvoodoo”that willnotberequiredinmostcases.… confusinglycomplicatedframework….
 SAFeheightenstheriskofjustapplying “lipsticktothepig”andnotdealingwiththe fundamentalchangesthatarerequiredin everyorganisation Peter Hundermark "Scaling Scrum to the Organisation" by Peter Hundermark (14.01.2014,
 http://www.scrumsense.com/blog/scaling-scrum-organisation )
  9. 9. “ ShittyAgileForEnterprises Martin Fowler 17.06.2014 https://twitter.com/berndschiffer/status/478793485642776576
  10. 10. OverviewThesearethescalingapproachesIexploredandcomparedsofar. SAFeinteractiveknowledgebasefor implementingagilepracticesatenterprise scale Agilelandscapeforenterpriseswith portfolioKanban,Scrumteams,and ExtremeProgrammingtechniques DeanLeffingwell +more AgileSoftwareRequirements
 byDeanLeffingwell ScaledAgileFramework it’s a idea peoplebehind this main book/article hierarchywiththreelevels:epicsonportfoliolevel,featuresonprogramlevel,stories onteamlevel minimumunitofpeopleistheAgileReleaseTrain(50-125persons) wantstohaveanswersupfrontforeverything(leadership,architecture,portfolio, teams,culture,etc.) allofthem,e.g.,businessowners,release trainengineer,productmanagers,system architects,UXprofessionals,development management,andmanymore roles key aspects http://scaledagileframework.com home SAFe ScaledAgileFramework some diagrams SAFeScaledAgileFramework DADagoverned,hybridapproachthat providesasolidfoundationfromwhichto scaleagilesolutiondeliverywithin enterprise-classorganisations Buildingonmainstreammethods
 istheDADprocessdecisionframework, providinganend-to-endapproachforagile softwaredelivery.ScottAmblerandMarkLines +more DisciplinedAgileDelivery
 byMarkLinesandScottAmbler DisciplinedAgileDelivery it’s a idea peoplebehind this main book/article people-first,learningoriented,hybrid,fulldeliverylifecycle,processgoaldriven, solutionfocused,risk-valuelifecycle,enterpriseaware definedlife-cycle(inception,construction,transition) mashesScrum,XP,Kanban,LeanStartup,Outside-insoftwaredevelopment,AgileData, AgileModeling(AM),UnifiedProcess primary(stakeholder,productowner, teammember,teamlead,architecture owner) andsecondary(specialist,domain expert,technicalexpert,independent tester,integrator) roles key aspects http://disciplinedagileconsortium.org home DAD DisciplinedAgileDelivery some diagrams DAD DisciplinedAgileDelivery DAD Exploratory Lifecycle Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org Observe & Measure Deploy Measure Productize Build a Little Envision Keep going Hypothesis Pivot Proven Idea Disproven Idea 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. This lifecycle is often a replacement for the Inception phase of other DAD life cycles About this lifecycle: Options Copyright 2014 Disciplined Agile Consortium DAD Continuous Delivery Lifecycle This lifecycle is best utilized by Product Teams. The Inception Phase occured in the distant past, and is, in fact, an historical artifact unless the product vision changes. The Transition Phase has become an activity rather than an explicit phase through automation and discipline. Supports DevOps by streamlining continuous delivery of con- sumable solutions to stakeholders. About this lifecycle: Work items are pulled when capacity is available to address them Replenishment modeling session Copyright 2014 Disciplined Agile Consortium Operate and support solution in production Enhancement Requests and Defect Reports Daily work Retrospective Demo Release solution Coordination Meeting Construction T Continuous stream of development Sufficient functionality New Work Feedback Learnings Strategy Production ready Delighted stakeholders Expedite Fixed Delivery Date Intangible New Features Business Value Options Expedite Fixed Delivery Date Intangible Work items are pulled when capacity is available to address them Replenishment modeling session Operate and support solution in production Enhancement Requests and Defect Reports New Features Initial Requirements Initial Architectural Vision Initial modeling, planning, and organization Daily work Retrospective Demo Release solution into production Coordination Meeting Construction Transition Continuous stream of development Stakeholder vision Sufficient functionality New Features Feedback Learnings Strategy Inception Production ready Delighted stakeholders Proven architecture Identify, prioritize, and select projects Envision the future This lifecycle is best utilized by mature teams who need to release regularly, leading towards a continuous delivery strategy using a Lean approach. Development activities (e.g. demos, retrospectives, requirements elicitation, ...) occur as needed in a continuous manner throughout construction. Work is prioritized and pulled into the team on a just-in-time basis. Work in progress is minimized. About this lifecycle: Business Value Identify, prioritize, and select projects Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Advanced/Lean Lifecycle This Scrum-based lifecycle is typically used by project teams new to agile software development. The team produces a consumable solution at the end of each construction iteration (typically 1-3 weeks in length). Work items are typically prioritized based on a combination of business value and technical risk. About this lifecycle: Highest-Priority Inception Construction Transition Operate and support solution in productionInitial Vision and Funding Iteration 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 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 Iteration Work Items Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Basic/Scrum-Based Lifecycle EBMgtEBMgt…isanapproachtomanaging softwareorganisationsforthevaluethey delivertotheorganizationasawhole. WhatScrumisforsoftware development,EBMgtisforwhole organisations;usingScrumtochangeon organisationallevel.KenSchwaber&GuntherVerheyen +more "TheAgilityGuidetoEvidence-Based Change"byKenSchwaber (2014,http://www.ebmgt.org/portals/agilitypath/The%20Agility %20Guide%20v1.5.pdfversion1.5http://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-BasedManagement™ it’s a idea peoplebehind this main book/article measure,diagnose,andimproveareitemsinaniterativecycle(inspectandadapt) differentdomainsaddressedbyapproach:enterprise,process,productivity,quality, value measurewithmetricstimetomarket,value,andabilitytoinnovate thesemetricsaresocalled"directevidenceofvalue",hencethenameEBMgt,in contrasttocircumstantialevidencelike"AredoingalltheScrummeetings?” metricresultsarecombinedinAgileIndex(singlenumber) diagnosisisindividualforeachorganisation SM,PO,ChangeTeam(SingleEnterpriseand severalDomainAgilityTeams) roles key aspects EBMgt Evidence-BasedManagement™ http://ebmgt.org home some diagrams EBMgt Evidence-BasedManagement™ ETFTheEnterpriseTransitionFramework …leadsandsupportsanorganization throughtheprocessofbecomingmore Agile. Assessment,strategy,pilotphase,rollout aspartofaninspectandadaptlifecycle AndreaTomasiniandMartinKearns +more AgileTransition-Whatyouneedto knowbeforestarting
 byAndreaTomasiniandMartinKearns EnterpriseTransitionFramework™ it’s a idea peoplebehind this main book/article pilotprojects traininternalcoaches Agilestrategymap independentoforganisation'ssize analysisofvision&strategy,organisation&structure,people&skills,products& technology leadershipteam roles key aspects http://www.agile42.com/en/agile-transition/etf home ETF EnterpriseTransitionFramework™ some diagrams ETFEnterpriseTransitionFramework™ LeSS Large-scaleScrumisregularScrum appliedtolarge-scaledevelopment. regularScrumappliedtolarge-scale developmentCraigLarmanandBassVodde ScalingLeanAndAgile byCraigLarmanandBasVodde Large-ScaleScrum it’s a idea peoplebehind this main book/article twoframeworks:lessorequal10teams,andmorethan10teams pureScrum-everythingelsehastobeevolvedindividuallyperorganisation Scrumrolesplus AreaPO(onlyin>10) roles key aspects http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum home LeSS Large-ScaleScrum some diagrams LeSSLarge-ScaleScrum 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 Oneofthemostimpressiveexamples[fordealingwithmultiple teamsinaproductdevelopmentorganization]…isSpotify autonomy,mastery,purpose resultinhigh-performanceteams allofSpotify'semployees(spreadingtheword: HenrikKniberg,AndersIvarsson,andJoakimSundén) ScalingAgile@SpotifybyHenrikKnibergand AndersIvarsson(10.2012,https://dl.dropboxusercontent.com/u/ 1018963/Articles/SpotifyScaling.pdf) ScalingAgile@Spotify it’s a idea peoplebehind this main book/article SA@S I made this acronym up! Scrum,Kanban,XP,hybridsatteamlevel(teamsarefreetochose) autonomoussquads specialinterestgroupscalledchapterstoaddressmastery severalsquadsformtribes(20-100ppl) measurablequarterlygoalsforsquads dedicatedPOpersquad;Agilecoachingasneeded; stablefeatureteams;chapterlead;tribelead roles key aspects … home ScalingAgile@Spotify SA@S I made this acronym up! some diagrams ScalingAgile@Spotify SA@S I made this acronym up! “Big Projects” 57 https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf asetofguidingprinciples autonomy,mastery,purpose resultinhigh-performanceteams PeterBeck,MarkusGärtner,Christoph Mathis,StefanRoock,AndreasSchliep … ScALeDAgileLeanDevelopment it’s a idea peoplebehind this main book/article ScALeD Woohoo, it’s a recursive acronym! principlesinthecategoriesexcitedcustomers,happyandproductiveemployees,global optimisation,supportiveleadership,continuousimprovement readslikeamanifestforAgilescaling … roles key aspects http://scaledprinciples.org home ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym! some diagrams ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym! sorry, no diagrams so far anewparadigm …thedominantparadigmformanagingproduct development…isaswrongaswewereinmanufacturing, beforetheJapaneseunlockedthesecretoflean manufacturing.Ibelievethatanewparadigmisemerging, onethatchallengesthecurrentorthodoxyofproduct development. DonReinertsen ProductDevelopmentFlow
 byDonReinertsen ProductDevelopmentFlowbyReinertsen it’s a idea peoplebehind this main book/article PDFbyR I made this acronym up! majorthemesareeconomics,queues,variability,batchsize,WIPconstraints,cadence &synchronisation&flowcontrol,fastfeedback,decentralisedcontrol severalprinciplesforeachofthemajorthemes … roles key aspects http://reinertsenassociates.com home ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up! some diagrams sorry, no diagrams so far ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up! SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR
  11. 11. SAFeinteractiveknowledgebasefor implementingagilepracticesatenterprise scale Agilelandscapeforenterpriseswith portfolioKanban,Scrumteams,and ExtremeProgrammingtechniques DeanLeffingwell +more AgileSoftwareRequirements
 byDeanLeffingwell ScaledAgileFramework it’s a idea peoplebehind this main book/article
  12. 12. hierarchywiththreelevels:epicsonportfoliolevel,featuresonprogramlevel,stories onteamlevel minimumunitofpeopleistheAgileReleaseTrain(50-125persons) wantstohaveanswersupfrontforeverything(leadership,architecture,portfolio, teams,culture,etc.) allofthem,e.g.,businessowners,release trainengineer,productmanagers,system architects,UXprofessionals,development management,andmanymore roles key aspects http://scaledagileframework.com home SAFe ScaledAgileFramework
  13. 13. some diagrams SAFeScaledAgileFramework
  14. 14. DADagoverned,hybridapproachthat providesasolidfoundationfromwhichto scaleagilesolutiondeliverywithin enterprise-classorganisations Buildingonmainstreammethods
 istheDADprocessdecisionframework, providinganend-to-endapproachforagile softwaredelivery.ScottAmblerandMarkLines +more DisciplinedAgileDelivery
 byMarkLinesandScottAmbler DisciplinedAgileDelivery it’s a idea peoplebehind this main book/article
  15. 15. people-first,learningoriented,hybrid,fulldeliverylifecycle,processgoaldriven, solutionfocused,risk-valuelifecycle,enterpriseaware definedlife-cycle(inception,construction,transition) mashesScrum,XP,Kanban,LeanStartup,Outside-insoftwaredevelopment,AgileData, AgileModeling(AM),UnifiedProcess primary(stakeholder,productowner, teammember,teamlead,architecture owner) andsecondary(specialist,domain expert,technicalexpert,independent tester,integrator) roles key aspects http://disciplinedagileconsortium.org home DAD DisciplinedAgileDelivery
  16. 16. some diagrams DAD DisciplinedAgileDelivery DAD Exploratory Lifecycle Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org Observe & Measure Deploy Measure Productize Build a Little Envision Keep going Hypothesis Pivot Proven Idea Disproven Idea 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. This lifecycle is often a replacement for the Inception phase of other DAD life cycles About this lifecycle: Options Copyright 2014 Disciplined Agile Consortium DAD Continuous Delivery Lifecycle This lifecycle is best utilized by Product Teams. The Inception Phase occured in the distant past, and is, in fact, an historical artifact unless the product vision changes. The Transition Phase has become an activity rather than an explicit phase through automation and discipline. Supports DevOps by streamlining continuous delivery of con- sumable solutions to stakeholders. About this lifecycle: Work items are pulled when capacity is available to address them Replenishment modeling session Copyright 2014 Disciplined Agile Consortium Operate and support solution in production Enhancement Requests and Defect Reports Daily work Retrospective Demo Release solution Coordination Meeting Construction T Continuous stream of development Sufficient functionality New Work Feedback Learnings Strategy Production ready Delighted stakeholders Expedite Fixed Delivery Date Intangible New Features Business Value Options Expedite Fixed Delivery Date Intangible Work items are pulled when capacity is available to address them Replenishment modeling session Operate and support solution in production Enhancement Requests and Defect Reports New Features Initial Requirements Initial Architectural Vision Initial modeling, planning, and organization Daily work Retrospective Demo Release solution into production Coordination Meeting Construction Transition Continuous stream of development Stakeholder vision Sufficient functionality New Features Feedback Learnings Strategy Inception Production ready Delighted stakeholders Proven architecture Identify, prioritize, and select projects Envision the future This lifecycle is best utilized by mature teams who need to release regularly, leading towards a continuous delivery strategy using a Lean approach. Development activities (e.g. demos, retrospectives, requirements elicitation, ...) occur as needed in a continuous manner throughout construction. Work is prioritized and pulled into the team on a just-in-time basis. Work in progress is minimized. About this lifecycle: Business Value Identify, prioritize, and select projects Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Advanced/Lean Lifecycle This Scrum-based lifecycle is typically used by project teams new to agile software development. The team produces a consumable solution at the end of each construction iteration (typically 1-3 weeks in length). Work items are typically prioritized based on a combination of business value and technical risk. About this lifecycle: Highest-Priority Inception Construction Transition Operate and support solution in productionInitial Vision and Funding Iteration 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 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 Iteration Work Items Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Basic/Scrum-Based Lifecycle
  17. 17. EBMgtEBMgt…isanapproachtomanaging softwareorganisationsforthevaluethey delivertotheorganisationasawhole. WhatScrumisforsoftware development,EBMgtisforwhole organisations;usingScrumtochangeon organisationallevel.KenSchwaber&GuntherVerheyen +more "TheAgilityGuidetoEvidence-Based Change"byKenSchwaber (2014,http://www.ebmgt.org/portals/agilitypath/The%20Agility %20Guide%20v1.5.pdfversion1.5http://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-BasedManagement™ it’s a idea peoplebehind this main book/article
  18. 18. measure,diagnose,andimproveareitemsinaniterativecycle(inspectandadapt) differentdomainsaddressedbyapproach:enterprise,process,productivity,quality, value measurewithmetricstimetomarket,value,andabilitytoinnovate thesemetricsaresocalled"directevidenceofvalue",hencethenameEBMgt,in contrasttocircumstantialevidencelike"AreyoudoingalltheScrummeetings?” metricresultsarecombinedinAgileIndex(singlenumber) diagnosisisindividualforeachorganisation SM,PO,ChangeTeam(SingleEnterpriseand severalDomainAgilityTeams) roles key aspects EBMgt Evidence-BasedManagement™ http://ebmgt.org home
  19. 19. some diagrams EBMgt Evidence-BasedManagement™
  20. 20. ETFTheEnterpriseTransitionFramework …leadsandsupportsanorganisation throughtheprocessofbecomingmore Agile. Assessment,strategy,pilotphase,rollout aspartofaninspectandadaptlifecycle AndreaTomasiniandMartinKearns +more AgileTransition-Whatyouneedto knowbeforestarting
 byAndreaTomasiniandMartinKearns EnterpriseTransitionFramework™ it’s a idea peoplebehind this main book/article
  21. 21. pilotprojects traininternalcoaches Agilestrategymap independentoforganisation'ssize analysisofvision&strategy,organisation&structure,people&skills,products& technology leadershipteam roles key aspects http://www.agile42.com/en/agile-transition/etf home ETF EnterpriseTransitionFramework™
  22. 22. some diagrams ETFEnterpriseTransitionFramework™
  23. 23. LeSS Large-scaleScrumisregularScrum appliedtolarge-scaledevelopment. regularScrumappliedtolarge-scale developmentCraigLarmanandBassVodde ScalingLeanAndAgile byCraigLarmanandBasVodde Large-ScaleScrum it’s a idea peoplebehind this main book/article
  24. 24. twoframeworks:lessthanorequalto10teams,andmorethan10teams pureScrum-everythingelsehastobeevolvedindividuallyperorganisation Scrumrolesplus AreaPO(onlyin>10) roles key aspects http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum home LeSS Large-ScaleScrum
  25. 25. some diagrams LeSSLarge-ScaleScrum
  26. 26. 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 Oneofthemostimpressiveexamples[fordealingwithmultiple teamsinaproductdevelopmentorganisation]…isSpotify autonomy,mastery,purpose resultinhigh-performanceteams allofSpotify'semployees(spreadingtheword: HenrikKniberg,AndersIvarsson,andJoakimSundén) ScalingAgile@SpotifybyHenrikKnibergand AndersIvarsson(10.2012,https://dl.dropboxusercontent.com/u/ 1018963/Articles/SpotifyScaling.pdf) ScalingAgile@Spotify it’s a idea peoplebehind this main book/article SA@S I made this acronym up!
  27. 27. Scrum,Kanban,XP,hybridsatteamlevel(teamsarefreetochoose) autonomoussquads specialinterestgroupscalledchapterstoaddressmastery severalsquadsformtribes(20-100ppl) measurablequarterlygoalsforsquads dedicatedPOpersquad;Agilecoachingasneeded; stablefeatureteams;chapterlead;tribelead roles key aspects … home ScalingAgile@Spotify SA@S I made this acronym up!
  28. 28. some diagrams ScalingAgile@Spotify SA@S I made this acronym up! “Big Projects” 57 https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf
  29. 29. asetofguidingprinciples autonomy,mastery,purpose resultinhigh-performanceteams PeterBeck,MarkusGärtner,Christoph Mathis,StefanRoock,AndreasSchliep … ScALeDAgileLeanDevelopment it’s a idea peoplebehind this main book/article ScALeD Woohoo, it’s a recursive acronym!
  30. 30. principlesinthecategories:excitedcustomers,happyandproductiveemployees,global optimisation,supportiveleadership,continuousimprovement readslikeamanifestforAgilescaling … roles key aspects http://scaledprinciples.org home ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym!
  31. 31. some diagrams ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym! sorry, no diagrams so far
  32. 32. anewparadigm …thedominantparadigmformanagingproduct development…isaswrongaswewereinmanufacturing, beforetheJapaneseunlockedthesecretoflean manufacturing.Ibelievethatanewparadigmisemerging, onethatchallengesthecurrentorthodoxyofproduct development. DonReinertsen ProductDevelopmentFlow
 byDonReinertsen ProductDevelopmentFlowbyReinertsen it’s a idea peoplebehind this main book/article PDFbyR I made this acronym up!
  33. 33. majorthemesareeconomics,queues,variability,batchsize,WIPconstraints,cadence &synchronisation&flowcontrol,fastfeedback,decentralisedcontrol severalprinciplesforeachofthemajorthemes … roles key aspects http://reinertsenassociates.com home ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up!
  34. 34. some diagrams sorry, no diagrams so far ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up!
  35. 35. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 1010 9 8 55 00 Comparison: Blueprint vs. Principles Whereisthescalingapproach’sfocus
 onascalefrom0(verymuchblueprintandspecs)to10(allaboutprinciples)?
  36. 36. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 8 7 9 8 5 3 00 Comparison: Commercialisation Howmassivelyhasthisscalingapproachbeencommercialised,i.e.exploitedinawaydesignedtomakeaprofit,
 onascalefrom0(looksverymuchlikeit)to10(notatall)?
  37. 37. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 10101010 55 00 Comparison: Scaling Howdoesthisscalingapproachactuallyhandlescaling,i.e.alineartransformationthatenlargesobjects,onascale from0(doesnotscale,i.e.worksonlywithsuperbigorgs)to10(doesscale,i.e.workswithverysmallorgs)? What I mean is: does it work with 2 teams?
  38. 38. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 10101010 1 3 1 3 Comparison: Recommendation HowlikelyisitthatI(BerndSchiffer)wouldrecommendthisscalingapproachtoacustomerofmine,onascale from0(veryunlikely)to10(verylikely)?
  39. 39. Don’t Scale!VeryoftentheNo1optionforpeoplelookingatscalingapproaches. DoThingsthatDon’tScale byPaulGraham (http://paulgraham.com/ds.html) awesome article “Recruit Fragile Delight Experience Consult
  40. 40. Comparing Ways to Scale Agile BerndSchiffer LASTConferenceMelbourne11/07/2014 ‣@berndschiffer ‣@bold_mover ‣coaching@berndschiffer.com ! ‣http://slideshare.net/berndschiffer ‣http://berndschiffer.com ‣http://boldmover.com ‣http://agiletrail.com Thank you!

×