Growing the Mob CHRIS LUCIAN, Hunter Industries, Inc.

Mob Programming was conceived of at Hunter Industries in 2011. We were a small, highly successful team. Then we grew. This report is about how over the past year we grew our department from one Mob of 5 team members to a department of 30 people supporting multiple streams of work. We’ve had to overcome challenges of incorporating new members at a pace we can sustain while preserving our team culture and focus on quality.

1. INTRODUCTION

I am Chris Lucian, part of the team who started Mob Programming at Hunter Industries in 2011. Severalmembersofour teamhavepublishedexperiencereportsbasedontheresultsandexperiencesour teamhashad:WoodyZuill[Zuill],AaronGriffith[Griffith],andJasonKerney[Kerney].ThisreportisabouthowwehavegrownourteamfromoneMobtoeight. InSeptember2015, IwasaskedbyHunter Industries to takeanewsoftwaredevelopmentdirectorpositiontobeginanewdepartmentandtogrowthenumberofMobteams.Myrolehasbeentohelpexpandandgrowourteamwhilekeepingitscultureandvaluesintact.

2. BACKGROUND

Beforeourmostrecentexpansion,wehadbeenMobbingforfouryearswithateamof5people.Duringthattime,weexperiencedaone-and-a-half-yearperiodwherewereceivednonewbugreportsforanysoftwarewehaddevelopedwhilereleasingworkingsoftwaretoproductionsometimestwiceinthesameday.ThissuccessledtoexecutivemanagementaskingustoexpandthepracticeofMobProgrammingintoalargerportionoftheorganization.ForoneyearnowwehavebeenscalingMobProgrammingfromoneteamtoeight.

OurteamMobprogrammedfor4yearsbetween2011and2015withnorealchangetoteamsize.Wehadsomepeopleleaveandnewmembersjointheteam,continuouslyimprovingasweprogressed.Oursupervisorat the time, Woody Zuill, felt that a manager was no longer needed for the team due to how well it wasoperating.Woodythen left theorganization6monthsbeforewehadstartedscaling.OurMobthenreporteddirectlytoourDirectorofInformationSystems,MarcKase.Inthismodelweidentifiedthatwedidnotneedtoexplicitlyhaveamanager.Thisproved important to thegrowthofourdepartment, andwecontinue to findthat not havingmanagersworkswell for us.Wedid a better job of setting objectives for each other and ofbuildingourskillsthanamanagercouldhaveeverdoneinatraditionaltop-downrole.

For about sixmonths after ourmanager left, ourMob programming group continued towork as it had,however, we self-organized around management tasks rather than any one person in charge. We handledmanagement-related tasks within the team and many times as the entire Mob. Ultimately, when I becameDirectorofSoftwareDevelopmentandwedecidedtoscaletomultipleMobs,weasadepartmentdecidedtomoveforwardwithoutmanagersandcontinuetousethismodel.

Inthesummerof2015wealsobegantoexperimentwithmultipleMobsbybringingontwointerns.Thisexperimentwasa cost-effectiveway to allowus to addpeople to the teamandevaluate thebenefits.Theseexperimentsweresuccessfulandinfluencedthedecisiontoexpandtheteamfurther.

Author’saddress:ChrisLucien,HunterIndustries,1940DiamondSt,SanMarcos,CA92078USA;email:chris@chrislucian.comCopyright2017isheldbyChrisLucien

GrowingtheMob:Page-2

3. GETTINGBUY-INTOGROW

Aswithanynewprocess,whilewedevelopedMobProgrammingwithintheorganizationweexperiencedbothsupportandskepticism.WeknewMobProgrammingwasworkingforusandwebelieved itcouldhelpwithotherdifficulties intheorganization. It ishardtogetbuy-infrommanagersaswellas individualswithinthecompanywhen people don’t understand how it can bemore effective to have four peopleworking on onecomputerinsteadofasingledeveloper.Inordertoovercomethis,wehadtoaddresseveryone’sconcernsonebyone.ItisimportantwhenspreadingapracticelikeMobprogrammingtoestablishgoodrelationshipswiththe peoplewho are least likely to believe in the effectiveness of the process. A good relationshipwill helpfacilitatetheuseofgoodmetricsinordertoconvincethemotherwise.

