LeSSwithoutScrum YILV,Odd-e

LeSSwithoutScrumprovidesanexperiencewhereweapplyLeSSorganizationdesignelementsforlarge-scaleAgileadoptionwithoutfirstimplementing Scrum teams. This illustrates an organization-first approach, in contrast to themore common team-first approach. Theproperorganizationdesignprovidesthesolidfoundationforthefurthercoachingandamplifiesitseffectiveness.

1. INTRODUCTION

The usual approach to scale Scrum in my experience is to start with one team as pilot then scale. Thisexperience report provides a different approach. We focused on organization design first, without havingproperScrum implementationat a team level.Weused themaindesignelements fromLeSS,butkept teamlevelintact.Then,wecreateddemandtohelpsometeamsmovetowardself-organization.Weusedthesameapproachintwodifferentproductunitsfromthesamecompany.Thetwounitsrepresentedcasesofdifferentsizes,ascasesofLeSSandLeSSHugerespectively.

TheproperteamstructurefollowingLeSSgaveallteamsasolidfoundationtoperform.Allteamswereableto workwith stakeholders and deliver value on sprint basis. The teamswith effective coaching performedbetterintermsofself-organizationandcontinuousimprovement.Thisindicatesthatorganizationdesignisafirst-orderfactorforchange,andcombiningitwitheffectivecoachingwouldcreatethebestresults.

2. BACKGROUND

Asapractitioner,IgotdeeplyinvolvedinoneofthefirstLeSSadoptionsinNokiaNetworksbackto2006-2007.Infact,therewasnonameasLeSSyet.ManyexperimentswedidbecamepartofthefirsttwoLeSSbooks[1,2]byCraigLarmanandBasVodde.

This experience is from two product units of the same telecom company in China during 2015-2016. Iworked as a consultant to help their large-scale Agile adoption. The telecom company is huge, having tensthousandsofpeopleonproductdevelopment.Theyareorganizedinbusinessunitsandproductunits,whichisusually hundreds to thousands of people. They had a big Agile movement a few years ago, but was notconsideredsuccess.Though,theyhadimplemented“iteration”and“continuousintegration”.Their“iteration”wasasmallwaterfallatbest,andtheir“continuousintegration”wasmoreondailybuildandtestautomationthandeveloperpracticeofcontinuouslyintegratingtheirwork.

Inthemiddleof2015whenIwashiredasexternalconsultanttohelptheirlarge-scaleAgileadoption,mycontacthadsomecandidateproductunits inmind,but therewasnodecision fromanyof themthatLeSSorLeSS-like approach was the way to go. Therefore, my contact and I did a few LeSS sessions to raise theawareness and build the proper understanding about what thismeans. It camewith no surprise that theyrealizedthatthechangewasbiggerthantheirinitiallyanticipated.Infact,noproductunitexpressedthattheywouldjumpinimmediatelyaftertheinitialworkshop,andallhesitated.Manyofthemneveractuallytookthenext step. Eventually, two of them decided tomove ahead, which became the two cases in this experiencereport.

2.1 Whywedidn’tstartwithoneScrumteamItisverycommontopilotScruminproject,asprojectteamiscross-functionalandend-to-endbynature.Withthetraditionalmatrixstructure,theprojectteamisnotarealteam,butagroupconsistingofpeoplewhofocuson their respectivespecialtyareas, suchas front-enddevelopment, testing,etc.Even though it ispossible to

YiLv,Address:Apt2-2-502,76DongqingXiang,XiachengDistrict,Hangzhou,P.R.China310003;Email:yi.lv@odd-e.comCopyright2017isheldbytheauthor.

LeSSwithoutScrum:Page-2

align everyone towards common goal and take shared responsibilitywithout the permanent organizationalchange (i.e. change reporting line), the alignment is fragile. Considering all other challenges such as lack ofcapabilityincollaborationandengineering,thelackofmotivationduetomissingstructuralsupportmakesitevenmoredifficulttosucceed.Inmyexperience,a lotofteamsfalteredaftersometime.Someorganizationsmovefurtherbychangingtheorganizationstructure,whileothersregresstothestatusquo.

Figure1.HowTeamDesignandCoachingJointlyAffectTeamPerformance

