Top Banner
267

About This E-Book · This book is for everyone in product development. The only prerequisite to this book is basic Scrum knowledge. If you don’t have that, we recommend you start

Jan 28, 2021

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • AboutThisE-Book

    EPUB is an open, industry-standard format for e-books. However, support for EPUB and its manyfeaturesvariesacrossreadingdevicesandapplications.Useyourdeviceorappsettingstocustomizethepresentationtoyourliking.Settingsthatyoucancustomizeoftenincludefont,fontsize,singleordoublecolumn, landscape or portrait mode, and figures that you can click or tap to enlarge. For additionalinformationaboutthesettingsandfeaturesonyourreadingdeviceorapp,visitthedevicemanufacturer’sWebsite.Manytitlesincludeprogrammingcodeorconfigurationexamples.Tooptimizethepresentationofthese

    elements, view the e-book in single-column, landscape mode and adjust the font size to the smallestsetting.Inadditiontopresentingcodeandconfigurationsinthereflowabletextformat,wehaveincludedimagesof thecodethatmimic thepresentationfoundin theprintbook; therefore,where thereflowableformatmay compromise the presentation of the code listing, youwill see a “Click here to view codeimage”link.Clickthelinktoviewtheprint-fidelitycodeimage.Toreturntothepreviouspageviewed,clicktheBackbuttononyourdeviceorapp.

  • Large-ScaleScrumMorewithLeSS

    CraigLarman

    BasVodde

    Boston•Columbus•Indianapolis•NewYork•SanFrancisco•Amsterdam•CapeTownDubai•London•Madrid•Milan•Munich•Paris•Montreal•Toronto•Delhi

    SãoPaulo•Sydney•HongKong•Seoul•Singapore•Taipei•Tokyo

  • Manyofthedesignationsusedbymanufacturersandsellerstodistinguishtheirproductsareclaimedastrademarks.Wherethosedesignationsappearinthisbook,andthepublisherwasawareofatrademarkclaim,thedesignationshavebeenprintedwithinitialcapitallettersorinallcapitals.

    Theauthorsandpublisherhavetakencareinthepreparationofthisbook,butmakenoexpressedorimpliedwarrantyofanykindandassumenoresponsibilityforerrorsoromissions.Noliabilityisassumedforincidentalorconsequentialdamagesinconnectionwithorarisingoutoftheuseoftheinformationorprogramscontainedherein.

    Forinformationaboutbuyingthistitleinbulkquantities,orforspecialsalesopportunities(whichmayincludeelectronicversions;customcoverdesigns;andcontentparticulartoyourbusiness,traininggoals,marketingfocus,orbrandinginterests),pleasecontactourcorporatesalesdepartmentatcorpsales@pearsoned.comor(800)382-3419.Forgovernmentsalesinquiries,pleasecontactgovernmentsales@pearsoned.com.ForquestionsaboutsalesoutsidetheU.S.,[email protected]:informit.com/aw

    LibraryofCongressControlNumber:2016941974

    Copyright©2017PearsonEducation,Inc.Allrightsreserved.PrintedintheUnitedStatesofAmerica.Thispublicationisprotectedbycopyright,andpermissionmustbeobtainedfromthepublisherpriortoanyprohibitedreproduction,storageinaretrievalsystem,ortransmissioninanyformorbyanymeans,electronic,mechanical,photocopying,recording,orlikewise.Forinformationregardingpermissions,requestformsandtheappropriatecontactswithinthePearsonEducationGlobalRights&PermissionsDepartment,pleasevisitwww.pearsoned.com/permissions/.

    ISBN-13:978-0-321-98571-2ISBN-10:0-321-98571-0

    TextprintedintheUnitedStatesonrecycledpaperatRRDonnelleyinCrawfordsville,Indiana.Firstprinting,August2016

    mailto:[email protected]:[email protected]:[email protected]://informit.com/awhttp://www.pearsoned.com/permissions/

  • Contents

    1MorewithLeSS

    2LeSS

    LeSSStructure

    3Adoption

    4OrganizebyCustomerValue

    5Management

    6ScrumMasters

    LeSSProduct

    7Product

    8ProductOwner

    9ProductBacklog

    10DefinitionofDone

    LeSSSprint

    11ProductBacklogRefinement

    12SprintPlanning

    13Coordination&Integration

    14Review&Retrospective

    MoreorLeSS

    15What’sNext?

    RecommendedReadings

    AppendixA:Rules

    AppendixB:Guides

    Index

  • Foreword

    byStephenDenning

    Large-Scale Scrum or LeSS continues the major discoveries that are transforming the world ofmanagementbyshowinghowtoimplementAgileandScrumatscale.

    In the 20th Century, hierarchical bureaucracy enabled large groups to work together to achieveextraordinary improvements in productivity. Then the world changed. Deregulation, globalization, theemergence of knowledge work and new technology, particularly the Internet, transformed everything.Competition increased. The pace of change accelerated. Computer software enabled huge gains inproductivitybutinturngeneratedimmensecomplexity.Aspowerinthemarketplaceshiftedfromsellertobuyer, the customer, not the firm, became the center of the commercial universe.These shifts requiredfundamentallydifferentmanagementthatcouldmobilizethetalentsofeveryoneintheorganization—andbeyond—tomeet the new andmore difficult challenge of delighting customers. The changes went farbeyondfixestoexistingmanagementpractices.AgileandScrumofferexplicitalternativestoseeminglylong-held,obvious,self-evidentmanagementassumptions.

    LeSS shows how to handle large and complex development. Self-managed teams are not just tinycuriosities.Theycanmanagevastinternationaloperationsofgreattechnicalcomplexity.Thepracticesarenotonlyscalable,unlikebureaucracy,theyarescalablewithoutsclerosis.

    LeSS continues the process of fundamentally reinventing management by incorporating the hard-wonlessonsofexperienceovermorethanadecadeinscalingthemanagementmethodsofAgileandScrum.Itshowshowtocopewithimmensecomplexitybycreatingsimplicity.

    LeSSisdeliberately incomplete. It leavesspaceforvastsituational learning. Itdoesn’tofferdefinitiveanswers.Nordoesittrytosatisfy20thCenturylongingsforformulaicanswersorforapparentlysafeanddisciplined approaches that offer a comforting illusion of predictable control. LeSS focuses on theminimal essence required when scaling, including continuous attention to technical excellence, and amindsetofcontinuousexperimentation.Itinvolvesforevertryingnewexperimentsinanefforttoimprove.LikeScrumitself,LeSSstrivesforabalancebetweenabstractprinciplesandconcretepractices.

    And likeScrum,LeSS isnotaprocessora technique forbuildingproducts.Rather, it is a frameworkwithinwhichprocessesandtechniquescanbeadaptedtomeettheneedsoftheparticularsituation.Itaimstomakeclearhowproductmanagementanddevelopmentpracticescanenablecontinuous improvementthataddsvaluetocustomers.

    Ratherthanprovidingfixedanswers,LeSSprovidesthestartingpointforunderstandingandadoptingitsdeeper principles. Instead of asking, “How can we do Agile at scale in our complex hierarchicalbureaucracy?”itasksadifferentanddeeperquestionis,“Howcanwesimplifytheorganization,andbeAgile?”

    LeSSstrivestoachievethisbalanceforlargerproductgroups.ItaddsmoreconcretestructuretoScrum,whilemaintaining radical transparencyandemphasizing the inspect-and-adaptcycle so thatgroupscancontinuouslyimprovetheirownwaysofworking.Itaddressesthebasicquestion:Howdowetakewhatworks really well at the individual team level and make that happen at a much wider level in theorganization?

    MuchremainstobelearnedanddoneintermsofscalingAgileandScrum.Thisbookisbothaprogress

  • reportandaguidetothefuture.Atpresent,manyorganizationsarenotdoingagoodjobhavingmultipleteamsworkinginsynconvariousaspectsofproductsandplatforms.SurveysshowthatmostAgileandScrum teams today report tension between the way their team operates and the way the rest of theorganizationisrun.Thisbookprovidesapractical,step-by-stepguidetoresolvingthistension.

    StephenDenningAuthorofTheLeader’sGuidetoRadicalManagement

    April27,2016

  • Preface

    Allgreattruthsbeginasblasphemies.—GeorgeBernardShaw

    Welcome to this portal into the world of LeSS, where simpler structures replace organizationalcomplexity by focusing on people and their learning.To some people,LeSSmight seem romantic andhopelesslyidealistic.Notso,itistherealityformanyproductgroupstoday!

    WhyThisBook?

    WhilereflectingonthefeedbackthatourprevioustwobooksonLeSSpresentedtoomanyideaswithtoofewstartingpoints,CraigaskedBasifhewantedtowriteanotherbook.Basdeclinedashewaseagerlyawaiting thearrivalofhissecondson.ArelentlessCraigconvincedBas thisbookwasgoing tobeaneasyone.Craigwaswrong.

    OurinitialintentwastowriteaprimerforthepreviousLeSSbooks.Weendedupwithaverydifferentbookasourexplorationinconcretestartingpointsledtoapursuitfortheminimumessentialsforscaling.Theresult?TheLeSSrules,theLeSSguides,andthisbook.

    TheLeSSrulesandguidesareimportant,buttheyarenottheonlyconsiderationswhenscaling.Beforediving into LeSS,wewant to explicitly highlight two other important points: continuous attention totechnicalexcellenceandtheexperimentationmindset.

    Audience

    This book is for everyone in product development. The only prerequisite to this book is basic Scrumknowledge. If you don’t have that, we recommend you start with reading through the Scrum Guide(scrumguides.org)andtheScrumPrimer(scrumprimer.org).WestarteverychapterwithaquickScrumrefresherrelatedtothattopic.

    ChapterStructure

    Eachmajorchapterhasthefollowingstructure:

    One-teamScrumSummarizeone-teamScrum,tosetthestageforlearningLeSS.

    LeSSCoversthebasicLeSSframework.Thissectionisstructuredas:

    IntroductionandrelatedLeSSprinciples.

    LeSSrules.

    LeSSguides.

    LeSSHugeStructuredthesamewayastheLeSSsection.

    http://scrumguides.org/http://scrumprimer.org/

  • Style

    Wedecidedonthefollowingstylechoices:

    LeSSandScrumtermsarecapitalized,suchas:Sprint,ProductBacklog,Team.Note:TeamistheroleinLeSSwhereasteamisthegeneralconceptofateam.

    Throughoutthebookweuseyoutorefertoyou,thereader.WeassumeyouareinvolvedinaLeSSadoptionandwepretendyourrolerelatestothetopicofthechapter.Forexample,intheProductOwnerchapter,youareaProductOwner.

    Weuseitalic,bold,andboxestoemphasizeimportantpoints.

    Thebookisintentionallyshallowinbibliographicreferences.Formorethoroughreferences,pleaserefertoourpreviousbookswhichhaveextensivebibliographies.

    OrganizationalTerms

    Mosttermsaredefinedwhenfirstused.However,we’vestruggledwithorganizationaltermsasdifferentcompaniesusedifferentterms.Therefore,hereweintroducethetermsweusethroughoutthebook,whichwillbeobviousforsomereaders,yetobscureforothers.

    ProductgroupAllpeopleinvolvedintheproduct.Companiesoftenuseprojecttorefertoallpeopleinvolvedinthedevelopment,butthisbookavoidsthetermprojectasitstrivestoemphasizeproductdevelopment.Hence,productgroup.

    LineorganizationTheformalorganizationusuallydepictedinanorg-chart.Lineorganizationistypicallyinvolvedinevaluation,hiring,firing,andcompetencedevelopment.Companiesmightalsohaveamatrixedprojectorganization(thisshouldnotexistinLeSS)andstafforsupportorganization.

    Linemanagerandfirst-levelmanagerAmanageryoureporttointhelineorganization.Thefirst-levelmanageristhedirectlinemanageryoureportto.

    SeniormanagerorexecutiveManagerswhoworknearthetopoftheorganization.Inalargeorganization,theytendtobeoutsidetheproductgroup.

    ProductmanagementorproductmarketingThefunctioninproductorganizationsthatexplorethemarketanddecideonthecontentoftheproduct.Thisisnormallynotinalinerelationshipwiththeteams.

    HeadoftheproductgroupThemanagerwhoheadstheproductgrouptowhichallpeopleintheproductgroupreportinalinerelationship.

    Project/programmanagerRoletraditionallyresponsibleforthescheduleofarelease.Thisisnormallynotalinerelationshipwiththeteamasithasashort-termtemporaryfocus.TheserolesshouldnotexistinaLeSSorganization.

  • FunctionalorganizationLineorganizationforafunctionalskillsuchasdevelopment,test,oranalysis.ShouldceasetoexistinaLeSSorganization.

    Acknowledgments

    We’vehadahugenumberofreviewersforthisbook.Thosewhocommentedonmorethanonechapterarelistedbelow.

    JanneKohvakka,HansNeumaier,RafaelSabbagh,RanNyman,AhmadFahmy,MikeCohn,GojkoAdzic,Jutta Eckstein, Rowan Bunning, Jeanmarc Gerber, Yi Lv, Steve Spearman, Karen Greaves, MarcoSeelmann,CesarioRamos,MarkusGärtner,ViktorGrgic,ChrisChan,NilsBernert,ViacheslavRozet,EdwardDahllöf, LisaCrispin,MikeDwyer, Francesco Sferlazza,Nathan Slippen,Mika Sjöman, TimBorn, Charles Bradley, Timothy Korson, Erin Perry, Greg Hutchings, Jez Humble, Alexey Krivitsky,Alexander Gerber, Peter Braun, Jurgen De Smet, Evelyn Tian, Sami Lilja, Steven Mak, AlexandreCotting,BobSchatz,BobSarni,MilindKulkarni,JanetGregory,JerryRajamoney,KarlKollischan,ShivKumarMn,DavidNunn,ReneHamannt,IlanGoldstein,JuanGabardini,MehmetYitmen,Kai-UweRupp,ChristianEngblom,JamesGrenning,VenkateshKrishnamurthy,PeterHundermark,ArneAhlander,DarrenLai,MarkusSeitz,GeirAmsjø,RamSrinivasan,MarkBregenzer,AaronSanders,MichaelBallé,StuartTurner,EaldenEscañan,StevenKoh,KenYaguchi,michael james,ManojVadakkan,PeterZurkirchen,LaszloCsereklei,GordonWeir,LaurentCarbonnaux,EladSofer.

    And then a special thanks to Bernie Quah for the art and Terry Yin for support on nearly anythingrequested. And to Chris Guzikowski from Addison-Wesley for his patience during this longer thanintendedbookproject.

  • 1.MorewithLeSS

    Thecheapest,fastest,andmostreliablecomponentsarethosethataren’tthere.—GordonBell

    •WhyLeSS?•WhydidScrumadoptionexplodeduringthelastdecade?ThisisthequestionwetoyedwithatahawkercenterinSingapore,overabeer.

    Some say itwas due to the simplistic certificationmodel. Perhaps.But another agilemethod,DSDM,providedcertificationbeforeScrumyetneverbecameaswidespread.

    OtherssaytheavailabilityofScrumMastercoursesmadethedifference.KenSchwaber’soriginalScrumMastercoursehasindeedhadastronginfluence.Yet,ExtremeProgramminghadtheXPImmersioncoursefirstandisn’tascommon.

    Perhapsit’sthesimplicityofScrumthatmadethedifference?ComparedtoXP,Scrumprovidesasimplerframework.Yet,evensimpleragilemethodssuchasCrystalneverreallytookoff.

    Aftersomemorediscussionandthought,Craigsuggested:

    Scrumhitsanidealbalancebetweenabstractprinciplesandconcretepractices.

    Thatconcludedthediscussionandwehadanotherbeer.

    These concrete practices emphasize empirical process control—a core Scrum principle. EmpiricalprocesscontroldistinguishesScrumfromotheragileframeworks.TheScrumGuideputsitwell:

    Scrumisnotaprocessoratechniqueforbuildingproducts;rather,itisaframeworkwithinwhich you can employ various processes and techniques. Scrum makes clear the relativeefficacyofyourproductmanagementanddevelopmentpracticessothatyoucanimprove.

    Meaning?Withempiricalprocesscontrolweneitherfixthescopeoftheproductnortheprocessofhowtobuildit.Instead,inshortcycleswecreateasmallshippablesliceoftheproduct.Weinspectwhatwehave andhowwe created it, and adapt the product and thewaywe create it.This clear inspection isenabledbythebuilt-inmechanismsfortransparency.

    Principlessoundgoodbutarenotobviouslyactionable.ItisthesmallsimplesetofconcretepracticesthatmakeiteasytostartwithScrum:theclearroles,artifacts,andevents.

    These practices get you started, but are intentionally “incomplete” so that groups have the space tocontinuouslylearnandimprovewithintheScrumframework,recognizingthatyouareworkingindomainsofhighcomplexitywheredefinedprocessrecipesaretoosimplistic.

    TheconcretepracticesofScrumprovidethestartingpointforadoptingitsdeeperprinciples.Aperfectbalance.

  • Large-Scale Scrum (LeSS) achieves the same balance for larger product groups. It adds a bit moreconcretestructuretoScrum,whosepurposeistomaintaintransparencyandemphasizetheinspect-adaptcyclesothatgroupscancontinuouslyimprovetheirownwaysofworking.

    LikeScrum,LeSSisdeliberatelyincomplete;itleavesspaceforvastsituationallearning.Itdoesn’toffermanydefinitiveanswers.Itwon’tsatisfythoselookingforformulaicanswersorforapparentlysafeanddisciplined approaches that offer a comforting illusion of predictable control via defined processes.Theseapproachesdestroytheprincipleofempiricalprocesscontrol,andfeelingownershipofprocessesandpractices.

    Alessdefinedprocessleadstomorelearning.Morewithless.

  • 2.LeSS

    Contents

    LeSS•Background••Experiments,Guides,Rules,Principles••LeSSPrinciples••TwoFrameworks:LeSS&LeSSHuge•

    LeSSFramework•LeSSFrameworkSummary••LeSSStories••LeSSStory:FlowofTeams••LeSSStory:FlowofItems•

    LeSSHugeFramework•RequirementAreas••AreaProductOwners••AreaFeatureTeams••LeSSHugeFrameworkSummary••LeSSHugeStories••LeSSHugeStory:ANewRequirementArea••Multi-SiteTeams:Terms&Tips••LeSSHugeStory:Multi-SiteTeams•

    alargestorymapininitialPBRinLeSS

  • 2.LeSS

    Therearetwowaysofconstructinga[design]:Onewayistomakeitsosimplethatthereareobviouslynodeficiencies,andtheotherwayistomakeitsocomplicatedthattherearenoobvious

    deficiencies.—C.A.R.Hoare

    One-TeamScrumScrumisanempirical-process-controldevelopmentframeworkinwhichacross-functionalself-managingTeam develops a product in an iterative incremental manner.1 Each timeboxed Sprint, a potentiallyshippableproductincrementisdeliveredand,ideally,shipped.AsingleProductOwner is responsibleformaximizingproductvalue,prioritizingitemsintheProductBacklog,andadaptivelydecidingthegoalofeachSprintbasedonconstantfeedbackandlearning.AsmallTeam isresponsiblefordeliveringtheSprintgoal;therearenolimitingsingle-specializedroles.AScrumMasterteacheswhyScrumandhowto derive valuewith it, coaches theProductOwner,Team, and organization to apply it, and acts as amirror.Thereisnoprojectmanagerorteamlead.

    Empiricalprocesscontrolrequirestransparency,whichcomesfromshort-cycledevelopmentandreviewofshippableproductincrements.Itemphasizescontinuouslearning,inspection,andadaptationabouttheproductandhowit’screated.It’sbasedonunderstandingthatindevelopmentthingsaretoocomplexanddynamicfordetailedandformulaicprocessrecipes,whichinhibitquestioning,engagement,improvement.

    In the ScrumGuide and ScrumPrimer, the emphasis is for one Team; the focus is not many Teamsworkingtogether.Andthatnaturallyleadstothinkingaboutlarge-scaleScrum.

    LeSS

    LeSSisScrumappliedtomanyteamsworkingtogetherononeproduct.

    LeSSisScrum—Large-ScaleScrum(LeSS2)isn’tnewandimprovedScrum.Andit’snotScrumatthebottom for each team, and something different layered on top.Rather, it’s about figuring outhow toapply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply aspossible.LikeScrumandothertrulyagileframeworks,LeSSis“barelysufficientmethodology”forhigh-impactreasons.

    ScaledScrumisnotaspecialscalingframeworkthathappenstoincludeScrumonlyattheteamlevel.TrulyscaledScrumisScrumscaled.

    ...appliedtomanyteams—Cross-functional,cross-component,full-stackfeatureteamsof3–9learning-focusedpeoplethatdoitall—fromUXtocodetovideos—tocreatedoneitemsandashippableproduct.

    ...workingtogether—TheteamsareworkingtogetherbecausetheyhaveacommongoaltodeliveronecommonshippableproductattheendofacommonSprint,andeachteamcaresaboutthisbecausetheyareafeatureteamresponsibleforthewhole,notapart.

  • ...on one product—What product? A broad complete end-to-end customer-centric solution that realcustomersuse.It’snotacomponent,platform,layer,orlibrary.

    •Background•

    In2002,whenCraigwroteAgile&IterativeDevelopment,manybelieved thatagiledevelopmentwasonly for small groups. However, we both (Craig and Bas) became interested in—and got increasingrequests—toapplyScrumtolarge,multi-site,andoffshoredevelopment.So,since2005wehaveteamedup toworkwith clients to scaleupScrum.Today, the twoLeSS frameworks (smallerLeSS andLeSSHuge)havebeenadoptedinbiggroupsworldwideindisparatedomains:

    telecomequipment—Ericsson&NokiaNetworks3

    investmentandretailbanks—UBS

    tradingsystems—IONTrading

    marketingplatformsandbrandanalytics—Vendasta

    videoconferencing—Cisco

    onlinegaming(betting)—bwin.party

    offshoreoutsourcing—ValtechIndia4

    Intermsof large,what’satypicalLeSSadoptioncase?Perhapsfiveteamsinoneor twosites.We’vebeen involved inadoptionsof thatsize,ofa fewhundredpeople,andup toaLeSSHugecaseofwellovera thousandpeople, far toomanydevelopmentsites, tensofmillionsof linesofC++,withcustomhardware.

    MoreLeSSLearning

    Tohelp people learn andbasedonour experienceswith clients, in 2008 and2010wepublished twobooksonscalingagiledevelopmentwiththeLeSSframeworks:

    1.ScalingLean&AgileDevelopment:ThinkingandOrganizationalToolsforLarge-ScaleScrum—explainsthethinking,leadership,andorganizationaldesignchanges.

    2.PracticesforScalingLean&AgileDevelopment:Large,Multi-site&OffshoreProductDevelopmentwithLarge-ScaleScrum—shareshundredsofconcreteexperimentsforLeSS,basedonourexperiencewithclients;experimentsinproductmanagement,architecture,planning,multi-site,offshore,contracts,andmore.

    Thisbook—Large-ScaleScrum:MorewithLeSS—isthethirdintheLeSSseries,aprequelandprimer.Thisbooksynthesizes,clarifies,andhighlightswhat’smostimportant.

    Besidesthesebooks,seeless.worksforonlinelearningresources(includingbookchapters,articles,andvideos),courses,andcoaching.

    •Experiments,Guides,Rules,Principles•

    The first two LeSS books emphasized: There are no such things as best practices in productdevelopment.Thereareonlypracticesthatareadequatewithinacertaincontext.

    Practicesaresituational;blithelyclaimingtheyare“best”disconnectsthemfrommotivationandcontext.

    http://less.works

  • They become rituals. And pushing so-called best practices kills a culture of learning, questioning,engagement,andcontinuousimprovement.Whywouldpeoplechallengebest?

    Therefore,theearlierLeSSbookssharedexperimentsweandourclientshavetried,andweencouraged—and encourage—this mindset. But over time we noticed two problems with the only-experimentsmindset:

    Novicegroupsmadeunskillfuldecisionstotheirdetriment,adoptingLeSSinwaysnotintended,withobviousproblems;e.g.groupscreatedRequirementAreaswithoneteameach.Ouch!

    Novicegroupsasked,“Wheredowestart?What’smostimportant?”Theyunderstandablycouldn’tseethekeybasics.

    BasedonthisfeedbackwereflectedandreturnedtotheShu-Ha-Rimodeloflearning:Shu—followrulesto learnbasics.Ha—break rulesanddiscovercontext.Ri—mastery and findyour ownway. In aShu-level LeSS adoption, there are a few rules for a barely sufficient framework to kick-start empiricalprocess control and whole-product focus.5 These rules define the two LeSS frameworks that areintroducedsoon.

    Tosummarizeandbuildonthesepoints,LeSSincludes:

    Rules—Afewrulestogetstartedandformthefoundation.TheydefinethekeyelementsoftheLeSSframeworksthatshouldbeinplacetosupportempiricalprocesscontrolandwhole-productfocus.e.g.HoldanOverallRetrospectiveeachSprint.

    Guides—Amoderatesetofguidestoeffectivelyadopttherulesandforasubsetofexperiments;worthtryingbasedonyearsofexperiencewithLeSS.Guidescontaintips.Usuallyhelpfulandareanareaforcontinuousimprovement;e.g.ThreeAdoptionPrinciples.

    Experiments—Manyexperimentsthatareverysituationalandmaynotevenbeworthtrying;e.g.Try...TranslatoronTeam.

    Principles—Attheheart,asetofprinciples—extractedfromexperiencewithLeSSadoptions—thatinformtherules,guides,andexperiments;e.g.whole-productfocus.

    TheLeSSguidesandexperimentsareoptional.Guideswillprobablybehelpfulandarerecommendedtrying.Butbypassordropthosethatlimitfurtherimprovementorjustdon’tfit.

    AgoodwaytolookatLeSSisvisualizedintheLeSScompletepicture:

  • TheLeSScompletepicturewillorderthewayweintroduceLeSS:1.LeSSprinciples,upnext2.LeSSframeworks(definedbytherules),intherestofthischapter3.LeSSguides,inthefollowingchaptersofthisbook4.LeSSexperiments,alreadyavailableinthefirsttwoLeSSbook

    •LeSSPrinciples•

    TheLeSSrulesdefinetheLeSSframework.Buttherulesareminimalisticanddon’tanswerhowtoapplyLeSSinyourspecificcontext.TheLeSSprinciplesprovidethebasisformakingthosedecisions.

  • Large-ScaleScrumisScrum—Itisn’tnewandimprovedScrum.Rather,LeSSisaboutfiguringouthowto apply the principles, rules, elements, and purpose of Scrum in a large-scale context, as simply aspossible.

    Transparency—Basedontangible“done”items,shortcycles,workingtogether,commondefinitions,anddrivingoutfearintheworkplace.

    Morewithless—Wedon’twantmorerolesbecausemoreroles leads to less responsibility toTeams.We don’twantmore artifacts becausemore artifacts leads to a greater distance between Teams andcustomers. We don’t wantmore process because that leads to less learning and team ownership ofprocess. Instead we want more responsible Teams by having less (fewer) roles, we want morecustomer-focused Teams building useful products by having less artifacts, we want more Teamownershipofprocessandmoremeaningfulworkbyhavinglessdefinedprocesses.Wewantmorewithless.

    Whole-productfocus—OneProductBacklog,oneProductOwner,oneshippableproduct,oneSprint—regardless if3or33 teams.Customerswantvaluablefunctionality inacohesiveproduct,not technicalcomponentsinseparateparts.

    Customer-centric—Focusonlearningthecustomersrealproblemsandsolvingthose.Identifyvalueandwaste in the eyes of the paying customers. Reduce wait time from their perspective. Increase andstrengthen feedback loops with real customers. Everyone understands how their work today directlyrelatestoandbenefitspayingcustomers.

    Continuousimprovementtowardsperfection—Here’saperfectiongoal:Createanddeliveraproductalmostallthetime,atalmostnocost,withnodefects,thatdelightscustomers,improvestheenvironment,andmakeslivesbetter.Doendlesshumbleandradicalimprovementexperimentstowardthatgoal.

  • Leanthinking—Createanorganizational systemwhose foundation ismanagers-as-teacherswhoapplyandteachleanthinking,managetoimprove,promotestop-and-fix,andwhopracticeGoSee.Addthetwopillarsofrespectforpeopleandcontinuouschallenge-the-status-quoimprovementmindset.Alltowardsthegoalofperfection.

    Systems thinking—See, understand, and optimize the whole system6 (not parts), and use systemsmodelingtoexploresystemdynamics.Avoidthelocalsub-optimizationsoffocusingontheefficiencyorproductivityofindividualsandindividualteams.Customerscareabouttheoverallconcept-to-cashcycletimeandflow,notindividualsteps,andlocallyoptimizingapartalmostalwayssub-optimizesthewhole.

    Empirical process control—Continually inspect and adapt the product, processes, behaviors,organizational design, and practices to evolve in situationally-appropriate ways. Do that, rather thanfollowaprescribedsetofso-calledbestpracticesthatignorecontext,createritualisticfollowing,impedelearningandchange,andsquashpeople’ssenseofengagementandownership.

    Queuing theory—Understand how systemswith queues behave in the R&D domain, and apply thoseinsightstomanagingqueuesizes,work-in-progresslimits,multitasking,workpackages,andvariability.

    •TwoFrameworks:LeSS&LeSSHuge•

    Large-ScaleScrumhastwoframeworks:

    LeSS.2–8Teams

    LeSSHuge.8+Teams

    The word LeSS is overloaded to mean both Large-Scale Scrum in general and the smaller LeSSframework.

    TheMagicNumberEight

    Actually, eight isn’t a magic number, and if your group can successfully apply the smaller LeSSframework with more than eight teams, great! But we haven’t seen that... yet. It’s just an upper-limitempiricalobservation.And insomecases, suchasvariedcomplexgoalswithmulti-site inexperiencedforeign-language-onlyteams,itcouldbelessthaneight.

    Inanyevent,atsomepoint,(1)thesingleProductOwnercannolongergraspanoverviewoftheentireproduct,(2)theProductOwnercan’tbalanceanexternalandinternalfocus,and(3)theProductBacklogissolargethatitbecomesdifficultforonepersontoworkwith.

    Whenthegrouphitsthattippingpoint,itmaybetimetochangefromthesmallerLeSSframeworktoLeSSHuge.Ontheotherhand,wesuggestfirsttryingtogetbetter,smaller,andsimpler,beforegettinghuger.

    CommonAcrosstheFrameworks

    TheLeSSandLeSSHugeframeworkssharecommonelements:

    oneProductOwnerandoneProductBacklog

    onecommonSprintacrossallteams

    oneshippableproductincrement

    Thefollowingtwosectionsofthischapterexplaintheframeworks;thesmallerLeSSframeworkisnext,

  • andLeSSHugestartsfurtheron.

    LeSSFramework

    •LeSSFrameworkSummary•

    ThesmallerLeSSframeworkisforone(andonlyone)ProductOwnerwhoownstheproduct,andwhomanages one Product Backlog worked on by teams in one common Sprint, optimizing for the wholeproduct.TheLeSSframeworkelementsareaboutthesameasone-teamScrum:

    Roles—OneProductOwner, two to eightTeams, aScrumMaster for one to three Teams. Crucially,theseTeamsare feature teams—true cross-functional and cross-component full-stack teams thatworktogetherinasharedcodeenvironment,eachdoingeverythingtocreatedoneitems.

    Artifacts—Onepotentially shippableproduct increment, oneProduct Backlog, and a separate SprintBacklogforeachTeam.

    Events—One commonSprint for thewhole product; it includes all teams and ends in one potentiallyshippableproductincrement.Detailsareexplainedintheupcomingstories,andinseparatechapters.

    Rules&Guides—Rules for a barely sufficient scaling framework for empirical process control andwhole-productfocus.Guidesmayhelp.

    •LeSSStories•

    LearningLeSS—Oneway to learn is by reading in-depth exposition, and readers preferring that cancomfortablyskipaheadtotheintroductiontoLeSSHuge,andthenontofollowingchapters.Otherswholikestories,keeponreading.

    Simplestories—Thesestoriesdon’texplorethecomplexitiesoflarge-scaledevelopment—frompoliticsto prioritization—that we experience when consulting. Later chapters unpack those boxes. Here areintentionallyplainandsimplestoriesjusttointroducethebasicsofaLeSSSprint.Ifyouwantthrilling

  • dialoganddrama,readaLeanbook.

    Rules&guides—InthestoriesyouwillnoticethatthemarginsrefertorelatedLeSSrulesandguides,toclarifyandmakeconnections.

    Twoperspectives—Followingare two related stories focusing separatelyon twokeyperspectives, tointroducesomeflowsmoresimply:

    1.TheflowofteamsthroughaLeSSSprint.2.Theflowofcustomer-centricitems(features).

    •LeSSStory:FlowofTeams•

    ThisstoryfocusesontheflowofteamsthroughaSprint,ratherthantheflowofitems.InrealitythemajorityoftimeintheSprintisworkingondevelopmenttasks,notmeetings.However,thisstory emphasizesmeetings and interactions, as the goal is an understanding of howmultipleteamsworktogetherduringLeSSevents,andhowtheycoordinatedaybyday.

    Markwalksintotheroomwherehisteam(Trade)worksandseesMira7,whosays,“Goodmorning!Justareminder,we’retheteamrepresentativesforthisSprint,andSprintPlanningOnestartsin10minutes.”“Right,”saysMark,“Meetyouinthebigroom.”

    SprintPlanningOne

    It’stimeforacommonSprintPlanningOne.Aroundthebigroomare10teamrepresentativesfromthefive teams in this product group. They all work on their flagship product for trading bonds andderivatives.Sam,theScrumMasterofteamsTradeandMargin,isalsothere.He’splanningtoobserveandcoachasneeded.(RULE:Thereisoneproduct-levelSprint,notadifferentSprintforeachTeam.8)

    ManySprintsearlier, everyone fromall the teamsattendedSprintPlanningOne.Thatwasmoreusefulwhen the groupwas not very good at getting items clear and ready, nor at creating broad knowledgeacross the teams. Back then, Sprint Planning One was used to answer a lot of major questions thateveryoneneededtohear.But lately that’sbeenmuchimproved,andsonowthegroupisexperimentingwithusingrotatingrepresentatives,inwhathasbecomeasimpleandquickmeetingwithonlyafewminorquestions that tend topopup. If thenewapproachdoesn’tworkwell, itwillprobablybe raised inanOverall Retrospective, and another experiment for Sprint Planning will be created. (RULE: SprintPlanningconsistsoftwoparts:SprintPlanningOneiscommonforallteamswhileSprintPlanningTwoisusuallydoneseparatelyforeachteam.Domulti-teamSprintPlanningTwoinasharedspaceforcloselyrelateditems.)

    Paolowalksinandsays“Hi!”He’stheProductOwnerandalsotheleadproductmanager.9Paololaysout22 cards on a table and says, “Here’s the big themes: German market, order management, and someregulatoryreports.I’velaidthemoutinmypriorityorder.Ithinkeveryonehereunderstandswhythesearethepriorities,sincewe’vebeendiscussingthisalotinProductBacklogrefinement.Butpleaseaskagain,if it’s not clear.” (RULE: Sprint PlanningOne is attended by the ProductOwner and Teams or Teamrepresentatives.TheytogethertentativelyselecttheitemsthateachteamwillworkonforthenextSprint.)

  • MiraandMarkwalkovertothetable(alongwiththeotherrepresentatives)andpicktwocardsforitemsrelated toGerman-marketbonds.Over the last twoSprints their teamclarified these items indetail, insingle-teamProductBacklogrefinement(PBR)workshops.

    And they pick two more items related to order management that both Team Trade and TeamMarginunderstandquitewell.Bothteamsworkedtogetherinmulti-teamPBRworkshopsontheseitems.Why?The teamswanted to decide as late as possible the choice of team-to-item, during some future SprintPlanning. This increases the group’s agility—easily responding to change—and their broader whole-productknowledgefostersself-organizedcoordination.

    Aminutelater,MaryfromTeamMargin,onscanninganotherteam’scards,askstheirrepresentatives,“Doyoumind ifwedo that report?Wedidsomethingverysimilar lastSprintand Ibetwecanget itdonequickly.CouldyouswapforthisGerman-marketitem?”Theyagree.

  • Afterafewminutes,theteamsfinishchoosingandswappingbasedontheirinterests,strengths,anddesiretogrouprelateditemsforfocus.

    Sam (the ScrumMaster) says, “I notice that TeamMargin has the top four priority items. Could thatbecomeaproblem?”Aquickdiscussionensuesinwhichthegrouprealizesthere’sachancethatoneofthehighest-priorityitemsfortheproductcouldgetdroppedifthingsdon’tgosmoothlyforTeamMargin.Theydecide todistribute a fewof thehighest-priority itemsacrossmore teams (constrainedbywhichteamsknowwhichitems),makingitmorelikelythattopitemswillgetdone.

    Therepresentativeshavechosenatotalof18cards,leavingfourlowestpriorityitemsonthetable.Paololooksovertheunchosenitemcards,picksuptwoofthem,andsays,“ThesetwoareprettyimportanttomethisSprint.MaybeIshouldhavegiventhemahigherprioritytobeginwith,butIdidn’t,andnowI’dliketochangemymind.Let’sfindawaytoswapthemwithsomeitemsyou’vealreadychosen.Andofcourse,ifateamgetsluckyandfinishesearly,pleasepickuptheunchosenitems.”

    Afterthat’sresolved,Paolosays,“Okay,let’sspendsometimewrappinguplingeringquestions.Asyouknow,I’vebeenfocusingmoreonfiguringoutprioritization,andmostofyouknowtheseitemdetailsalotbetterthanme,butlet’sseewhatwecandotogethertoclearupminorstuff.”(RULE:InSprintPlanning,Teamsidentifyopportunitiestoworktogetherandfinalquestionsareclarified.)

    Inparallel,Mira,Mark,andtheothersthinkhardaboutfinalminorpointstoclearupfortheiritems,andwritesomequestionsonflip-chartpapersonthewallsaroundtheroom.Paoloroamsaroundtodifferentareas,discussing.Everyoneminglesandcontributes.Afterabout30minutes,alltheminorquestionsthatcouldbeansweredhavebeen.

    Thegroupformsastandingcircletowrapup.Nooneraisesanycoordinationtopics,soeventuallySamsays,“Inotice thatTeamsTradeandMarginandNotDerivativehavepickedupstronglyrelatedorder-managementitems.”Mirasays,“Hey,let’sgetTrade,Margin,andNotDerivativetogetherforamulti-teamSprintPlanningTwo.We’vegotopportunitiestoworktogether.”That’sagreed.Themeetingends.

    TeamandMulti-TeamSprintPlanningTwo

    Afterabreak,twoofthefiveteamsholdtheirownsingle-teamSprintPlanningTwomeetingstocreatetheirownSprintBacklogs,designingandplanningtheirworkfortheSprint.(RULE:EachTeamhasitsownSprintBacklog.)

    Incontrast,TeamsTrade,Margin,andNotDerivativeholdamulti-teamSprintPlanningTwotogetherina big room, since they are implementing strongly related items—whichwere also previously clarifiedtogetherinmulti-teamPBR—andtheyforeseevalueinworkingclosely.(RULE:Domulti-teamSP2inasharedspaceforcloselyrelateditems.)

    They talk together ina10-minute session to set the stage, identifyingsharedwork (common tasks)anddesignissues.Thentheystarttheclockforatimeboxed30-minutedesignsession,agreeingtovisualize:moresketchingon thewhiteboard, less talkingwithoutdrawing.During this time,moresharedwork isalsodiscoveredandwrittenontheboard.

    Ding!After30minuteslotsofunexploreddetailsremain,buttheteamsmoveonanyway.EachteamheadstoadifferentcornerofthebigroomwhereeachstartsitsownfocusedSprintPlanningTwo,talkingmoreaboutdetaileddesignissuesandcreating theirownSprintBacklogwithcards.Furthercoordination ishandledbyanadvancedvariationofthejusttalktechniqueinLeSS:justscream.

    Duringthetalking,theteamsrealizetheneedforanin-depthmulti-teamDesignWorkshop.Theyagreeto

  • holdonelaterthatday.

    Multi-TeamDesignWorkshop

    AfterSprintPlanningandanotherbreak,MiraandMarkfromTeamTrade,andafewpeoplefromTeamMarginandTeamNotDerivativeholdatimeboxedone-hourmulti-teamDesignWorkshop foradeeperdiveintoacommonandconsistentdesignfortheirwork.Aroundalargewhiteboardtheysketchandtalktogether towards some clarity and agreement on a design approach and common technical tasks.Fortunately,theconclusionsdon’tseriouslyimpacttheirexistingSprintplans,buttheyfeeluncomfortablewiththeirprocess,recognizingtheycouldhavepredictedtheneedtoresolvethesebigdesignquestionsearlier.

    DevelopmentActivitiesSupportingCoordinationandContinuousDelivery

    AfterSprintPlanning,theteamsdiveintodevelopingitems,withanemphasisoncommunicatingincode.All the teams are integrating continuously. The continuous integration of all code across all teamscreatestheopportunitytocooperatebycheckingwhoelsemadechangesinthecomponentbeingworkedon.That’suseful,becausethegroupusesintegrationasawaytoinformandsupporttheircoordination.

    Forexample,earlyduringtheseconddayoftheSprint,Mark,adeveloperonTeamTrade,pullsthelatestversionlocallyandquicklychecksthelatestchangesrelatedtothecomponenttheyareworkingonnow.Hediscoverschanges related tocodeaddedbyMaximilian fromTeamMargin.Heknows that teamisworkingonastronglyrelateditem,soheisnotespeciallysurprised.Sincethecodehascommunicatedthatnowthere’saneedtocoordinateandwhoheneedstotalkwith,heimmediatelyvisitsTeamMargindownthehall.They just talk abouthow towork together tobenefit fromoneanother’swork. (RULE:Preferdecentralizedandinformalcoordinationovercentralizedcoordination.)

    FortheitemthatTeamTradeisdeveloping,andinfactforeveryitemineveryteam,theyhavewrittentheautomatedacceptancetestsbeforestarting todevelopthesolutioncode.Thus, inaddition to integratingthe code continuously, they’re also integrating the automated tests. These acceptance tests are runfrequently by team members, and so when any of them fails, the teams are immediately signaled tocoordinate.Thecodeistellingthem,“Hey!There’saproblem!Youneedtotalkandworkitout.”

    Naturally,anothermajorbenefitofthegroup’spracticeofintegratingcontinuously,automatedtesting,andstopping-and-fixingwheneverthebuildbreaks,isthattheirproductismoreorlesscontinuouslyreadytodeliver into production. There’s no separate integration team or testing team that would add delay,handoff, and complexity. (RULE: The perfection goal is to improve the Definition of Done so that itresultsinashippableproducteachSprint,orevenmorefrequently.)

    OverallRetrospective

    On the second day of the Sprint, Sam and the other ScrumMasters, the Product Owner Paolo, a sitemanager,andarepresentativefrommostoftheteams,allgettogetherforamaximum90-minutesOverallRetrospective related to the last Sprint. (RULE: An Overall Retrospective is held after the TeamRetrospectivestodiscusscross-teamandsystem-wideissues,andtocreateimprovementexperiments.)

    Whydidn’ttheyholdthisOverallRetrospectivebeforethisnewSprintstarted?Theycouldhave,buttheynormallyendaSprintonaFridayandstartanewoneonMonday(incontrast toSam’ssuggestionthattheytryaWednesday–Thursdayboundary).AndonthelastFriday,theyheldboththeSprintReviewandthe team-level Retrospectives. After that they didn’t have the energy to hold an engaged OverallRetrospectiveat theendoftheday.Sothey’veoptedforanearlynextSprint.Samprivatelythinksthis

  • delayisnotagreatidea—he’drathertheystartedSprintPlanningalittlelaterafterthismeeting—buthewantsthegrouptodiscoverthatforthemselves.

    Theyfocusonasystem-wide issueand improvement:howtocoordinate,share information,andsolveproblemsacrosstheentiregroupduringtheSprint?PreviouslytheyhavetriedScrum-of-Scrummeetingsanddidn’tfindthemveryeffective.SamexplainsthetechniqueofOpenSpace,andtheyagreetotryitthisSprint.

    ActivitiesforCoordination(RULE:Cross-teamcoordinationisdecidedbytheteams.)

    ThefourthdaydemonstratesavarietyofcoordinationideasinLeSS:

    InLeSS,eachTeamholdsaDailyScrumasusual.TosupportcoordinationbetweenTeamsTradeandMargin,Miragoesasascout toobserveTeamMargin’sDailyScrumandthenreturnsandupdatesherteamonwhatshelearned.AndsomeonefromTeamMargindoestheopposite.

    As agreed in the Overall Retrospective, the group holds a 45-minute Open Space meeting forcoordinationandlearning,precededbydrinksandsnacks.Samactsasfacilitatortoteachthegrouphowto hold an Open Space meeting. Everyone is welcome, but most teams decide to send only a fewrepresentatives.MiraandMarkfromTeamTradejoinin.ThegroupplanstotryanOpenSpaceonceaweek.

    The Test community, with volunteers from most teams, gets together for a half-hour to hear Mary’sproposaltotryanewautomatedacceptance-testingtool.Theyenthusiasticallyagree,andMaryvolunteersher TeamMargin to do the actual experimental work next Sprint, since they are really interested inlearningthis.

    MiraisamemberoftheDesign/Architecturecommunity.There’snodesignworkshopneededthisSprintrelated to overall architecture, but she wants to hold a half-day spike in the next Sprint for a newtechnology.Shepostsher ideaon thecommunitycollaboration tool,andsuggests thecommunitydo thespiketogetherwithmobprogrammingtoincreasetheirsharedlearning.

    The build system seems to have a weird bug. Time to stop and fix! This Sprint, Team Trade isresponsibleforit,andit’soneofMark’ssecondaryspecialties,sohevolunteerstofixitandasksanotherteammembertopairupwithhimtohelphiscolleaguelearnmoreaboutit.

    Later,Mira and a few other teammembers visit the customer support and training group, who workcloselywithhands-onusers.Her teamhas finished their first itemand theywant togetearly feedbackfrompeople closer to customers.One of the trainers is free and he playswith the new feature. TeamTradeleaveswithafewideastomakeitbetter.

    Later in thedayMarkand the restofTeamTradearedoing tasks for their second item.Markhas justcompleteda10-minuteTDDcycleandhascleanstablecodeafteramicro-change.Onceagain—aboutevery 10minutes—he pushes the tiny change to the central shared repository (to “head of trunk”), tointegratecontinuouslywithhisteamandallothers.Heglancesovertotheirbigvisiblered-greenscreenonthewallandseesthatthebuildsystemispassingallthetestsfortheentiregroup.

    OverallProductBacklogRefinement(RULE:Domulti-teamand/oroverallPBRtoincreasesharedunderstandingandexploiting

    coordinationopportunitieswhenhavingcloselyrelateditemsoraneedforbroaderinput/learning.)

    Onthefifthday,MarkandMirajoinanoverallPBRworkshop,withrepresentativesfromeachteam,and

  • Paolo,theProductOwner.Paolostartsbysharinghiscurrentthinkingonproductdirectionandwheretogonextintheshorttermand,mostimportantly,why.Tohelpthemunderstandhisreasoning,hereviewshis prioritizationmodel with the group, that factors in profit impact, customer impact, business risk,technicalrisk,costofdelay,andmore.

    Paoloasksforfeedbackandideasfromthegroupforupcomingdirection,andthegroupdiscusseswhatitems to refine next. Although he knows that he’llmake the final priority calls,Paolo works hard toengagetheteamsinunderstandinghisthinking,andalsotolearnfromtheirthinking.Hewantstheteamstoalsobeinvolvedinowningtheproduct.

    Thegroupthensplitsafewbignewitems,doinglightweightclarification(morewillfollowlater),andplanningpokerestimationasawaytolearnmoreabouttheitems—ratherthantocreateestimates.

    Therepresentatives fromthree teams(includingTradeandMargin)decide to laterdomulti-teamPBRtogetherforsomeitemstoincreasetheirsharedunderstandingandbecausetheyarestronglyrelated.AndrepresentativesfromtwootherteamschooseitemstofocusonseparatelyinteamPBRsessions.

    Multi-TeamPBRandTeamPBR(RULE:AllprioritizationgoesthroughtheProductOwner,butclarificationisasmuchaspossible

    directlybetweentheTeamsandcustomer/usersandotherstakeholders.)

    Onthesixthday,everyoneinthreeoftheteamsgetstogetherforamulti-teamPBRworkshopinthebigroom.

    Althoughtheirmainbusinessiscreatingandsellingtheirtradingsolution,thecompanyhasasmallgroupofbondtradersthatuseit,withrelativelysmallpositionsthatkeepthemengagedbutwithouthighrisk.Thiswaythecompanyhasbetterinsightintomarkettrendsaswellassomeexpertusersthatcaneasilytalkwiththedevelopmentteams.

    TanyaandTedarethetraderswhotoldPaoloaboutatrendthatledtotheitemsbeingrefinedinthemulti-teamPBRsession.Sotheybothjoin,asexpertstohelptheteamslearnandclarifythenewitems.

    Theothertwoteams,indiscussionwithsomeothertraders,holdseparatePBRworkshopstocompleteclarification of some items already under refinement and to start on some new ones.Also, one of thecompany’sthreelawyersspecializinginfinancialregulationsandcompliancejoinsoneoftheseteamstohelptheminclarification.

    AsalaststepinthePBRmeetings,peopletakephotosofeverythingonthewallsandwhiteboards.Theyaddthosetothewikipagesthatareusedtorecordeverythingforeachitem.Plustheyupdateandcleanupthetextandtablesinthewikipagesthatwerequicklyaddedduringdiscussions.

    AChatAboutTeam-LevelBacklogsandProductOwners

    Afterthemulti-teamPBRworkshop,Mike(whojustjoinedthecompany)seesSambythecoffeemachineand walks over to talk. Mike says, “Hey Sam. I’m interested in your opinion on something. In therefinementworkshopwejustfinished,ofcourseInoticedthatwewereworkingdirectlywithsomeofthetraderstoclarifytogether.Butisn’tthatinefficient?Inmylastcompany,everyteamhaditsownProductOwnerwhodidthestorywriting,wireframes,andspecifications,andthengavethemtoustoimplement.Thenwecouldjustfocusontheprogramming.AndeachteamhaditsownProductBacklogthattheteam’sProductOwnerprioritized.ButIdon’tseethathere.Whyisitdifferent?”

    Samsays,“Interestingquestions.DoyoumindifIaskyouafewquestionstoexplorethis?”

  • “Sure,goahead.”

    “Let’sfirstconsideroneProductBacklogversusmanyteam-levelbacklogs.Supposeeachteamhaditsownbacklog.HoweasyandeffectiveisitforonetrulyoverallProductOwnertohaveanoverview?Andhowmuch knowledgewill a teamhave of the requirements and designs of items in a different team’sbacklog?”

    Mikereplies,“Icananswerthatprettyclearlyfrommylastcompany.Notmuch.”

    Samcontinues. “Nowsuppose there are eight teamsand eight teambacklogs.What if, from thehighercompanyorproductperspective,forsomereason,theitemsintwooftheeightteambacklogsareactuallybyfarthemostimportantorhighestpriority.Maybethere’ssomechangeinthemarketsothatthissituationcomesup.Sosomequestions foryou:Can thesix teamsworking in the lower-prioritybacklogseasilyshifttostartworkingonthehigh-priorityitemsintheothertwobacklogs?Andisitlikelythatthegroupwillevenseethisproblem,giventhattheyarelockedintoeachteamhavingtheirownbacklogandlocalpriorities?”

    Mikeanswers,“Ourteamsatmyoldplaceonlyworkedontheirownteamitembacklog.Theycouldn’tshifttoothers.Butwhywouldtheywantto?Isn’tthatinefficient?”

    Sam responds, “Well, from a company perspective, the teams are only working ‘efficiently’ on low-prioritystuffbecauseoftheirnarrowknowledgecreatedbyeachfocusinginadifferentteambacklogandbecausetheoverallpriorityandoverviewisn’tvisible.Letmeaskyousomequestions:Doesthatseeminflexibleorflexible—agile?Anddoesthatoptimizepeopleworkingonthehighest-impactstufffromthecompanyperspective?”

    Mikepauses,“Oh!IthinkIgetit.It’sactuallynotbeingagile,eventhoughourgroupsaidtheyweredoingagile.Weweren’tresponsivetothehighest-valuechangesoverall.AndmyoldteamProductOwnersaidshewas prioritizing for highest value in our teambacklog.But now I see thatmy teamwas just busyefficientlyworkingonwhatcouldbelow-valuestuffwhenyoulookat itfromahigherlevel.”(RULE:ThereisoneProductOwnerandoneProductBacklogforthecompleteshippableproduct.)

    Samsays,“Exactly.Sothat’soneofseveralreasonswhywehaveoneProductBackloghere,andnoteambacklogs, even though there are many teams. In short, it supports whole-product focus, systemoptimization, and agility. And of course it’s simpler, and it’s easy to see what’s going on across thegroup.”

    “Also,”Mikecomments,“Inoticeditwasmuchharderinmypriorcompanyforall theteamstoreallyworktogetheratthesametime,sincewewereworkingonverydifferentgoalsinasynchronousSprints.HereitfeelslikealltheteamshavemoreofacommonfocusanddirectioninoneSprinttogether.”

    “Exactly!”Samreplies,thencontinues.

    “Here’s another question: If there’s only one Product Backlog and one real Product Owner whoprioritizes it, but each team still had its own so-called Product Owner who per definition is notprioritizingateambacklog—sincethereisn’tone—thenwhatdotheydoalldaylong?“

    Mike replies,“Well, inmy lastcompany itwas the jobof the team-levelProductOwner to talk to theusersandwrite thestoriesfor the team,so theycouldfocusonefficientlyprogrammingwhile the teamProductOwnerworkedongatheringandwritingrequirements.”

    Samasks,“Mike,beforeyoulearnedaboutScrumtermssuchas‘ProductOwner’,whatwouldyouhavecalledmiddlemeninbetweenthedevelopersandrealcustomers—theonescollectingrequirementsand

  • thengivingthemtodevelopers?”

    “IjoinedmylastcompanybeforeweadoptedScrumthere.”Mikeanswers,“Andbackintheday,therewasagroupofbusinessanalystswhodidthat.AfterweadoptedScrum,wewereaskedtocallthemtheProductOwners.”

    “TodayinyourPBRworkshop,”Samasks,“Didyoutalkwiththetraderswhowerethere?”

    “Letme think back.”Mike replies, “Yeah, Iwas talkingwithTanya about her idea to analyze tradingRussiancorporatebonds.ItseemedalittleconfusingsoIaskedher,why?Sheexplaineditwasbecauseof concerns around money laundering in offshore accounts. Now, she didn’t know that we’ve beenrecentlyworking on some other features that integratewith newEU andUSA regulatory databases toassessthis.SoIproposedtoheradifferentapproach,whichIthink—andsheagrees—willbettersolvetheproblem.

    “NowthatIthinkaboutit,”hereflects,“thatprobablywouldn’thavehappenedinmylastcompany,sincewerarelytalkeddirectlywithusers.”

    (RULE:TheProductOwnershouldn’tworkaloneonProductBacklogrefinement;sheissupportedbythemultipleTeamsworkingdirectlywithcustomers/usersandotherstakeholders.)

    (RULE: All prioritization goes through the Product Owner, but clarification is as much as possibledirectlybetweentheTeamsandcustomer/usersandotherstakeholders.)

    MoreDevelopment

    Minutebyminuteanddaybydaytheteamsdevelopcode,integratingcontinuouslycombinedwithfulltestautomation.Theystopandfixwhenthebuildbreaks,workingtowardstheirperfectiongoalofhavingadoneshippableproducttheycancontinuouslydelivertocustomers.Therefore,whentheSprintisnearlyoverandtheteamsarepreparingtojointheSprintReview,there’snolatemadrushofefforttointegrateandtestabigbatchofcode—it’sbeenintegratedandtestedallalong.

    SprintReview(RULE:ThereisoneproductSprintReview;itiscommonforallteams.)

    Finally it’s the last day and time for an all-together Sprint Review.Who’s there? Paolo (the ProductOwner, lead product manager), all the internal bond traders, a few trainers and customer servicerepresentatives,afewpeoplefromSales,andfourusersfromexternalclientswhopaylowerannualratesinexchangeforparticipatingregularlyinthesereviews.Also,there’salltheteammembers.

  • Because there aremany items to explore, the group starts with a one-hour bazaar—something like asciencefair—withmanydevicessetupintheroom,eachavailableforexploringdifferentsetsofitems.Someteammembersstayatfixedareastocollectfeedbackwhileeveryoneelseusesanddiscussesthenewfeatures.

    Afteranhour,thegroupcomestogethertodiscussthequestionsandfeedback,inasessionledbyPaolo.Afterthat,theydiscussfuturedirection.Paoloshareswhat’sgoingoninthemarketandwithcompetitors,andhisthoughtsonwheretogonext,andasksforadvice.

    TeamRetrospectives(RULE:EachTeamhasitsownSprintRetrospective.)

    After a break,TeamTrade (and all other teams) hold separate team-levelSprintRetrospectives.They

  • decidethatholdingamulti-teamDesignWorkshopwithTeamMarginafterSprintPlanning(ratherthanearlier)wasfarfromidealinthiscase,becausemajorissueswereleftunexploreduntilthelastminute—issues which could have seriously blocked or complicated development. So for the next Sprint theydecide that during theirPBR sessions theywill strive to identify items that havemajor design issuesworthdiscussingwithotherteams.Andifso,holdamulti-teamDesignWorkshopassoonaspossible.

    TheEnd

    Sprint done!Sam invitesTeamTrade to joinMira andhimat theBelgian-beer pubdown the street—Mira’sfavorite—tocelebrateherbirthday.(RULE:BeerisBelgianTripelKarmeliet.)

    Summary

    Somekeypointsfromthestory:

    itemphasizedflowofpeopleandteamsthroughaSprintinLeSS

    itconnectedstoryelementstospecificLeSSguidesandrules

    forareaderwhoknowsScrum,theeventsshouldbefamiliar

    thestoryshowswhole-productfocus,evenwithmanyteams

    theactivitiesemphasizedteam-basedlearningandcoordination

    developitemsbyintegratingcontinuouslysothatcommunicatingincodesupportsdecentralizedcoordinationandjusttalking,inadditiontocontinuousdelivery

    teamsclarifydirectlywithusersandcustomers,toreducehandoffandincreaseunderstanding,empathy,andownership

    •LeSSStory:FlowofItems•

    This story focuses more on the flow of items (features) through part of a Sprint, primarilyduringrefinementanddevelopment.

    Portiawraps up hermeetingwith the government regulator and heads to the airport, and home. She’sanotherproductmanager;shehelpsPaolo,andspecializesinregulatoryandaudittrends.10

  • Later,PortiameetswithPaolo.Writingoncards,shesummarizesthenewrulesthataregoingtoimpacttheirproduct,andwhatclientsshethinksaregoingtowantcertainfeaturesfirst.Paolopointstothefivecards and asks, “So this covers all the work, as far as you know?” Portia smiles and says, “This isregulatory.It’sneverfinishedorclear.”

    Paoloasks,“CanyouputtheseintheProductBacklogforme,unorderedatthebottomfornow?”

    “Sure.”

    A week later Paolo tells Portia, “Soon, I want to start delivering some parts of the big regulatoryrequirementforbondderivatives.InthenextSprint’sProductBacklogrefinementworkshops,I’mgoingtoaskforsometeamstofocusonthat.Youknowthemostaboutit,sopleasebeattheoverallPBRandatwhateverteamrefinementworkshopswheretheywantyou.Also,canyousetupawikipagewithlinkstothenewregulatorydocs,tosharewiththeteams?”

    “Alreadydone,”answersPortia.

    OverallPBR

    PaolokicksoffaquickoverallPBRworkshop,“We’vegotlotsofworkaroundnewregulations.Soonweneedtodeliverrelateditemsbecauseofalegaldeadlineendoffiscalyear.We’llknowbetteraftersomesplittingandestimation,butIwouldn’tbesurprisedifitultimatelyinvolvesthreeormoreoftheteamsforimplementation,andlotsoftime.”

    Thegroupsplits thenewgiantitemintoonlyafewlargeparts, tolearnmajorelements.Moresplittingwillhappenlaterinasingle-teamormulti-teamPBRsession.Portiaheadstothewhiteboard;ontheleftsideshewrites“regulationsforbondderivatives.”Theninconversationwiththegroup,theysketchatreediagramwithfourarmsrepresentingasplittingintofourmajorsub-items.Buttheydon’tgoanydeeper—they’reavoidingover-analysis.

    Next,thegroupcreatesfourcardsforthenewitems,andeveryonetogetherestimatesthemwithplanningpoker and relative-size points, baselining the points against existing well-known items in the Product

  • Backlog.Theirmaingoal isnot tocreateestimatesbut tosurfacequestionsanddrivemorediscussion,whichtheydowithPortia.

    Next,Paoloasks,“SoPortia,ofthesefourbigones,whichonefirst?”

    Shepointstothesecondcard.“Over-the-counterexoticbondderivatives.”

    Paolosays,“Weneedtostartdeliveringsomeofthatassoonaspossible.It’smovingwayuptheProductBacklog.SoI’dlikeoneteamtotakeabiteintothis,nextSprint.Who’sinterested?”

    TeamTradevolunteers.

    Finally, teammembers from three other teams decide to hold amulti-teamPBRworkshop for relateditems.

    TeamPBR:BitingIn

    ThenextdayTeamTradeholdsateamPBRworkshopwithPortia.Theyhaveonlyoneofthefourgiantitemstofocuson:Newregulationsforover-the-counter(OTC)exoticbondderivatives.Sam(theirScrumMaster) is also there. Portia says, “This is a gigantic complex item, in an area that frankly nobody isreally clear about. It’s going to takeus a long time to split thisup, reallyunderstand it, and specify itwell.”

    Samasks,“Dowereallyneedtounderstandallofit?Andwillallthatanalysisteachusmore,orcoulditactuallydelayourlearning?”

    HereviewswiththemtheideaofTakeaBite:tojustsplitoffonetinyfragment,reallyunderstandthat,andimplementitquickly.Samconcludes,“Youknow,diagramsdon’tcrashanddocumentsdon’trun.”

    WithPortia,theteamsplitsoffonetinybiteofathincustomer-centricend-to-enditem.

    Fromnowontheywillfocusonthattinybite,clarifyingandimplementingit.Onlyafterimplementationandfeedbackwilltheyreturnmuchlatertomoresplittingandrefinement.UsingspecificationbyexamplePortiaandTeamTradespendtherestofthedaychewingontheirbite.

    Multi-TeamPBR:RotationRefinement

    OneoutcomeofoverallPBRwasthedecisiontotakeabitewithTeamTrade.Anotherwasthedecisionforthreeteamstoholdamulti-teamPBRworkshopforrelateditems,toincreaselearningandtheagilityofmultipleteamsknowingandthinkingaboutthesameitems.

    Inadditiontoeveryonefromthethreeteams,theinternaltradersTanya,Ted,andTravisjointohelptheteamsstartclarifyingaboutadozennewitems.(RULE:AllprioritizationgoesthroughtheProductOwner,but clarification is as much as possible directly between the Teams and customer/users and otherstakeholders.)

    To start, they form three temporarymixedgroupswithpeople fromeach team.Themixedgroups startclarifyingdifferentitemsinseparateareasintheroom,eachwithawhiteboard,bigwallspace,laptop,andprojector.Tanyaiswithonegroup,Tedanother,andTravis,thethird.

    Then they do rotation refinement: After 30minutes, a timer goesding!One groupwalks over to theother’sarea,andviceversa,butTanya,Ted,andTravisdon’tmove.Thetimerisrestarted, thetradersexplainthecurrentresultstotheincominggroups,andtheycontinueclarifying.

  • Figure2.1multi-teamPBR

    Throughout theday, asdifferent itemsbecome relatively clear—or are leftwithhangingquestions thatwillhavetobeexploredlater—newitemsareintroducedataworkarea.Someofthebiggeritemsaresplitintotwoorthreenewsmallerones.

    Afewtimesduringtheday,thegroupsstoptheirclarificationanddosomeestimation,mostlytolearnandtopromptconversation.They’reusingrelative(story)points;toremainsynchronizedagainstacommonbaseline,theycalibrateagainstsomealreadycompletedandwell-knownitemsintheProductBacklog.

    UpdatingtheProductBacklogandProductOwner

    ThedayafterthePBRworkshops,Portiaandafewteammembers

    updatetheProductBacklogwiththenewsplititemsderivedfromtheoriginalones,anddeletetheoriginals

    addlinkstothenewwikipagesofitemdetails,createdinthePBRworkshops

    recordnewestimates,anditemsreadyforimplementation

    Later, Portia and those teammembersmeetwith Paolo to review theProductBacklog changes and toanswerhisquestions.

    TheEnd

    Somekeypointsfromthestory:

    TakeaBiteonagiantitemtolearnfromdeliveryofsomethingsmallandtoavoidprematureandexcessiveanalysis.

    Domulti-teamPBRforitems,forsharedknowledgeacrossteams,whichincreasesorganizationalagility,broadenswhole-productknowledge,andfostersself-organizedcoordination.

    Striveforwhole-productfocus,evenwithmanyteams.

  • Next—ThenextsectionshiftstotheLeSSHugeframework,usedforlargegroupsofmanyteams.

    LeSSHugeFramework

    •RequirementAreas•

    With1000orevenjust100peopleononeproduct,divide-and-conquerseemsunavoidablebecauseofthecomplexityofsomanyrequirementsandpeople.Traditionallarge-scaledevelopmentdividestheseways:

    single-functiongroups(analysisgroup,testgroup,...)

    architectural-componentgroups(UI-layergroup,server-sidegroup,data-accesscomponentgroup,...)

    Thisorganizationaldesignyieldsslowinflexibledevelopmentwith(1)highlevelsofwaste(inventory,work-in-progress, handoff, information scatter, ...), (2) long-delayed ROI, (3) complex planning andcoordination,(4)moreoverheadmanagement,and(5)weakfeedbackandlearning.Andit isorganizedinwardaroundsingle-skills,architecture,andmanagement,ratherthanoutwardaroundcustomervalue.

    But in theLeSSHuge frameworkwhen above about eight teams, division is aroundmajor areas ofcustomerconcernscalledRequirementAreas.Thisreflectsthecustomer-centricLeSSprinciple.

    Size—ARequirement Area is big, usually with between four and eight teams, not one or two. ThefollowingAreaFeatureTeamssectionexplainswhy.

    Dynamic—RequirementAreasaredynamic.Over time an areawill change in importance, and then itgrowsorshrinkswithteamsjoiningordeparting—mostlikelytoorfromanotherexistingarea.

    Example—Forexample, inaSecurities product (to trade stocks), thesecouldbe somemajorareasofcustomerinterest—RequirementAreas:

    tradeprocessing(frompricingtocapturetosettlement)

    assetservicing(e.g.handlingastocksplit,dividends)

    newmarketonboarding(e.g.Nigeria)

    Conceptually in the one Product Backlog, a Requirement Area attribute is added, and each item isclassifiedintooneandonlyonearea:

  • ThenpeoplecanfocusononeAreaProductBacklog(conceptually,aviewontooneProductBacklog),suchasthemarketonboardingarea:

    Common Sprint—Does each Requirement Area work separately in its own Sprint, with delayedintegrationuntilafar-futuredate?No.

    InLeSSHuge,IntegrateContinuouslyinOneCommonSprint

    Thereisoneproduct-levelSprint,notadifferentSprintforeachRequirementArea.Itendsinoneintegratedwholeproduct,andalltheteamsacrossalltheRequirementAreasarestrivingto

    integratecontinuouslyacrosstheentireproduct.

    •AreaProductOwners•

    InLeSSHuge one new role is introduced.EachRequirementArea has anArea ProductOwner whospecializesinthatareaandfocusesonitsAreaProductBacklog.

    Largeproductgroupsusuallyhaveseveralsupportingproductmanagersspecializingindifferentcustomerareas,andsomeofthesearelikelytoserveastheAreaProductOwners.SometimestheProductOwneralso servesdoubledutyasanAreaProductOwner foronearea; that’smore likely in small less hugeLeSSHugegroups!

    •AreaFeatureTeams•

    Area feature teamsworkwithin oneRequirementArea (e.g. asset servicing),with oneAreaProductOwnerfocusingon the items inoneAreaProductBacklog.Froma team’sperspective,working in thearea is likeworking in thesmallerLeSS framework—they interactwith theirAreaProductOwnerasthoughsheweretheProductOwner,andsoon.

    Theteammemberscometoknowthecustomerdomainofthatareawell.Andfortunately,theitemsofoneRequirementAreatendtocoverasemi-predictablesubsetoftheentirecodebase,therebyreducingthescopeofwhattheyhavetolearnwellwithinavastproduct.

    Keypointaboutsize:ManyfeatureteamsworkinaRequirementArea.

    ARequirementAreanormallyhasfourtoeightteams.AnimplicationisthataRequirementAreaisbig.

  • TheMagicNumberFour

    First,whydoesaRequirementAreahaveasuggestedupperlimitofeightteams?SeeTheMagicNumberEight.

    What about the lower limit of four teams?Why not one or two teams? Naturally, four isn’t a magicnumber, but it strikes a balance so that the product group is not composed ofmany tiny RequirementAreas.

    What’s the problemwithmany tiny areas?They reduce visibility into overall product-level priorities,increaselocaloptimizations,increasecoordinationcomplexity,requiremorepositions,andcreateteamsthatare toonarrowlyspecializedand lack theflexibility(agility) to takeon theemerginghighest-valueitemsfromacompanyperspective.Furthermore, ina tinyarea theAreaProductOwner is increasinglylikelytoactasabusinessanalystbetweentheusersandoneortwoteams.

    Arethereanyreasonableexceptionstothelowerlimitoffour?Yes:

    Anearlytransitionalsituationwhenthegroupisincrementallygrowinganewareathatisfullyexpectedtoultimatelyhavefourormoreteams.Then,startsmallandsimplewithoneteam.

    Whenre-balancingteamsfromanareawithadecreasingdemandtoonewithanincreasingdemandcausesanareatogofromfourtothreeteams.Ultimately,mergetworeducedsmallareasbackintoanewlargerarea.

    ExampleRequirementAreasandTeams

    Insummary,aSecuritiesproductcouldhave

    oneProductOwnerandthreeAreaProductOwners,alltogetherformingtheProductOwnerTeam

    sixfeatureteamsinthetradeprocessingarea

    fourfeatureteamsinthemarketonboardingarea

    fourfeatureteamsintheassetservicingarea

  • •LeSSHugeFrameworkSummary•

    EachRequirementAreaworksasa(smallerframework)LeSSimplementation,eachworkinginparallelinoneoverallSprint.WesometimessummarizeaSprintinLeSSHugeasastackofLeSS.

    Fromtheviewpointofateaminonearea,LeSSHugelookslike(smaller)LeSSregardingevents.

    AswithLeSS,therearerulesandoptionalguidesforLeSSHuge;thoseareintroducedinthefollowingstoriesandfleshedoutinlaterchapters.

    Roles—Same as LeSS, plus two or more Area Product Owners, and four to eight Teams in eachRequirement Area. The one Product Owner (who focuses on overall product optimization) and theseveralAreaProductOwnersformtheProductOwnerTeam.

    Artifacts—Same asLeSS, plus aRequirement Area attribute in the one Product Backlog and thus anAreaProductBacklogviewforeacharea.

    Events—There isstillonlyonecommonSprint for theproduct; it includesall the teamsandends inacommonpotentiallyshippableproductincrement.

    •LeSSHugeStories•

    Learning LeSS Huge—Readers who prefer exposition can comfortably skip ahead to followingchapters,bypassingthesestories.

    Simplestories—TheseareintentionallyplainandsimplestoriesjusttointroducebasicsinLeSSHuge.

    Twotopics—Followingaretwostorieswithdistincttopics:1.CreatingandgrowinganewRequirementAreatodealwithanewgiganticrequirement.2.Workingwithmulti-siteteams.(ThishappensinthesmallerLeSSframeworktoo,butisespeciallycommoninLeSSHuge.)

  • •LeSSHugeStory:ANewRequirementArea•

    Priti welcomes Portia to her first day in her new job.11 As a mid-level Operations manager in theSecuritiesdivisionofthelargetradingcompanyaswellasProductOwner for their internalSecuritiessystem, Priti is also responsible for finding and retaining talent for her ProductOwner Team ofAreaProductOwners.AndshethinksPortiaisafantasticfind,asherexpertiseisexactlywhatisrequiredfordealingwithsomenewhugerequirements.

    During the recent job interview—when Portia was still a product manager specializing in regulatoryissuesatacompanythatmadeasystemfortradingbonds—Pritihadlaidoutthesituation.“Portia,afterthelastcrash,theregulatorsarecomingdownhardandtheyrequireustobecompliantwithDodd-Frank.Rightnow,wedon’tknowwhatitexactlymeansorhowitwillimpactoursystem.You’vegotincredibleknowledge of this space, and a great professional networkwith the regulators. Iwould love it if youwouldjoinourgroupandhelpusfigureouthowtodealwiththis.”

    ABigSurprise

    Afewdayslater...PritiwelcomesPortia,Peter,andSusanintoheroffice.PeterisAreaProductOwnerformarketonboarding,andSusanisaScrumMasterfromthetradeprocessingarea.

    Pritisays,“Asyouknow,Dodd-Frankiscoming,andit’shuge.Whatyoudon’tknowisthatthismorningtheregulatorscalledusandtheywantustotakeactionnow.I’dbeenworkingundertheassumptionwecouldstartnextyear.Sowe’regoingtohavetoadapt,bigtime.

    “Idon’t thinkanyone isclearwhat itmeans indetail—eventheregulators.Andwedon’tknowhowitwillimpactoursystemandhowmuchworkthisisgoingtotake,otherthan,alot!ButnowPortia’sjoinedusandshehasabetterunderstandingofthisthananyone,althoughshe’stotallynewtooursystems.So,howcanwehelpherstarttacklingthismountainofwork?”

    Susanasks,“YouguysunderstandtheDyslexicZombies,right?”

    PeterandPritinod.Everyoneknowsabout them—and it isn’t just theirname.TheDyslexicZombies12haveprobablythebroadestexperienceofalltheteams.They’vebeenaroundforyearsandtheywereatrue pain in the asswhen they adopted LeSS. The team contained two formermembers of their now-abandonedarchitecturegroupandacoupleofpeoplewhohadbeenworkingonthesystemforoverfifteenyears.Thosepeople’sresistancetotheLeSSadoptionwaslegendaryastheywereafraidthey’dlosetheir“systemperspective.”To their surprise, theoppositehappened!Becauseof theirdeepknowledge theycontinuously get tough items to develop. And they regularly participate as expert-teachers in current-architecture-learningworkshopswithnewcomers,andMario—oneoftheformerPowerPointarchitects—isnowcoordinatorforthearchitecturecommunity.Whenfedenoughbeer,he’lladmitthatworkingcloserwithcodeandtestshasincreasedhisrealunderstandingofthesystem.

  • Susancontinues,“IfanyteamcanquicklyhelpPortiagetabetterunderstandingofthesizeandimpactofDodd-Frank,it’llbetheZombies.AndtheyledtheworkonSarbanes-Oxleyafewyearsago.Tomorrowis their PBR session. They are just about wrapped up on a new feature.Why don’t we re-direct themeetingtoincludetheminadiscussiononDodd-Frank,andsoonafter,askthemtofocusfull-timeonit?”

    RefiningwithZombies

    NextdayattherefinementmeetingwiththeZombies,Portiaexplainsthesituation,“You’veprobablyallheardabout theDodd-Frank legislation.Buthere’s thesurprise:We’ve justbeen toldby the regulatorsthat theywant us to take action ‘now’ and demonstrate significant compliance by the end of the year.Otherwisetheymightrestrictourtrading.”

    TheZombiesarevisiblysurprised.Theyhadheardrumorsbutdidn’texpectsucharush!

    Mario says, “OK Portia, give us a quick summary of what this means. And how is it different fromSarbanes-Oxley?”

  • Portiapicksupapenandstartssketchingonawhiteboard.Afterabout45minutes,sheisfinishedwiththeoverviewandtheZombieslookedalittlestunned.

    “Endoftheyear,theysaid?”saysMario.“Ifthewholegroupstartedtoday,itwouldn’tgetfinished.Thisishuge!”

    Hetakesapenandatthewhiteboardstartsaroughsketchoftheirsystem,talkingwiththeotherZombiesabouttheimpactitmighthave.

    Hesays,“Portia,let’salsousethisasachancetohelpyouunderstandthesystembetter.Askaway.”

    Portiasays,“Canyouholdonforasecond?Letmestartavideorecordingtohelpmerememberthis.”

    Michelle,aveteranintheteam,says,“We’dbetterstartonsomerealdevelopmentsoonandlearnmoreaswegobecauseotherwisewe’llendupanalyzingforever.I’veseenthisstorybefore.”

    Susan,theirScrumMaster,says,“Remindsme...TomDeMarcooncesaidthatthereasonforeveryfailedprojectisthatitstartedtoolate.”Everyonelaughs.Shecontinues,“Sohere’sasuggestion:takeabite.”

    CreatingaNewRequirementArea

    The next day, Portia, Priti, and rest of theProductOwnerTeammeet. Portia shares a summary of thescopeassheunderstandsitnow.

    Priti says, “This is even bigger than I expected, andwe need to show some tangible progress to theregulatorswithinafewmonths,andmajorprogressbeforefiscalyearend—sevenmonthsfromnow.Tostatetheobvious,they’renowauthorizedtorequiremorefromus,andwiththepowertoshutusdown.Asyouknow,just lastmonththeCEOmadeitcrystalclear thatnewregulatoryrequests takepriorityoveranyotherconcern.It’smyexperiencethatourgoodwillandflexibilitywiththeregulatorsgoesupifwecangivethemsomethingearly,andbetransparentandresponsive.Sothat’swhatwe’regoingtodo.”

    Priticontinues,“It seems tome thatwe’llneedanewarea for thisbig surprise.Andofcourse that’sprobablygoingtoimpactsomeofourexistinghigh-prioritygoals,sincewe’llhavetoshiftsometeams.Let’sprepareforadeeperdiscussionofoverallprioritizationimpactinacoupleofdays.Butfornow,I’dlikeyourinputaboutspinningupanewarea.”

    Afterashortdiscussion,it’sclearthateveryonerecognizestheimportanceofcreatinganewarea.

    Pritithensays,“Portia,Iknowyouarenewtous,butdoyouthinkyouwouldbeabletohandletheAreaProductOwnerresponsibilityforthis?”

    Portianods.

    Priticontinues,“Peter,doyouthinktheZombiescouldstartworkonthis?Andwe’llneedthemtolearnmoreDodd-Frankandfigureouttheimpactonoursystembeforewecanaddmoreteamstothis.”

    Petersays,“Idon’tthinkwe’vegotanychoice.”

    Pritisays,“OKPortia,socurrentlywe’vegotafewitemsinPeter’sAreaBacklog,theonehugeitemIthinkyoucalled“remainderofDodd-Frank”andthetinyitemwhichtheZombiesandyousplitoffofit.PleaseaskPetertoshowyouhowtosetupanewareaintheProductBacklogandmovetheitemsovertoit.”

    Priticontinuesaddressingthegroup,“ThenextSprintstarts in threedays.Let’smovetheZombies intoyourareaandgetstartedonthismonster.ProbablyinacoupleofSprintswe’llbereadyto—andneedto—grow your area by moving in another team. Folks, please think about two major concerns: First,

  • preparingforaseriousprioritizationimpactmeetinginafewdays.Andsecond,whatotherteamswillbegoodcandidatesforthenewarea.”

    SprintPlanningintheNewRequirementArea

    EachRequirementAreaholdsitsownSprintPlanningmeetings,allmoreorlessinparallel.InPortia’snewarea,shestartsherSprintPlanningbyintroducingtwounfamiliarfacestotheZombies.

    Shesays,“GillianandZakhavebeenincontactwiththeregulatorsregularlyandwillhelpusfleshthisthingout.They’veagreedtohelpusnowinPlanning,duringourPBRsessions,andasmuchastheycansparedailyduringupcomingSprints.”

    Shecontinues,“Here’smytentativeplanofattackforthenexttwoSprints.First,togetherweneedtolearnmoreaboutDodd-Frank,andalsosplititintosomemajorandmanageablepiecessowecanstarttoclearthefogandgetabettersenseofpriorities.

    “Second, we implement the smaller bite we’ve taken, starting this Sprint. That’ll give us betterinformationabout the realworkand the impactonourproduct.Andwe’llhave someconcretevisibleprogress.

    “Third, we prepare for more teams to join our area. What do you think of this approach? Othersuggestions?”

    During the short discussion, Mario says to his team, “Let me give a bit more context, because IrepresentedourteamintherecentProductOwnerTeammeetingwithall theAreaProductOwnersandPriti.Tostartwith,it’sjustustostart.We’regoingtotaketheleadonearlyimplementation,andgettingthebigpictureoftheitem,andunderstandingtheoverallimpactonourarchitecture.”

    Michelleinterrupts,“Likeatigerteamworkingonanewproduct?”

    “Yes, like that,” says Mario. “Think of Dodd-Frank support as a new product that needs to becontinuouslyintegratedintotherestoftheproduct.Butwe’reinahurryandit’satonofwork,soinafewSprintsonemoreteamwilljoinusandshortlyafter,probablytwomoreteams.Wekeepdevelopingtoo,butwe’llbethe leading team,whichmeanswe’llneed tobring theother teamsup tospeedandmakesurewekeeptheoverallproductinmind.”

    Michelle says, “It’s starting to sound to me like we’re going to become the architecture and projectmanagementteam!”

    Mariolaughs,“No.I’mdonewiththat.We’restillanormalfeatureteam,butbesidesdevelopmentwe’llfocusonmentoringandbringingthenewteamsuptospeedasfastaspossible.Butlet’sbeclear:teamcoordinationandmanagementisstilltheresponsibilityofeachteam.”

    TheFirstSprintintheNewRequirementArea

    Their first Sprint is an unusual balance of clarification versus development, but nevertheless quiteusefulinthisextremesituation.TheyspendalmosthalftheSprintinclarificationwithPortia,Gillian,andZak.That’sbecauseevenforthisextremelysmallbite,tryingtounderstandwhatiswantedintheobscurerealm of new government regulations—with no direct access to the politicians and policy writers—requiredalotofinvestigation,reading,discussion,andcommunicatingwithoutsiders.TheyexpectthatinfutureSprints,theamountoftimeneededforclarificationwillsoondropdowntoamorecommon10%or15%oftheirSprint.

    AndsotheyalsoonlyspendabouthalftheSprintdevelopingonesmallitem.Butthediscussionandthe

  • learningfromcodingpaysoff.SlowlybutsurelytheystarttosplitDodd-Frankapart—atleastthepartsthatanyofthemcanunderstand.

    While implementing the small item they had bitten off first, they spend much of the time together atwhiteboards todiscuss theoveralldesign implicationson the system.The teammoves frequentlybackandforthbetweenthecodeandthewall.

    SprintReviewintheNewRequirementArea

    The overall Securities product group works together in one Sprint, with one final shippable productincrement.ButeachRequirementAreaholdsitsownSprintReview,allmoreorlessinparallel.

    InPortia’sarea,duringtheirReview,she,Gillian,andZakexploretheone“done”itemthattheZombieshavemanagedtocompleteandintegrateintotheoverallproduct.Theyhadoriginallyforecasttwoitems,butPortiaisimpressedthattheygotevenonedone,givenhowfastthisnewworkwasthrownatthem.

    TheSecondSprint

    InthesecondSprintthey’reabletomakeslightlybetterprogressonitems,thoughtheyonceagainspendalotoftimeclarifyingtogetherwithPortia,Gillian,andZak.

    In themiddleof theSprint theyholdamulti-teamPBRsessionwith thesecond teamthat isplanned tosoonjointhearea,teachingthemaboutDodd-Frank.Theyholdacurrent-architecturelearningworkshoptointroducetheteamtothemajordesignelementsalreadyinplace.

    TheZombiesknowhowbigtheworkisandlookforwardtomorehelp.

    ProductOwnerTeamMeeting

    AfewSprintslater...It’stimeoncemorefortheper-SprintProductOwnerTeammeeting.TheyuseittoalignandcoordinatebetweenthedifferentAreaProductOwners,andforPrititogiveguidance.

    TheAreaProductOwnerseachshareinturntheirsituationandupcominggoals.Whenit’sherturn,Portiasays,“Tononeofoursurprise,theprogressislittleandthesurprisesarebig.ButthefogisclearingandtheteamsandIaregettingourheadsaroundthework.GillianandZakhavebeentremendoushelp.”

    Pablo, theAreaProductOwnerofasset servicing,commentsonsomeclose itemrelationshipshenowseesbetweentheirareas.PortiaagreestomeetwithPabloandsometeamrepresentativeslater.

    Pritiasks,“Portia,aboutourupcomingSprint.Whatareyourgoals?”

    AddingaThirdTeam

    TwoSprintslater...AttheProductOwnerTeamcoordinationmeeting,Pritisays,“Asyouknow,Portia’sareastillhasonlytwoteams.IknowthatPablowouldliketokeephissixteamsinassetservicing,butDodd-Frankisjusttooimportanttomethisyear.Sowe’regoingtomoveoneteamfromPablo’sareaintoPortia’s.Pablo,pleaseaskforavolunteerteamfromyourgroupandletmeandPortiaknow.”

    TheEnd

    SomekeypointsfromthestoryinLeSSHuge:

    TheProductOwnerisresponsibleforfindingAreaProductOwnersanddevelopingtheirtalents.

    TheProductOwnerisresponsiblefordecidingtostart,grow,orwinddownRequirementAreas.

  • RequirementAreasarelarge,normallyrequiringfourtoeightteams,butduringinitialstartuptheymaybesmaller,especiallyifinitiatedwithoneteamusingaTakeaBiteapproach.

    ALeadingTeamworkssolototackleagiganticitemuntiltheyunderstandthedomainanddevelopment,andthentheycoachmoreincomingteamstohelpwiththevastwork.

    •Multi-SiteTeams:Terms&Tips•

    NextisaLeSSHugestoryinvolvingmulti-siteteams.Butfirst,someclarifyingdefinitions,becausethecommontermdistributedteamsconfusinglymeansseveralthings.Theclarifyingtermsareasfollows:

    dispersedteam—Oneteamof(e.g.seven)peoplespreadoutindifferentlocations;eitherdifferentrooms,buildings,orcities

    co-locatedteam—Oneteamworkingliterallyatthesametable

    multi-siteteams—Oneco-locatedteamworkingatonesite,andanotherco-locatedteamworkingatanothersite

    Second,anobservationandguidance:

    Adispersedteamisrarelyarealteam;itismuchmorelikelyalooselyconnectedgroupsofindividuals.Thecommunicationandcoordinationfrictionsarehigher,andtheyseldomjellasateam.

    Whenyourproductgroupis50or500people,dispersedteamsaren’tnecessary.Eachteamofseven-ishpeoplecaneasilybeco-located.However,someteamsmaybeindifferentsites,sothattheproductgrouphasmulti-siteteams.Dispersedteamsareusuallytheresultofbadorganizationaldecisionsandignoranceaboutthecostofnothavingco-locatedteams.(Rule:Eachteamis(1)self-managing,(2)cross-functional,(3)co-located,and(4)long-lived.

    •LeSSHugeStory:Multi-SiteTeams•

    PortiaistheAreaProductOwnerforanewRequirementAreainaSecuritiestradingsystem.Thenewarea startedwith justone team for focusand simplicity.A fewSprints laterPortia’s areaaddsa thirdteam.Her first two teams are based inLondonwithher.But her thirdnew team,HouseDraculesti, isbasedinClujRomaniaatamajordevelopmentsiteforthecompany.

    Whynot add a third team from theLondon site?Thatwould have avoided themany aggravations andefficiencypenaltiesthatcancomefrommulti-sitedevelopmentwithinonearea—costspotentiallysohighthataddingateamcaneffectivelyresultindeletingateam.

    Butonthepositivesideinthiscase,ClujisonlytwotimezonesfromLondon,andeveryonetherespeaksEnglishwell.And theyareall strongdeveloperswithComputerSciencedegrees, in a city thatvalueslong-termandhands-onengineeringmastery.Also, this isadedicated internaldevelopment site for thecompany, so these are experienced internal teams that have in-depth knowledge of the product anddomain.

    Andbottomline,Priti(theProductOwner)didn’twantanyoftheotherLondonteamstoshiftfromtheircurrentareas.

    Priti knows thatmulti-site teamsare anewsituation forPortia, and so at their nextmeeting, she says,“PleaseaskyourScrumMastertotalkwithSita,andalsoaskSitatocoachsomeofyourevents.She’sa

  • ScrumMasterinassetservicing,andshe’sobservedtheirmulti-sitesituationforafewyears.SheknowstheimportanceofScrumMastersco-locatedwiththeirteams,andshe’shelpedfacilitatemanymulti-sitemeetings.”

    Priti continued, “Also, we’ve had a super profitable year, so I’m providing funding for you and theZombiesteam—atleastthosethatcantravel—tospendaSprintinClujassoonaspossible.Workcloselywith them, all in one room.TheCluj teamcould comehere toLondon, but youwant to send a strongsignalthattheyareimportant,attheirsite.TrytoavoidmakingthemfeelthatLondonismoreimportantthanCluj.Oh—andyou’llwanttoregularlyvisiteveryfewmonths.”

    Multi-SiteSprintPlanningPartOne

    A few Sprints later, Portia walks into the room. There’s a computer projector attached to a laptop,displayingviavideoa room inCluj.Thewhole team inCluj are sittingandwaiting.Sita suggested itwouldimprovelearningandengagementiftheentireClujteamparticipatedinmulti-sitemeetingsforthefirstfewmonthsoftheiradditiontothearea.

    Alltheteamrepresentativeshavetabletsorlaptopswiththem.

    Portiabegins.“Welcomeandlet’sgetstarted.MyofferofitemsthisSprintarehighlightedinthesharedspreadsheet.Canyouallseeit?Ithinkyouallunderstandwhythesearethethemesandpriorities,sincewe’vebeendiscussingthisinPBRanditreflectsyourinputandmine.Butpleaseaskagainifyou’dlikeclarification.Otherthanthat,you’reinvitedtoenteryourteamnamesbesidetheitemsyouwant.”

    Thatdone, thegroupenters aQ&Aphase towrapup lingeringquestions about the items.TheLondonrepresentativestapeupsomeflip-chartpapersandstartwritingquestions.TheClujteammembersentertheirquestionsinseparatesheetsofasharedspreadsheet.Portiaspendssometimeatthedifferentpaperflipcharts,discussinganswersandsketchingonthepaper.Andshespendssometimeatthespreadsheet,typinginanswersfortheClujteam,whilealsotalkingwiththemface-to-faceviathevideosession.

    Afterabout30minutestheseparatequestionshavebeenresolved,andPortiaaskseveryonetocomebacktogether.Shesays,“Anyissuesorquestionsthatyouwanttodiscusstogether,beforewewrapup?”

    Multi-SiteOverallPBR

    PeopleentertheworkshoproominLondonformulti-sitePBR.Twoprojectorsaresetup.OneshowsavideosessionoftheworkshoproominCluj.TheotherdisplaysabrowseronPortia’scomputer.

    Portiasays,“Let’sgetstarted.Iwanttofocusonsplittingsomeitems.I’veinvitedZaktojoinusbecauseheknowsquitealotaboutthis.”

    Usingamind-mapping,browser-basedgraphicstool,Zakstartstocreatesomebranches,whilediscussingwiththegroup.

  • Afterwards,theyuseasharedspreadsheettodiscussandwriteasingleexampleforeachofthenewsplititems,sothatthepeopleatbothsitesgainalightweightbutconcreteunderstandingofthedetails.Later,thegroupdoesestimationofthenewitems,usingespeciallybigplanningpokercardsthatcanbeeasilyseenbythecamerasandvideowhenheldup.

    TheEnd

    Somekeypointsfromthemulti-sitestoryinLeSSHuge:

    Multi-siteteamsfrequentlycreatebothobviousandsubtlefrictionsandcoststhataresurprisinglylargeintheirnegativeimpact.

    Qualitiesthatreducethefrictionofanothersiteincludesimilartimezone,internaldedicatedsite(notoutsourced),developersthatarefluentinthesamespokenlanguage,alocationandculturethathighlyvalueslong-termhands-ondeveloperexcellence.

    AScrumMastermustbeco-locatedwiththeirteams.

    Eachsitemustfeellikeapeer,notasecond-classcitizen.

    Sitesmustbevisitedregularlyandcross-pollinated.

    Inmeetings,striveforface-to-facewithvideotools.

    Theuseofshared-documenttoolsmakeiteasyforeveryonetomodifyartifactstogetherandatthesametime.

    OnwardsRather thanasking,“Howcanwedoagileatscale inourcomplexandawkwardorganization?”,askadifferent and deeper question, “How can we simplify the organization, and be agile rather than doagile?”AndsincetrulyscalingScrumstartswithchangingtheorganizationratherthanchangingScrum,the next major section focuses on understanding and adopting a simpler customer-focused LeSSorganization.

    This is followedbymajorsectionsonamorecustomer-focusedproductandSprint ina simplerLeSS

  • organization.

    EndNotes1.PleasereadthePrefaceforwhychaptersstartwiththissection,therepeatingmajorstructureineachchapter,definitionofsomekeyterms,andstylepoints.

    2.LeSSsuggestsbothLarge-ScaleScrumandsimplifyingwhenscaling—less.3.NokiaNetworksisnotthemobilephonefirmacquiredbyMicrosoft.4.Seethecasestudiesatless.worksformoreexamples.5.Scrumalsohasafewrulesforitsframework,forthesamereasonsasLeSS.6.Thesystemiseveryoneandeverythingfromconcepttocash,andallitsdynamicsintimeandspace,primarilyfromthecustomeranduserperspective.

    7.Tohelpremembercharactersandroles,namesuseanalliteration;e.g.MiraateamMember,SamaScrumMaster,PaoloaProductOwner.

    8.Inthesestories,LeSSrulesarestated,tomakeconnections.9.Inproductcompanies,theproductmanagementorproductmarketingroles—incollaborationwithteams—focusonvisionanddirection,encourageinnovation,analyzecompetitors,anddiscovercustomerandmarketneedsandtrends.Ininternaldevelopmentgroups,thisrolemightbefilledbyaleaduserinanoperationalbusinessgroup.TheProductOwner—theowneroftheproduct—inScrumandLeSStypicallycomesfromtheseroles,suchasPaolotheleadproductmanagerservingasProductOwner.SeetheProductOwnerchapterformore.

    10.Inadditiontoaleadproductmanager—whooftenservesasProductOwner—manylargegroupshaveafewsupportingproductmanagers,eachspecializinginamajormarketsegmentorcustomerarea.

    11.Reminder:Namingusesanalliterationforrolerecall.PritiisaProductOwner,PortiaanAreaProductOwner,SusanaScrumMaster,Marioateammember.

    12.Yes,thatwasreallytheirname,inLisbon!

    http://less.works

  • LeSSStructure

  • 3.Adoption

    Contents

    LeSSAdoption•Guide:ThreeAdoptionPrinciples•Guide:GettingStarted•Guide:CultureFollowsStructure•Guide:JobSafetybutnotRoleSafety•Guide:OrganizationalPerfectionVision•Guide:ContinuousImprovement•Guide:GrowingYourAdoption

    LeSSHuge•Guide:EvolutionaryIncrementalAdoption•Guide:OneRequirementAreaataTime•Guide:ParallelOrganizations

    managersthinkingaboutimprovementstohelp

  • 3.Adoption

    Ifyoudonotchangedirection,youmayendupwhereyouareheading.—LaoTze

    One-TeamScrumScrumissimple.AdoptingScrumisn’t.Whynot?

    Scrumisn’taprocess.Itdoesn’tmagicallysolveyourproblemsandcreate“hyperproductive”teams.It’sa framework that creates short feedback loops that dramatically increase transparency. This acts as amirrorshowingtheteamhowgoodtheyareatmakingaproduct.Italsoexposesproblemsintheteamandorganization.Thisvisibilityunderpinsempiricalprocesscontrol,which,alongwithinspect-adaptcycles,putstheteam,ProductOwner,andorganizationinacontinuousimprovementloop.

    That’sthegoodnews.Thebadnewsisthatthissucks.Inreality, transparencyisdiscomfortingoreventhreatening,whichmakesadoptionhard.

    One-team Scrum doesn’t saymuch about Scrum adoption other than to start “by the book.” This isn’tbecause the Scrum zealots want to force their favorite rules on the world but is a recognition thatimprovementstartswithfollowingandunderstandingthestandard.Orinleanthinking,“Wherethereisnostandard,therecanbenokaizen.”ExperiencingScrumbythebookcreatesunderstandingofhowScrumprinciples and practices relate—a systems-thinking perspective. That’s critical for succeeding withScrum.

    AnexperiencedScrumMasterandateamwithadeepunderstandingofScrumwilldramaticallyimprovethelikelihoodyouwillachieveasuccessfuladoption.

    LeSSAdoptionLeSS adoption involves big organizations andmanymindswith deeply rooted assumptions about howorganizationsshouldwork.Successfuladoptionrequireschallengingtheseassumptionsandsimplifyingtheorganizationalstructure,withalltheexplosivepoliticsand“lossofface”thatworkingacrossabiggroupentails.Adop