Themost interestingcomparisonI’veseenbetweenagroupthat isdoingMobprogrammingandagroupthatisnot,camefromwithinourorganization.Duringthetime,wehavebeenpracticingMobprogrammingoninternalapplications,ourexternalproductdevelopmentteamwasgoingthroughsomeofthesameproblemsthatwererelevanttous4yearsearlier.Duringanexternalsoftwaredevelopmentprocessauditthetwoteamswereevaluatedfortheirpractices.OurteamwasperformingMobprogrammingandAgileingeneral,whiletheother team was operating under an increasingly unsuccessful process. It was clear that the Mob processneededtogrowandspreadwithintheorganization.Yetitwasonlyastateofemergencyontheotherteamthatcausedrapidanddrasticchange.

Unfamiliarwithagile softwaredevelopment,ArnePike, ourvicepresidentof engineering’s curiositywaspiqued about the process after hearing about our results. I described to him the many aspects of MobprogrammingthatIbelievedmadeussuccessful.ItoldhimthatthefoundationofMobprogrammingwasourlearning sessions and retrospectives. I also described how overtime is not an indicator of dedication andinstead is an indication of failing processes. I mentioned, however, that release frequency is an importantmetricandneedstobemonitoredregularly.Wediscussedhowbadpracticescancauseabreakdowninbothreleasefrequencyandmanifestovertime.Ialsointroducedtheconceptoftechnicaldebtandtheimportanceofcontinuous integration, continuous delivery, Test-Driven development, and behavior driven development.Finally, I described to him the positive effects of having no bugs in production. Quickly, the reasoning Ipresented helped convince him that our Mobbing and agile process was a good one to adopt within thesoftwarethathewasoverseeing.

With both the vice president of engineering and the director of information technology convinced, thepresidentofthecompany,GregHunter,gaveustheabilitytoscaleandcreateanenvironmentinwhichgreatsoftwarebecomesinevitable.Wegotbuy-infromallmajorareasoftheorganizationandwenowonlyhadtoaddress the small patches of skepticism within the organization rather than having to fight a large up-hillbattle.

Atthispointitwasdecidedthattheexternalproductteamandtheinternalproductteamshouldmerge.Ourdepartment would report to both the VP of engineering and the Director of Information Technology as acentralized software development organizationwithin the company. At this point, all of the teammembersfrombothgroupsbeganMobbing,allowingustogrowtooursecondMob.Sincetheorganizationasawholeidentified the importance of software development, leadership wanted to further grow 6 more Mobs. Thenumberof6Mobseventuallybecame8aswetookoninternsandaddedadditionalprojectstoourcatalog.

Ifeltthatthenewproductownerswerethemosttakenabackoutofeveryone.TheirpreviousexperienceswithsoftwaredevelopmentgroupswereentirelybasedinWaterfallpractices.Sincewewantedtoworkcloselywithourproductowners,weexplainedtheconceptsthathadhelpedussucceedinthepastwithourproductowners for internal applications. This meant explaining minimum viable product development, automatedtesting,singleitemworkinprogress,andAgileingeneral.Oneofmygreatestsuccessesinhelpingconvinceourproduct owners toworkwith us thewaywe desired, was through one-on-one conversations over a set ofPowerPointslidesthatweusediscussingminimumviableproductfeedbackandothersystemsweuse.

4. GROWING THE MOB Oncewehaddecided togrowMobprogrammingwithin thecompany,weneeded to identifyhoweachMobwouldhandleworkasitcamein.Inthepast,withouroneMobteamweusedKanbananditwasveryeffectivefor us. We described our work as a stream of work that could be utilized for any project, depending onwhatever priority was highest. With our new department, each Mob was identified as a stream and weallocatedstreamstotheprojectsthatwewantedtoaccomplish.EachMobonaverageconsistedoffourpeople.Inordertogrowourcapacity,wedecidedtobeginhiringfourpeoplepermob.Initially,welikedfourmembers

GrowingtheMob:Page-3

ineachMob,however,wefoundthatfivetypically isbetterinordertofacilitatepeopletakingvacationsanddealingpossibledistractions.With the assumption that any featurewill have fourpeopleworkingon it, thedevelopersself-organizearoundavailablework.MembershipofaMobispurelynegotiatedandanydevelopercanmovefromoneMobtoanotheraslongaseachMobhasfourpeople.Along-termeffortmayconsistoftwofull timeMobs,however, thoseMobscouldre-formordecomposebasedontheself-organizingnatureof thedepartment.