ThisisbestillustratedbyRichardHackman’swork.Inhisclassicalbook“LeadingTeams”[3],therelationsasshowninfigure1amongteamperformance,teamdesignandcoachingareinsightful.Inshort,well-designedstructureandeffectivecoachingtogethercreatebesteffects,butorganizationdesignisfirst-orderfactor.

In Scrum, the ScrumMaster is responsible for providing effective coaching. Inmy experience, the initialScrumMastersinmostorganizationsarejuststartingtolearnaboutcoaching.Whenorganizationalstructuredoesnotsupportthis, thecomplexity inneededchangeisoverwhelmingtothem.Theconceptofcoachingisforeigntomyclient,anditishardforthemtoimagineaself-organizingteamwithoutanappointedleader.ThechanceofsuccesswouldbeverylowifwepilotoneScrumteaminexistingorganizationalstructure(withoutorganizational redesign) and let an inexperienced ScrumMaster coach the team towards self-organization.Therefore,wetookadifferentapproachtofocusfirstonestablishingproperstructure,andlaterincreasingthecoachingcapability.

Anotherreasoncamefromthisparticularassignment,asmyconsultingwassupposedtocreateexperienceformyclient inapplyingLeSSontheir large-scaleAgileadoption.OrganizationredesignisnecessaryinLeSSadoption.Mostorganizationstrytoavoidorganizationstructuralchange,astheyseeitrisky.Anditisindeed,particularly when it involves hundreds even thousands of people. In fact, LeSS is aware of this risk, andexplicitlysuggeststomakeincrementalchangeinverylargescale,whichisthecaseofLeSSHuge.However,itdoesrequirethatinthe“smaller”largescale,whichinvolvesapproximately50peopleorless,toestablishthecompleteLeSSstructureatthestart.

2.2 ProductunitOneoftheinitialcriticaldecisionsinadoptingLeSSistodefinewhattheproductis.Inmyclientcompany,thedevelopmentofalmostallproductsarespreadintomultipleproductunits,whichareorganizationalentities.Eventhoughtheproductunitisresponsibleforafinalproducttotheendcustomers,itusuallyhasdependencytootherunitssuchasplatformsornetworkmanagement.

For example, Base Station as a final product to telecomoperators such as ChinaMobile is built upon aninternalplatform,anddependentonnetworkmanagement.Thereareatleastthreeproductunitsinvolvedtodeliver thecompletevalue -BaseStation (not includingplatform),Platform(supportmultipleproducts,andBase Station is one of them), Networkmanagement (supportmultiple products, and Base Station is one ofthem).Thisisstillasimplifiedview,whileinreality,thereareoftenmanyplatformsinvolved.

InLeSS,“thedefinitionofproductshouldbeasbroadandend-user/customercentricasispractical.”[4]Aswe could only influence the head andmanagement of product units in practicality,we decided to focus on“products”developedbyproductunits.

LeSSwithoutScrum:Page-3

Thetwoproductunitsweworkedwithhappenedtorepresentdifferentsizes,oneapproximately40peopleand theotherapproximately120people, thus,providing casesofLeSSandLeSSHuge respectively.We firststartedwithLeSScaseinlate2015,thenLeSSHugecasein2016.TherewassomeoverlappingperiodwhenIworkedwithbothunitsatthesametime.

3. LESSCASE

3.1 InitialworkshopTheproductunit inthiscasedevelopsaplatformconsistingofapproximately40people.TheplatformoffersfunctionalitiessuchasextendedOS(OperatingSystem),communication,patching,etc.Astheyareinalowerlayer,theyhavelittledependencywithotherproductunits,butotherunitsdependonthem.Therequirementstothemarenotdirectlycustomerrequirements,butpartofthesolutiondefinedbyupperapplicationlayers,whichcouldbeanotherplatformorthefinalproduct.

The initialworkshop happened inAugust of 2015. The decision to have organizational structure changehappened in late2015,3-4monthsafter theworkshop.Meanwhile,wehada fewdeepdiscussionswith themanagementteam.Thisisusuallythecaseastheorganizationalchangeisriskyandinvolvesmuchpersonnelchange.Changestartsbeforeitstarts.

3.2 WorkdesignTheworkdesignwasaroundthecreationofproductbacklog.Themainchangesaresummarizedinthefigure2.