4.1 PreservingtheCulture Weknewthataddingpeopletotheteamwoulddilutetheculturewehadestablished.SincetheorganizationdecidedthatweneededtohavesixMobs,wedecidedtobeginhiringfortwenty-fourpeople.Sincetwenty-fourisanenormousnumberofpeopletoaddtoasmallteam,wedecidedtodefineagrowthratethatwasnottobeexceededinordertopreserveourculture.Thisnumberwastwopeoplepermonth.

Quickly,we foundthatwewereable tohireat therateof twopeoplepermonth.We foundthat throughcommunityinteractionatusergroupsandagileconferences,wewereabletofindthetypeofpeoplewewerelooking for to join ourMob programming teams. In fact, because of the benefits thatwe receive fromMobprogramming,wefoundthatmanydeveloperswantedtoworkwithusfortheexperiencewithanewstyleofsoftwaredevelopment.WehadWoodyZuillcomeintofacilitateworkshopsinMobprogramming,helpingustremendouslywithhiringandspreadingthewordaboutouropenings.

To integrateeachpairofnewhires into the team,wedevelopedaway toonboard themembersandgetthem familiar with the team’s core beliefs. We hired at this rate for several months (see Figure 1). Weexperimentedwithhiringfourpeoplewithinthesamemonthandfoundthatitwasamuchlargerdisruptiontothecultureandpractices.Sincethenwehavedecidedtosticktotwopeopleamonth.

Figure1.Growthwaslimitedtotwopeoplepermonth

4.2 EnvironmentOurfacilitieswereanotherconcernwehadtoaddress.InourpriorspaceweonlyhadroomfortwoMobs.Inorder toaccommodate sixMobs,weneededanew facility.Thiswasgreatbecausewewereable to identifyeverythingaboutthefacilitythatwewantedtoincludetomakeourgrowthsuccessful.Oneofthefirst itemsthat was apparent was wanting everything on wheels, including our 80 inch 4K resolution monitors. Thiswouldallowus torearrange theofficeatany time.Anotherchange thatwemade toournewspacewas theremovalofwallstomakemoreofanopenareaforustocollaboratemore.Imadesurethatnodesksassignedwere to people, including myself, and instead gave each developer a locker. I set up pairing stations thatlaptopscoulddockatincaseanythingnon-Mobrelatedlikeexpensereportsandotheradministrativeneededtobeworkedon.Finally,Iwantedtomakesurethattherewasofficespaceforanyproductownersthatwouldliketoberelocatednearusinteractwiththeteamsmorefrequently.

4.3 InterviewsAs a team, we identified that our interview process needed to accommodateMob programming as well astechnical excellence. As a group, we designed our interview to include questions about test drivendevelopment,debugging,legacycodere-factoring,anddatabases.AllofthequestionswereaskedtocandidatesasiftheywereintheMob.Teammembersweretheretoaidthem,butthoseteammembersdidnotknowthesolutions to the problems.We had some successes in this process and we retrospected frequentlymakingadjustmentstoourhiringprocessbasedonoursuccessesandfailures.TherewerethefewtimesthatwehadcandidatestoonervoustocontinuetheinterviewwithaMob.Webelievethatthenervousnesscamefromthefactthecandidatewashavingtoprograminfrontoffourpeople,whichisunusual.Subsequently,JasonKearny

GrowingtheMob:Page-4