Before After

Workisscattered,includingcustomersrequirements,improvement,maintenance,etc.

Allworkgoesthroughoneproductbacklog

Workisorganizedinprograms Workisorganizedinproduct(platforminthiscase),withprogramsonlyasinterfacetowardsoutside

Multipleprogrammanagers OnePO(ProductOwner)

Doneinphases(analysis,development,testing) CommonDoD(DefinitionofDone)forallrequirements

Figure2.WorkRedesign

Collectingalltheworkandputtingthemintooneprioritizedbacklogresponsiblebyoneownerwasthekeyinorganizingthework.WhetherthisbacklogshouldbeownedbyonePOormultiplePOswasanotherchoicetomake.WefollowedtheLeSSruletohaveonePOwhichisgoodfortheproductwholenessandtransparency.Inordertogetitworkinpractice,i.e.notoverloadingPO,itisnecessaryforPOtofocusonprioritizationwhilehave teammake clarification as directly as possible with customers. We will elaborate more in 3.5 Sprintpractices.

3.3 TeamdesignBefore adopting LeSS, there were 4 development teams responsible for different domains, and one testingteam.Wereorganizedtheminto6teamsviaaself-designingteamworkshop.Wewould liketocreatecross-functionalfeatureteamsoutoffunctionalfeature/componentteams.

ManagementandIworkedoutsomeconstraints,andtheinitiallistwasasbelow.- Teamsizeis5-7people- Teamiscross-functional,consistingofdevelopersandtesters- Teamisfeatureoriented,beingabletocompleteend-to-endfeaturewithintheplatform- Teamisgeneric,beingabletotakeanyitemfromthesharedproductbacklog

Regardingthelastpoint,wewereconcernedifeveryteamwasgenericwithoutspecialization,eventhoughitprovidedthemostflexibility,itraisedthebiggestchallengeinkeepingthesufficientproductivityintheshortterm.Therewere4domains,andtherewouldbe6teams.Wetriedtobalancethesetwofactors,andeventuallychangedittoeachteambeingabletoworkinatleast2domains,whileeachdomainhavingatleast3capable

LeSSwithoutScrum:Page-4

teams.Thisrefinedconstraintmadeeachteamstillpossibletohavesomelevelofspecializationforefficiency,butmeanwhileenabledthewholeunittofollowonepriority.

Thenwemovedontodesigntheagendafortheself-designingteamworkshop.Wereferredtosomeideassharedinthisarticle[6],andmadearoughagendalikethis:

1. Opening(unitheadhighlightsthemotivationbehindthis)2. Volunteerforteamleaders(see3.4ScrumMastervs.TeamLeader)3. Self-designingteamcycle1(withinitiallistofconstraints)4. Self-designingteamcycle2(withrefinedlistofconstraints)5. Self-designingteamcycle3(fixing“bugs”-unmetconstraints)6. Createteamresumeandpresenttothewholegroup7. Wrap-up(participantssharetheirfeelingandcommentsattheirwill)

Eachcycleendedupwithasetupof6teams.Incycle2, itstartedbyaskingparticipantstocomeupwithadditionalconstraintsthatwouldhelpformteamsbetter.Astheyalreadysawoneconcretesetupfromcycle1,itwasa lot easier. Forexample, theynoticed that some teams fully consistedof seniorpeople,whileothersonlyjuniorpeople.Whenthiswasraised,ashortopendiscussionensuedandwedidaconsensuscheckingtorefine the list by adding a constraint about seniority of themembers in each team. In cycle 3, it started byaskingthewholegrouptoraise“bugs”forteamscreatedoutofcycle2.Then,theyself-organizedtofulfilltheremainingunmetconstraints.

Thewholeworkshop took2.5 hours, and the outcomewas6 new teams created, aswell as the chargedenergytogetstarted.Thebeforeandafterstateissummarizedinthefigure3.

Figure3.TeamRedesign

3.4 ScrumMastervs.TeamLeaderOne challenge for my client to adopt LeSS, more precisely Scrum, was introducing ScrumMaster role.ScrumMaster is a coach,while coach as a role is inexistent in traditional organizations.Meanwhile, a TeamLeader role is commonplace and traditional organizations hold a Team Leader accountable for teamperformance.ThiscontraststoteamaccountabilityinScrumandLeSS.

As itwasclearthatwecouldnotreachtheagreementonthis,wedecidedtokeepTeamLeaderroleanddefineaccountabilityabitvaguely-sharedbybothTeamLeaderandteam.Thiswasnotoptimal,butthatwasour starting point. Later, we educated Team Leaders about coaching self-organizing teams, and createddemand so that I was pulled to help some teams, which moved further than others in terms of self-organization. Some Team Leaders developed themselves intomore ScrumMaster/Coach roles, but still kepttheirshareofaccountabilityforteamresults.Aspossiblepathforward,accountabilitymightberemovedfromtheTeamLeaderandgivencompletelytotheteamsomeday.

3.5 SprintpracticesWithproperorganizationstructureinplace,weprettymuchimplementedLeSSSprintpractices.

LeSSwithoutScrum:Page-5

3.5.1 Backlogrefinement&SprintplanningAswehadonePOandoneproductbacklog for thesix teams in thewholeplatform,westartedwithoverallbacklogrefinement,whichworkedasmini-planningabouthowtodothefurtherrefinementamongteams.POand team representatives worked together to decide which items would be refined by which teams. Wedecided for some items tobedoneby some teams,while leavingother itemsopen thus refinedbymultiplecandidateteams.Thefinaldecisionofwhichteamsworkingonwhichitemswouldbemadeinsprintplanning.

Sprint planning happened jointly in a big common space. The participants included PO, all teams, andstakeholders suchasSMEs, applicationdevelopers (as theusersof theplatform), aswell as supportpeople.Thejointnesseasedalottheparticipationofallparties,astheitemmappingbetweenteamsandstakeholdersisn-to-n.Forteams,theycouldmeetvariousstakeholdersrelevanttothoseitemstheywoulddevelopinthesametimeandspace;forstakeholders,theycouldmeetvariousteamsrelevanttothoseitemstheyrequestedin thesametimeandspace.This jointsprintplanningactedasan importantenabler for teamstoclarify therequirementsdirectlywithusersandstakeholders.

Sprintplanningpart1 is forunderstandingwhat tobuild. ItstartedbyhavingPOroughlypresenting theproductbacklogandcandidate items for thecomingsprint.Teamswould togetherdecidewhich itemswerepickedupbywhichteams.POmadesurethathighpriorityitemsweredistributedtomultipleteamsforriskmitigation. The decision for some itemswas alreadymade during backlog refinement, and the decision forotheritemswasmadehere.Aftertheselectionwasdone,teamsinparallelclarifieddetailsanddiscussedaboutacceptancecriteriadirectlywithusersandstakeholders.Whentherewasalackofclarityaboutitemscope,POwaspulledintothediscussion.

Sprint planning part 2 is for understanding how to build. It continued in the same big space. As teamsselecteddifferentitemsfromproductbacklog,theycouldsplitanddopart2separately.However,theywouldbenefit from doing part 2 in shared space, because it increased likelihood that they identified needs forcoordinationacrossteams.Itwascommontohearsometeamsimplyshoutingthat“wewouldneedtomakebigchangeoncomponentXinthenextsprint,wouldanyteamwanttohaveajointdiscussionaboutthebasicdesign?”,thenotherteamsresponded.

Duringplanningpart1orpart2,itislikelythatsometeamsfoundthattheycouldnottakeasmanyitemsastheyinitiallythought,whileotherteamsmightbeabletotakemore.Asallteamswerepresent,itwaseasytoadjustthroughself-organizationamongteamsandPO.

3.5.2 SprintreviewInthebeginning,wethoughtaboutinvitingthesameusersandstakeholderstojointsprintreview.Itturnedout that theywerenotvery interested,as theplatformmostlyprovidesAPIsandservices.The learningandfeedbackalreadyhappenedwhiletheywerebeingused-theintegrationwithapplication.Thus,weswitchedourfocustoensurelearningandfeedbackatsprintreviewtoduringthesprint.Eventually,weexpandedourDoD to capture this.This furtherpromptedus to ask “whenwould theapplicationuse this feature?”duringsprintplanningasoneaspectofreadiness.Whenlearningandfeedbackhappenedduringthesprintforspecificitems, we simply shared the learning, discussed about their implications and updated product backlogaccordinglyduringsprintreview.