wrote a blog about our interview process (http://jason.teamkerney.com/post/a-better-interview) and webegantosendeverycandidatethislinktohelppreparehimorherfortheinterview.

5. MAINTAINING TECHNICAL EXCELLENCE Attending conferences and a conference budgetwere two of our highest prioritieswhenwe started as oneMob.Typically,inoneyearwewouldgototwoorthreeAgileOpenconferencesaswellasamajorconferencelike theAgileAlliance.We foundthatgoing togetherasa teamhelpedbuildcamaraderieand trust.This isapretty large budget for individual developers to be attending conferences. Therewas a negotiation aroundbudgetthatwewentthroughwhenIbecamedirectorofthedepartment.Ihadaskedtheorganizationtokeepmostofthetrainingbudgetintactforeverynewdeveloperthatwebroughton.Thiswasextremelyimportantinhelpingdevelopahighlycohesiveteamwithinthetimeframethatwewantedtobecomeeffective.

Anotheritemwenegotiatedforwhenwebegantogrowwasonsitetraining.Iwantedtomakesurethatthetechnicalexcellenceof theteamwaskept toahighstandardevenwiththe influxofall thenewpeople.Thismeantthatweneededalargeamountoftechnicaltrainingupfront.Wedecidedtodoamonthlytrainingforthefirstyearandsubsequentyearswouldbequarterly.

Inthepast,withonlyoneteam,asingleclickmanualdeploymentwasallweneededtopracticecontinuousdelivery.However,aswegrew,we identifiedtheneedforrigorous,continuous integrationandacontinuousintegrationtool.Thisneedcamefromthefactthatsomepeopleknewhowtodeploywhilesomedidnot,andmanywould forget over time as theyworkedonnewordifferent projects. Rather than risk teammembersforgettinghowtodeploy,wefullyautomateddeployment.Thisultimatelyledtoanincreaseindeliveryspeed,aswellasanincreaseinquality.

Astheteamsweregrowing,wediscoveredthatwehadnaturallyemergingtechnicalleaders,whichhelpedustodefinecoreelementsofourcodingpracticesthatwouldcontinuetogrowandevolveovertime.Oneofour Mob Programming heuristics is “everyone on the team should be navigating about an equal amount”.Referencingthisheuristic,wedeterminedthesetechnicalleadersshouldbenavigatinglessandteachingmore.Thisactionreinforcedtechnicalexcellencewithintheteamandallowedtheseniordeveloperstobuilduptheirteammates.

Wecontinuetoencourageself-organizingteamssotheteamcompositionforeachprojectisbasedpurelyonnegotiation.Thismeansthatiftwodevelopersonseparateteamsagree,theycanexchangeplacesonprojectteams.ThisisdonewiththeunderstandingthataMobwillconsistofmostlypeoplethatcancontinuetomovetheprojectforwardwhilesomeonenewisgettinguptospeed.Retrospectivesinthepasthaveidentifiedthatsometimestheteamisswitchingpeopletooquicklyandsomewereswitchingtooslowly.Thishasbeenagreatwaytohelpregulatethepeoplethathavesocialdifficultieswitheachothersincetheycanswitchteamsatanytime.

Theonlystructurethatisimposedonthedepartmentaroundteamcompositionistheideaofaminimumnumberofdevelopersperproject.Wheninitiallyplanningourgrowth,wehadthreemajordevelopmentpathsorprojectswewantedtofocusonwiththefullystaffedteams.Aswegrew,weaskedthatateamalwaysendupwitheightpeopleononeprojectteam,eightonanother,andfiveonthelast.Thisallowstheteammemberstoself-organizewithouttheorganizationriskingalossofinterestbythedevelopersintheproject.

With rapid growth, comes drastic change. Our goal is not to prevent that change but instead to steer ittowardapositivedirection.Wewereextremelyawareofareasinwhichweneededtopayattentiontothisfact,especiallywithculture,quality,andstructure.

6. CULTURE With a large influx of newpeople,we also identified the need tomaintain our culture.We decided to startpracticingretrospectivesaroundcultureandexplicitlydesignthecultureoftheteamasagroup.

In our new emerging culture, one of the thingswe implemented immediatelywas a review of our corebeliefs. Number one was the idea that we should be treating everyone with kindness, consideration, andrespect.Withallnewemployees,wealsoreviewedtheAgileManifesto,theSoftwareCraftsmanshipManifesto,andtheconceptsvaluedbytheNoEstimatesmovement.Wefoundthatthisreviewworkedwellandhelpedtoimmediatelyreinforcesomeoftheareasthatwehaddeemedimportant.Aswegrew,therewasadipinqualityandtechnicalexcellence,wealsodidseesomefailuresaswellassuccesses.Wedidnotexpecttomaintainourhighlevelofqualitytheentiretimeweweregrowing,soitwasimportanttomakethefailuresevidentsowecouldretrospectbacktoahighleveloftechnicalexcellence.

GrowingtheMob:Page-5

Thecultureof thedifferentproject teamsalsobegan todiverge from thebeginning.Todaywehave fourdistinctgroupsworkingonwhatwewouldconsiderprojects.Sincemembershipofateamisnegotiated,Ihavenoticed there is a personality spectrum that has surfaced within the different teams. The people who arepassionateaboutnewtechnologieshavecoalescedaroundwhatIcallthepopularprojects.Otherspassionateabout the Agile process and maintainability of Legacy Code have organized around the hard-refactoringproject.Thenthereare those thatareamiableandwilling to takeonanything thatwillhelp thedepartmentwhoendedupontheimportantbutlessappealingproject.Thesecultureshavesolidifiedaroundtheseprojectsand over time people havemoved between them.When the transition happens, the newmember seems toadoptthecultureof thatteam.Tofacilitatethetransition,however,weasadepartmenthave identifiedcoreworkingagreementsthattheentiredepartmentagreeson.Theseworkingagreementsincludeloftygoalsandstandards likeGherkin across teams. It is also important tonote that the teams are allworking indifferentlanguages and development stacks, however, Gherkin is the unifying language between teams for clarity ofdirectionandrequirements.Whensomeoneswitchesbetweenteamstheycanalwaysgetuptospeedquicklyby reading theGherkinandUnitTests.Finally,weholddepartment retrospectivesaboutoncepermonth tohelpdevelopaunifieddepartmentculture.

6.1 FlatDepartmentStructureAnotherinterestingcultureshockwastheimplementationofourflatdepartmentstructure.AsadirectorIdonotplaytheroleofamanager.Withagroupoftwenty-fourpeopleinatypicaldepartmentatHunterIndustriestherewouldbemultiplemanagers.Iamultimatelyresponsibleforthesuccessofthedepartmenttotherestoftheorganization;however, I tryanddistributeasmuchof theactualmanagementrelatedresponsibility intoourflatstructure.Infact,theonlymanagementresponsibilitiesIpersonallydobymyselfarerelatedtowagesand reviews.We decided to continue with our current situation, which was to distribute the managementresponsibility to everyone in the team. Any management task, including budgeting and team performancemetrics,ishandledfromwithintheteam.WequicklyestablishedamanagementKanbanboardandusedthattoquicklydelegatework. Finally,we created a rotation forpeople to attend the internal departmentmeetingsthatoccurredonaregularbasis.Inthatimplementation,weusedasimpleroundrobintechniquetoalloweachperson toexperience themeetingsandcontribute inhisorherownway.WehavealsobeenexperimentingwiththeideaofanimpromptuMobthattakesonmanagementtasksinsteadofhavingthosetasksbedonebyonly one person. So far, the team has been favoring the management Mob instead of a management taskKanban.

The self-awareness of a team of four working together is significantly greater than people working bythemselves. Ibelieve thatagroupcanmakebetterdecisionseventwith themostminorchoices suchas thesentencestructureofanemail.Ultimately,havingsomebodyeithermicromanagingormiddlemanagingateamworkinginthiswaybecomesredundantorwasteful.Ifeelthatmyroleasthedirectoristoprovideeverythingtheteamneedstobesuccessfulinbothatechnicalandpsychologicalsense.Theteamcanprogressquickly,andmakegoodtechnicalandinterpersonaldecisionswithoutmyintervention.Itryandinfluencethesystemonlyinwaysthatsupporttheoveralldirectionoftheteam.

Mybiggestchallengeinthisregardhasbeenourrateofgrowth.Sincetheteamisgrowingsoquickly,itishardtoguidesomanynewinfluencesonthesystemovertime.Whenhiringourlastfourmembers,Ialsomadethemistakeoflettingthemallstartatonce.Havingfourpeoplestartatthesametimeviolatedourtwopeopleper month rule, which proved to be chaotic, as it was extremely difficult for me to avoid getting directlyinvolvedintheteam’sincorporationofthesenewpeople.

I believe my greatest contributions to the team has been around communication of our practices andperformanceouttotherestoftheorganization,guidingtheteam’sinterpersonalcommunication,andhelpingtheteamdevelopcoachingskillstoguideeachothertoabetteroutcome.Iftheorganizationcancommunicatewellwiththeteammembersandtheteammemberscancommunicatewellwitheachother,thenIbelievewewillhaveafoundationforcontinuingtomakegreatthingshappen.

IstartedasadeveloperMobprogrammingwiththeteamandIstilltrytocontinuetoemploytheseskills.Icanhaveadiscussiontechnicallyorfromthebusinesslowerlevel.Theseskillsarealsoimportanttodevelopineverymemberoftheteamatleastonsomelevel.Wehavecreatedanenvironmentwhereeverymemberoftheteamhassomeleveloftechnicalexpertiseaswellascoaching,managing,andteachingskills.

Tocommunicatewellwiththerestof theorganization, Ihavecreatedseveralpresentationsaroundwhatwe expect from our different counter parts. I have also created several automated reports around theperformanceoftheteam,whichhelpstheorganizationbemoreawareofthedecisionswemake.Examplesof

GrowingtheMob:Page-6

thesereportsincludemetricsonreleasestoproductionperdayandanautomatedhistoricalGanttchartthatdepictsthecompleteGherkinscenarioscreatedovertime.Thishasledtoahighleveloftransparency,whichinturnhascreatedahighleveloftrust.

Asatechnicalleaderinthedepartment,Idogetinvolvedatatechnicallevelwithteams,butitisimportantto note that we try and avoid the HiPPO (Highest Paid Person Opinion) effect. Before I begin Mobbing orparticipateinanarchitecturaldiscussion,Iexplicitlystatethateveryoneshouldonlytakemytechnicaladviceas recommendations and not a command to execute my version of the plan. I participate in technicaldiscussionsasaMobmemberandnotthedirectorofthedepartmentandIhavepeopleinmyteamholdmeaccountabletotheserules.

7. CHALLENGES

ItiseasytotalkaboutallofthesuccesseswecontinuetoexperienceandIwouldliketoalsoaddresssomeofthechallengesthatwehaveincurred.Withgrowth,therewillalwaysbestressonthesystem.Thatstresswillwarpandmanipulatethesysteminordertoaccommodatethatgrowthinwhateverwaynecessary.

7.1 NewpeopleallthetimeThe first big challenge has been the continuous growth for about a year. With that growth, we haveexperienceddifficultiesprimarilyaroundconflictingprior technicalexperiences.This isbothabenefitandachallenge.Peoplewithdifferentvaluesandopinionscome into the teamandhave toworkwith the teamtodefinewhattheirworkingagreementsaroundtechnicalstylewillbe.Theseworkingagreementsdefinedatadepartmentlevelareguidedbyourloftygoals.

With each new developer, we have found that they have different technical backgrounds and differentexperienceswithqualityandautomatedtesting.Muchofthechallengehascomefromstandardizingthelevelofqualitythatwewantedtoachieve.BehaviorDrivenDevelopmentwasnotacommonpracticeforusuntilwehadsomanypeoplethatweneededtodomoreintegrationtesting.Inthepast,comprehensiveunittestingwasallweneededtogettothepointwherewehadzerobugs.Itisimportanttonotethatweincreasedtheamountoftestinginpartspecifically,toaddressthedifficultyofworkingwithmorepeopleinmultipleMobs.

WewriteBDDtestsasaresultofproductownerinputandmaintainGherkinforourautomatedacceptancetests. Since many more people are on the team, Gherkin has become an outstanding communication toolbetweenmembersacrossteamsortonewpeopleworkingonprojects.Thenumberofbugswehaveseenhasincreasedwith our growth and the need for better communication betweenMobs.However, our BDD testshave decreased those numbers.We are now going longer and longer periodswithout reported bugs on theteamsthathavebeenincorporatingautomatedacceptancetestsintotheirdevelopment.

7.2 GrowandSplitAswegrewtheMobs,wedidnotexplicitlysetouttoseparatepeopleandinsteadusedaheuristicforwhentoform new Mobs. We typically tell everyone that a Mob only is too big when someone in the Mob is notcontributingorlearning.Thismeansaswegrow,weallowtheMobtobecomelargerandlargeruntilthereisakeymomentinwhichtheteamdecidestosplit.WealwayshaveonemoreMobstationavailablethatisneededfortheteamstooperateindependently.ThisprovidesanavenueforsuggestingthattheMobssplitsincethereisnothingintheirwayofbecomingaseparateMob.ThiscausedustodivideoriginalMobteamintomultipleteamstoseedculture.

Aswedividedtheteamsandbroughtonnewpeople,ourmostexperiencedMobbersanddevelopersspreadamongstthenewteamsthat formed.Wefoundthat ifwedidnotgetenoughofaknowledgetransferbeforemoving, an experienced person would constantly be asked questions until theMob built up enough of thecommon knowledge that they could move forward without that person’s knowledge.We called this effect,whenagroup’scollectiveknowledgewasnotcompletebeforetheylostanysingleteammember,“creationofatribalknowledgesilo.”Wehadtwosolutionstothisproblem.Firstwasthepracticeofkeepingteamsintactandadding the new person before someone else left the team. Second was the incorporation of Gherkin asacceptance tests throughout all our projects. The combination of these two solutions helped us bridge theknowledgegap.

Whenthemergeof the InternalandExternalproduct teamshappened,we foundthat thereweresilos ineach team that needed to be distributed across the other teams. We encouraged the start of movementbetweenMobsbecausewewanttoavoiddevelopingsiloswithintheoverallgroup.Wewantedtomakesurethatthereareatleastanumberofpeoplethatcanhandleanyparticulartaskthatwouldotherwisebedoneby

GrowingtheMob:Page-7

asingledeveloper.Agreatexampleofthis,waswhentheteamsmerged,therewasanalreadyanestablishedsiloontheteamthathadtosharetheirknowledgeinorderfortheteamtobecomemoreeffective.ThiswasaneffectthatwesawbothwhenwestartedMobbingin2011andwhentheteamsstartedtogrowin2015.Eachtimewegrew,wefoundthatcertaindevelopershaddevelopeddeepsilosofknowledgearoundsomespecific,crucialfunctionsthatwedeterminedneededtobedistributedacrosstheothermembersoftheteam.

Due of the nature of Mob programming, distributing that knowledge was simple and learning theinformationneededtotakecareofthosetaskswaseasieraswell.

7.3 InterruptionsAnotherissuethatnewMobbingteamstypicallyhavetoendureisthenatureoftheinterruptionscreatedbypeople getting used to Mob programming. Examples of these issues are background noise, and sideconversations. TheMob programming etiquette that is developed can be accelerated by retrospectives andteambuildingexercises.Eventuallytheteamneedstogettoapointwheretheyareallcomfortablegivingeachotherhonestandcandidfeedback.Yet,attimesitwasstillanissueaswegrew.Today,however,Ihaveseenthesamegroupsofpeopleperformingwithoutanyissuesanditjustappearstocomewithtime.Whennoiselevelsbecometoohigh,theteamscannowturnoffthelightsintheofficewhenthecollectivegroupsofMobbersaretooloud.Forsideconversations,therearetapedperimetersaroundtheMobbingareaswherepeoplehavingasideconversationmustmoveawayfrom.

7.4 RetrospectiveSaturationAnotherareathatwestruggledwithistheissueIliketocall“retrospectivesaturation.”Thisiswhenyouhavesomanyretrospectivesthatpeopleontheteambecomesickofthem.Thiseffectreducesthevaluethatcanbegainedoutofretrospectives.Intheend,wereducedandthenincreasedthenumberofretrospectivesthatwehad in order to accommodate this. It was made clear quickly that we would want to do more imprompturetrospectivessotherewaslesstotalkandtimespentatthemoregeneralretrospectives.Thereneedstobesomebreathingroomtoallowtheteamstogettoknoweachotherabitmorebeforethenextretrospective.Now,attimes,theteams’retrospectdailywhichisalargeimprovementbutasateamgrows,givingfeedbacktopeopleyoujustmetisdifficultandrequiresbothsocialandstructuraldevelopmentbeforedeepissuescanbediscussed.

7.5 Bi-AnnualGoalsetting

Figure2.Timeline&ForcefieldRetrospectiveforBi-AnnualGoalSetting

Traditionally,ourgoalsettingandevaluationpracticewastocomeupwithafewgoalsfordeveloperstomeetand themanagerwould evaluate themon their performance in these areas.Wedecided after retrospectionthat we wanted to make better use of the biannual goal setting process and the time the company wasexpectingustospendonthem.Weendedupwithaprocessinwhicheachdeveloperhelpedfacilitateanotherdeveloper in two retrospective formats (see Figure 2). They did a timeline retrospective and a force fielddiagram,toisolateeverythingthathappenedtothedeveloperregardingtheircareerinthelastsixmonths.Theforcefielddiagramretrospectiveformatisoneinwhichtheparticipantidentifiesthingsthatareholdingthembackandmovingthemforward.Theideaisthattheseareforcespushingafieldbackandforth.Inotherwords,

GrowingtheMob:Page-8

thetime lineyields insights intoeventsthatwerepositiveandnegative forthedeveloperandtheforce fieldretrospectiveprovidesinsightintoeverydaybehaviorsorelementsofthatperson’slifethatarecontributingto or taking away from that person’s work experience. We identified two things from each section of theretrospectives that we could count as goals and then I, as a director, had one-on-one meetings with eachdeveloper. Ina laterretrospective,adevelopersaidthatthiswastheonlytimetheyhadeverhadarelevantgoalbeproducedfromtheiryearlycorporategoalsintheirentirecareer.

8. CONCLUSIONS

Overall, growingMobprogrammingatHunter Industrieshasbeenawonderful experience. I have learnedagreatdealaboutthedifferentwaysthatMobprogrammingcanaidinscalingAgileatanorganization.Ibelievemanyproblemsofscalingwerenotasmuchofanissueastheywould’veotherwisebeenhadwebeenworkingasindividuals.WebegantogrowtheMobandwhentheMobwastoobigwesplitintotwoMobs.AfterreachingsixpeopleinaMobwewouldsplit intotwoMobsofthree.Typically,wenormalizedatfourpeopleperMob.SincewetreateachMobasaSingleItemWorkinProcessdevelopmentstreamourgoalwastobeabletoreacheightstreamsofwork.Wecontinuedthestyleofgrowthandsplituntilreachingeightteams.

Wekeptalimitedhiringpaceoftwopeoplepermonth,whichhelpedusbetterintegratenewpeopleintotheprocessquickly.Ourfocushasbeenontechnicalandsocialexcellenceandourinterviewsreflectthat.Wepractice continuous integration and continuous delivery; we also train for agile coaching and automatedtestingwithintheteams.

In order tomaintain a close pulse on the progress of the team,we perform frequent retrospectives andtypicallyconsider itaproblem ifwehavegonemore thanaweekwithouta retrospective.WedesignedournewofficesspecificallytofostercollaborationandMobility,especiallytherequirementthateverythingintheoffice had to be on wheels. We have a flat department structure meaning we distribute the managementresponsibility and self-organize aroundmanagement related tasks andmaintain amanagementKanban.Wehaverequestedfromtheorganizationthatourproductownersbeengagedandalwaysavailableandwehavemade it clear to everyone in the organization thatwe practice no estimates. Themetrics thatwe currentlyvalueasateamare:thetimesincelastproductionreleaseforeachproject,thetimesincethelastretrospective,and the number of bugs in production, which should always be zero. Finally, as a director I am practicingservant leadership in order to provide the best environment possible for the team to be successfulwithoutbeingcommandinginmymanagementpractices.Sinceateamofthissizeissonew,wecanonlygetbetteraspeopleintheteamformnewbondsfromtheirexperiencesworkinginMobs.

Ialsofindthattheevolutionofourdepartmentstructurehasplayedagreatroleinmaintainingbuy-infromthedevelopersworkingontheteams.Ultimately,wehavefoundthatMobprogramminghasscaledwellforusandwearecurrentlyworkingonprojectswithfewtonobugs.Wehavehadstrugglesalongtheway,butourlearningsessionsandretrospectiveshaveplayedenoughofarolethattheseproblemsfadedasweprogressed.

9. ACKNOWLEDGEMENTS

Hunter Mob, I could not have had this experience without you. Your dedication to experimentation andawesomeculturehasmadegreat thingsable tobecomeevenbetter.CarolannLucian, thankyou fordealingwithmyfocusonmycareer,editingthispaper,andbeingthesoundingboardformyideas.HunterIndustries,MarcKase,ArnePike,andGregHunterIappreciateyoursupportandyourunwaveringtrustinourteamandprocess. I have heavily relied on JasonKerney,Dexter Baga, GordonPu, AaronGriffith, andWilliamGetz inordertohelpestablishandpropagateourculturetoournewhires,thankyouallforinvestingsomuchintoourideas.ThankyouWoodyZuillforputtingonamazingworkshopsandspreadingtheideaofMobProgrammingto theworld. I reallyappreciate the timethatRebeccaWirfs-Brockhasput intoshepherding thisexperiencereportitreallyhasbeenapleasure.REFERENCES [Griffith] Griffith, Aaron, “Mob Programming for the Introverted” Agile 2016 Conference, Atlanta, GA https://www.agilealliance.org/wp-content/uploads/2016/03/Mob_Programming_for-the-Introverted.pdf [Kerney] Kerney, Jason, “Mob Programming – My first team” Agile 2015 Conference, Washington D.C. https://www.agilealliance.org/wp-content/uploads/2015/12/Mob_Programming_-_My_first_team.pdf [Zuill] Zuill, Woody, “Mob Programming – A Whole Team Approach” Agile 2014 Conference, Orlando, Florida http://www.agilealliance.org/files/6214/0509/9357/ExperienceReport.2014.Zuill.pdf