3.5.3 DailyScrumandcross-teamcoordinationItwasnotahardselltohaveadailyScrum,eventhoughsomeTeamLeaderswerestillthinkingofitasstatusreporting.EverytimeIvisitedthem,IobservedtheirdailyScrumandtriedtoaskpowerfulquestionssuchas“whatisoursprintgoal?”,“whataremostimportantrisksforustoachieveourgoal?”,“whatslowsusdown?”,“whataremostimportanttasksforustoachieveourgoal?”,“howshallweadapt?”,etc.Bylettingteamthinkofthosebythemselvesanddiscussaboutthosetogethertomakedecisionsonhowtomoveforward,itopenedupTeamLeaders’viewonalternativewaysofleadingteams.Someofthemgotinterestedincoachingandstartedtolearnaboutaskingpowerfulquestions.IfocusedonhelpingthosewhowouldliketogrowintocoachingtypeofTeamLeaders.

Surprisingornot?TherehadneveremergedaneedforSoS(ScrumofScrums).Outofbacklogrefinementand joint sprint planning, teams usually had good idea about which teams they need to keep closecommunicationduringthesprint.Theysetupchannelstocoordinateinadecentralizedway,whichisinlinewithLeSSruleoncross-teamcoordination.Oneexamplewassimplytohavesomeonejoinotherteam’sdailyScrum.

LeSSwithoutScrum:Page-6

Component guardians were introduced after moving to feature team. Initially, there was strict reviewprocess for teams to submit the design & code so that component guardians would review them beforeproceeding further.Soon, itwasclear that it sloweddown thedevelopment.Weadapted through twoways,one was increasing the frequency of those reviews as well as promoting the small batch and frequentsubmission; the other was increasing the capability of people to have at least one member qualified forensuringqualityinitsownteam.

Thewholegroupsittingtogetherinonespacecertainlyhelpedthecross-teamcoordinationtoo.AswellastheCommunityofTestinghelpeddiscovercoordinationneedsamong“testers”,whoareinterestedinhoningtestingskills.ThisdemonstratedtwokeypointsregardingLeSSviewoncoordination-usingmultiplechannelstocoordinate,andfocusingonidentifyingthecoordinationneeds.

3.5.4 SprintretrospectiveandcontinuousimprovementWehavealreadytalkedaboutsomeinspectionandadaptationaroundprocessessuchasreviewbycomponentguardian, integration with application, etc. We experimented various ways and adapted based on the realexperienceandfeedback.Theprocesseswereevolving,whichistheessenceofcontinuousimprovement.

FromthefirstSprint,weintroducedteamlevelretrospectives.AsTeamLeaderswerestillaccountableforteamperformance,thepointofentrywastoconvincethemthatitwouldeasetheirjobwhenteammemberscontributedtotheimprovement.Ifacilitatedretrospectivesforallteamsatleastonce,whichdemonstratedthedifference thateffective facilitationcouldmake.SomeTeamLeadersbecame interested in facilitativewayofleadingteams,then,Iworkedwiththemmore.

We started with one overall retrospective before the first sprint, with the whole group present. Thereflectionwasdoneforthelastreleaseof2-3months.Andwekeptthisrhythmofhavingoverallretrospectivewitheverybody.Foroverallretrospectiveineverysprint,onlyTeamLeaders,POandmanagersattended.Wediscussedaboutwhether to involve teamrepresentatives anddecided to startwithout them firstly, becauseretrospectivewas not even a normalway ofworking at the team level, andwewould like to involve teammembers step by step in continuous improvement. At first, the organizational improvementwas driven byTeamLeadersandmanagementtogether.

Onefocusincontinuousimprovementwastoshortenthetimefromdoneproductincrementtoshippableproduct incrementmeetingproduct level releasecriteria, as this reflects theagility.Thishadbeena regulartopic for quite a few sprints. Through systematically removing impediments and expanding DoD, it wasdecreasedfromroughly2-weekto3-dayinhalf-a-year.

Overall, there had been significant improvement on cycle time and productivity. The quality in terms ofexternaldefectswaslowbeforethechange,anditwaskeptatlowlevel.

4. LESSHUGECASE

Theproductunitinthiscasedevelopsanetworksecurityproduct,consistingofapproximately120people.Theproducthastwoparts-webandequipment.Therewere3groups,onedoingwebinterfaceinBeijing,andtheothertwodoingtheworkinequipmentinHangzhou.Manyfeaturescutthroughwebinterfaceandequipment.ThesizeoforganizationexceededLeSS,anditwasacaseofLeSSHuge.

4.1 RequirementAreaRA(RequirementArea)[5]isthemostimportantscalingtechniqueinLeSSHuge,inresponsetothecomplexityforonePOtomanage,regardingproductbacklog,numberofteams,etc.ProductunitissplitintoRequirementAreas,eachconsistingofseveralfeatureteams.ProductbacklogissplitintoAreabacklogs,eachcontainingallitemsinthearea.WithineachRAisessentiallyaLeSSadoption.

ThecriticaldecisioninLeSSHugeadoptionistheformationofRAsasgroupingforbothworkandpeople.Weconsideredtoform3RAsforthose3groups,butinessence,therewereonly2RAs,asbothareasincludewebinterface.Ideally,wewouldhavedismissedBeijinggroupandmovedpeopletojoin2realRAs.Duetothelocationdifference,wedecidedtoform2RAsandonedevelopmentarea.Those2RAs,ononehand,treatedthedevelopmentareaastheirexternaldependency;ontheotherhand,madeuseofCLI(CommandLineInterface)forindependentverificationasmuchaspossible.

OncewedecidedtheRAs,itworkedthesameasLeSScasewithineacharea.Usually,LeSSHugeadoptionhappensevolutionarywithRAbyRA.AswehadonlytworealRAsinplace,wedecidedtodothisatonceandsupportedbothareastomakethetransformation.

LeSSwithoutScrum:Page-7

Another interesting decision was whether we would couple RA with line organization. RA is a tradeoffbetweentheflexibilityandtheneedforspecialization.RAassumesthattheworkloadfromhighvalueitemsinoneareaisstableduringarelativelylongperiod,say,oneyearratherthanacoupleofsprints.However,thiswasnot the case.Releaseby release, each release roughly3-6months,we saw fluctuation in thehighvalueworkload. Itwas toopainful tomoveteams inreporting lineswithsuchhigh frequency, thus,wedecidedtodecouple lineorganization fromRA.Toaccommodate the fluctuation,we targeted to formone team ineachareatobeabletoworkforbothRAs.[7].

4.2 POteamTherewasoneAPO(AreaProductOwner)andoneareabacklogforeacharea.OneoverallPO,twoAPOsandprogram managers, who remained as interface towards outside, together formed PO team for the wholeproduct.

TheoverallPOwasoneofthemostseniorpeopleintheorganization,whohadthecapabilitytoworkwithmultiplestakeholdersandmaketoughprioritizationdecisions.However,wewerenotabletofindAPOswiththe similar level of experience in the organization, which clearly showed the weakness in its productmanagement.With thevisionthatAPOseventuallyneedtoworkdirectlywithstakeholdersandmaketoughdecisionsontheirown,theoverallPOactedasteacherandcoachforAPOstonotonlyhelpthemgetthejobdone,butalsobuildtheircapability.

4.3 FeatureteamswithinRATherewere twomain changes in termsof team structurewithinRA.Onewas to get testers integrated intofeatureteamspermanently;theotherwastomakeallteamsshareoneproductbacklog.

Beforethechange,testerswerelooselyconnectedtodevelopmentteams,andtheyweresubjecttochangeoverreleases.Afterthechange,testerswereintegratedwithteamsandexpectedtostaytogetheroverreleases.

Before the change, each development teamworked on a certain specialty sub-areawithin the area, andessentially followed theprioritywithin its sub-area.After thechange,each feature team(development teamwithtesterspermanentlyintegrated)workedonthewholearea,andfollowedonesharedprioritywithinthewholearea.[8].

We chose adifferent approach than the first LeSS case. In the first case, the team redesign enablednewteamstoworkacrossdomainsand followonepriority. In thiscase,wedidnotreformtheteams,except thepermanentintegrationoftesters.Thekeywastocreatetheflexibilitybyremovingtheconstraintthatoneteamcouldonlytakeitemsinonesub-area.Consideringthattheskilldifferenceamongthosesub-areaswasnotbig,wethoughtthatitwouldbefeasibletolettheexistingteamsexpandtheirworkscopewiththesupportfromotherteamshavingthespeciality,thus,decidedtokeepthoseteams.

4.4 DependencyRegardingSprintpractices,mostactivitieshappenedinsideRA,thus,workingalmostthesameasthefirstLeSScase.Asthiscasewasarealproduct,ratherthanaplatform,itposedmorecomplexityintermsofdependency.Theproduct dependedonnetworkmanagement andplatforms,whichweredoneby otherproduct units. Itwas not practical to extend feature team across product units. Thus, we had to resort to other ways ofmanagingdependency.AsSAFewasusedwidelyinmanyproductunitsofthecompany,weessentiallydidPI(Program Increment) sync to manage dependency across product units, while adopting feature teams toremovedependencywithinproductunit.WhilewewereabletosynctherelevantworkintothesameSprint,the integration was done as continuously as possible within the same Sprint. However, out of sync acrossproduct units still happened quite often, as the underlying limitation came from the big structure - thoseproductunitsessentiallydevelopsomekindofcomponents.Overall, this LeSS Huge case was still at early stage when I left, but the approach of organization designproceedingsprintpracticeswassolid.

5. WHATWELEARNT

The experiencehad strong resonanceonRichardHackman’s finding aboutproper teamdesignoutweighingeffectivecoachingasfactorstoinfluenceteamperformance.LeSS’sstrongfocusonorganizationdesignreflectsthe same.Organization firstapproachprovidesanalternativeway to thenormalapproachofpilotingunderexistingstructure.

LeSSwithoutScrum:Page-8

Itwouldbebetter ifwehadagreedonavisionofeffectivecoaching for teams.This lackofagreementatorganizationallevellimitedhowfarwewouldgointermsofself-organizingteams,asitwasleftbychancetoindividualteamleaders.

Attacticallevel,hereisasummaryforwhatwelearned.- Useanincrementalapproachtoexpanddomainspecializationformoreflexibility- TakeatransitionalpathfromtraditionalTeamLeadertoScrumMaster/Coach- Enableself-organizationacrossteamsviajointScrumevents.- EnableonePOvs.multipleteamsbygettingteamsonrequirementclarificationandfeedback.

Inaway, thisexperiencereport isnota full story. It ignoreswhathappenedbeforewegot involved.Forexternalconsultant,theconsentonorganizationredesigncouldbetakenasprerequisite.However,forinternalpeople, I would suggest to apply the art of the possible till the tipping pointwhere itwould be feasible toredesigntheorganization.

6. ACKNOWLEDGEMENTS

IwouldliketothankmycontactGuangjingChenfromtheclientcompany.Weworkedverycloselyduringthewhole journey, had lots of deep discussions about how to help those two product unitsmove forward, andsharedmanygreatinsights.

IwouldliketogivemydeepappreciationonthegreathelpthatChrisEdwards,myshepherd,hasgivenmeinwritingthisexperiencereport.

REFERENCES[1]CraigLarmanandBasVodde,“ScalingLean&AgileDevelopment:ThinkingandOrganizationalToolsforLarge-ScaleScrum”,AddisonWesleyProfessional,1stedition,2008[2]CraigLarmanandBasVodde,“PracticesforScalingLean&AgileDevelopment:Large,Multisite,andOffshoreProductDevelopmentwithLarge-ScaleScrum”,Addison-WesleyProfessional,1stedition,2010[3]RichardHackman,“LeadingTeams:SettingtheStageforGreatPerformances”,HarvardBusinessReviewPress,1stedition,2002[4]https://less.works/less/rules/index.html[5]https://www.scrumalliance.org/community/articles/2013/2013-april/how-to-form-teams-in-large-scale-scrum-a-story-of[6]https://less.works/less/less-huge/requirement-areas.html[7]https://blog.odd-e.com/yilv/2016/06/decouple-line-organization-from-requirement-area.html[8]https://blog.odd-e.com/yilv/2015/12/shared-backlog-with-one-priority.html