DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard BECKYBERNDT,INTELCORPORATION

SharingaKanbanboardisagreatstarttogetteamsworkingtogetheronacommongoal,eveniftheteamconsistsofpeopleindifferentrolessuchasdevelopersandvalidators.Collaborationdoesnothappenautomatically.Wetookmanystepstonotjustgeteveryoneusingthesameboard,buteveryoneworkingtowardsacommoncycletimegoalof14daysfromstarttofullytestingaworkitem,thesamecycletimethatwasnearlyayearlongatthestart.

1. INTRODUCTION

Revolutionizingtheworldofmemoryandstorageasweknowittodaytakescollaboration.Beingonthecuttingedgemeansshiftingtimelinesleft,andproducinghighqualityworkinlesstime.Unfortunatelyourteam’snewdevelopmentwastakinglongerthanexpectedtovalidate,andeventhen,notthoroughly.Thishadtochangeorwewouldneverbereadytoreleasethisamazingproduct.

Developersandvalidatorsneededtocombineforces,cooperate,andworktowardscommongoalsinordertoclosethisgapandstoprevisitingcodethatwaswrittenasmuchasayearago.

Ourteamneededtoshareandvisualizecommongoals,worktogetheronadailybasistoreachthosegoals,and needed away to know ifwewere succeeding.We chose Kanban, awell-known process used bymanyagiliststovisuallyshowhowateamisprogressing.

2. BACKGROUND

IamblessedtobeasoftwareengineerworkingonthemanageabilitycodeforIntel’srecentlyannounced3DXPoint™. It’sexciting tobepartofsomething thatwill revolutionizememory technology. It’scrucial that thequalitybeoutstanding.Workingasanagilescrumteamtoshiftthetimelineleft,itwasimportanttohaveclear,open, and often communication as requirements changed.We needed to earn the right to continue callingourselvesBSTEs(BestScrumTeamEver,butwepronounceitbesties).

Wedevelopershaveoursetofunittests,butappreciatetheimportanceofafullblownvalidationsuiteoftests.However, itwasunclearhowmuchwascovered inour localvalidationteam’stests,andthevalidationteam was unable to react when features or requirements, and thus, our code changed. So imagine ourfrustrationwhenwehadalocalvalidationteamthatwasnotopentotakingtheriskandtryingsomethingnewbyjoiningforcesandbecomingonecohesiveteam.

Fastforwardafterarestructure,andwenowhaveanew,butremote,validationteam.Weknewwehadtoset this up for successwith both sidesworking closely from the beginning. It’s not how either the currentdevelopmentteamorthenewvalidationteamwasusedtoworking,andthevalidationtestsuitetheyinheritedwasincomplete.

3. MYSTORY

IhavebeenasoftwareengineeratIntelfor6years.ThelastfewyearsIhavealsobeenScrumMasterforour3DXPoint manageability software team located in Colorado. We used Scrum for our development for severalyears.WereachedapointwhereIfeltitwasimportanttobeabletoreactquickertochange.Alittleoverayear

BeckyBerndt,email:BeckyBerndt@intel.comCopyright2016isheldbytheauthor.

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-2

ago,ItookabriefKanbansessionduringanagileconference.Afterdoingalittlemoreresearch,Ithoughtitwassomething that could work for us. Showing the expected benefits from incorporating Kanban practices toconvincemyteamleadandmanagertoallowustomakethechangewaseasierthanIexpected.Theycouldseemyvisionandwere interested ingiving ita try.Almostexactlyayearago, justacoupleofmonthsafter theconference, itwas time tostart.Neverhaving followedKanbanprocessesbefore,wewereallexperimentingtogether,whichturnedouttobeagreatthing.AlreadyhavingourworkitemsinRally,weeasilysetupournewKanbanstates, createdouracceptancecriteria foreachcolumn,gavesomeKanban flowtraining,andoffwewent,stillfiguringsomeofitoutalongtheway.

We had a development team that worked well together for a couple of years on this project. We weredisappointed with what we felt was a lack of collaboration with our local validation counterparts. Thedevelopergroupandthevalidationgroupeachhadtheirownscrumteams,withtheirownrituals,and littlecrossover.Thevalidationgroupwasinvitedtothedevelopmentstand-up,review,planning,andretrospectivemeetings,butattendancewasrareandcommunicationwaspoor.Wedevelopershadnoideahowmuchofthecodewasgettingtested,and felt like thingswerebeinghidden fromus.Thevalidationgroupwas frustratedwhen specs and code behavior unexpectedly changed. We talked about it during stand-ups, but with fewcommongatheringsthecommunicationfailed.Wewantedbothsidestobeonthesameteam,communicatingandplanningtogether,givingstatusupdatestogether,andtalkingaboutprioritiestogether.Unfortunately,ourattempts to get the local validation to join forces to achieve better collaboration failed. I’ve always toldmyteam,“Ifitdoesn’twork,we’llchangeit.”What’stheworstthatcouldhappen?Wefailandgobacktothewayweusedtodothings?

About9monthsago,afterateamrestructure,ourvalidationworkwastransferredtoanewvalidationteamacrosstheglobe.Therewasaneighthourtimedifference.Theywerenewtoourteam,ourproductandtoouragilepractices.Themajorityofexisting functionalityhadnoassociatedtests,and tests thatdidexistdidnotrun,sotherewasalotofworktobedone.Giventhehistory,somedevelopmentteammemberswerenotsurethenewteamwasupforthetaskandwereafraidofstartingalloverwithanewgroupofvalidationpeople,notknowing anything about them, or what to expect, especially when they wanted to start with a whole newframework. Rumor had it the new validation teamwas not capable of doing the job.Needless to say, Iwasconcerned,butwewereallwilling to take therisk together.Turnedout,ournewvalidationteamwaseagerandwillingtotakeonthechallenges.That’sthelasttimeIlistentorumors.

Joining forceswas great, but of course therewasmorework to be done. Aswe all know agilemethods,including theKanbanboardvisual,don’t fix issues, they justmake themeasier tosee.Validation inheritedatestsuitethathadfewworkingtests.Theyhadtobuildanewtestframework,andimportexistingtestsintothisframework,hadmanyteststoupdate,andmanymoretoimplement.Thisallneededtooccurwhiletheywerevalidatingnewwork,oh,andlearningwhattheheckthisproductwasandwhatitwascapableofdoing.

Tojumpstartthenewteammembers,theygotanoverviewoftheproduct,andfreedomtoaskanything,anytime.Thispremisestillholdstruetoday.Wesharestand-upseverymorningwiththeentireteam,soweshouldknowexactlywhateveryonehasaccomplishedandwhattheymaybestuckon,whichinturn,tellstheteamwhatischanging.

ThemergestartedwithashortKanbanprocesstraining,havingbothdevelopersandvalidatorsjoiningindailystand-upsandretrospectives,andadding‘testinprogress’and‘testdone’columnstoourKanbanboard.The idealKanban flowwouldhavework items testedandacceptedbefore thedeveloperpushescode to themasterrepository.Thisensurestheworkiscompleteandcorrect,andpracticallybugfree.Ifullybelievethatonceweget to thispoint,we shouldhavenonewbugs filedbyourvalidation team,making the teammoreefficientandsavingalotoftimefixingdefectsinoldcode.Thecodechangesarefreshineveryone’smindandthiswouldavoidtaskswitchingbackandforthbetweenoldandnewcodechanges.However,asImentioned,codethatwascreatedasmuchasayearagoiswhatwascurrentlygettingtested,sowehadalongwaytogo.

Ithasbeendifficulttochangethethinkingthatwearenolongeradevelopmentteamandavalidationteam,butweareone combined team. Iwill say that again.Weareone combined team. If one failsweall fail.Wesucceedasateam.

Wetalkedabouthavingdevelopershelpbuildupthetestcases.ThePolandvalidationteamincludessomecontingent workers as well as Intel employees. Given the way things worked with contingent workers inPoland, and commitments the developers already had in place, it wasn’t an immediate option. Developerswere, however, able to answer questions quickly, share documentation that is kept in a shared documentrepository, and teach feature behavior in order to help get the newmembers of the team up and runningquickly.Inthemeantime,inordertoallowthetimetofillinmissingtests,IdecidedtohaveaninitialWIPlimit

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-3

of20forour‘developmentdone’and‘testinprogress’columns.Highenoughtoallowsomewiggleroom,butnotsohighthatwewouldneverrevisitthisifthenumberofitemsinthiscolumncontinuedtoincrease.

Figure1.ModifiedKanbanBoardCombiningDevelopmentandValidation

Our goal was always to have our developer’s code tested by the validation team before the code getscheckedintoourmasterrepository.Thiswouldkeepthenumberofdefectsdownanddeveloperswouldspendmuch less time task switching to revisit code that wasmodifiedweeks ormonths ago now that they havemoved on to other work items. In order to do this, our cycle time (days from ‘analysis in progress’ to‘accepted’)wouldhavetodecrease….alot.With3weekintegrationbuilds,ourcycletimeof25+daysstartingwiththenewteamwasjustnotgoingtocutit.Wewerereadytoacceptaweekindevelopmentandaweekintestasthemosttimeanyworkitemshouldtake.So,formanymonthsourcycletimegoalwas14days.Wealsoknewthatourcycletimewouldgetbiggerbeforeitgotsmaller,sinceweaddedthevalidationacceptanceaspartoftheflow.

InitiallyitwashardforvalidationtokeepKanbanworkitemsuptodatebecauseeverythinghappenedsofast.Developerswereimplementingfeaturesandfixingdefects,whilerequirementswerechanging.Validationwasnewtotheprocessanddidn’twanttofloodtheKanbanboardwithstoriessuchascompletelyredoingthetest framework andupdating tests, so they keptwork items off the sharedboard. They felt that since theiritemswereunrelatedtodevelopmentworkatthetime,itdidn’taddanythingusefulfortheoverallprocessandthey shouldnot clutterup theKanbanboard. I think itwouldhavebeenbetter tohave these itemson theboardforfulltransparency,abetterunderstandingofwhattheteamswereupto,aswellaspotentialplacesforotherteammemberstojumpinandhelp.Wenowputallvalidationworkitems,includingitemsthathavenodevelopment impact, and all development work items, including those with no validation impact, on theKanbanboardforalltosee.

4. PROBLEMS

Theeagernewvalidationteamandre-energizeddevelopmentteambecameonemanageabilityunit.Bothsideshappily jumped intostand-upsandretrospectives.Problemsolved, right?EverythingwehavebeendoingasBSTEs(“besties”,orBestScrumTeamEver)isperfect,right?Well…

Asexpected,thingswereabitbumpyatfirst.Wehadafewobstaclesrightaway.Therewasnowan8hourtimedifference.Validationhadasmallteamandtheirleadershipkeptchanging.Theyhadtocontinuetolaunchtheexistingtestsuiteontheoldframeworkwhilebringingthenewframeworkup-to-date.Theexistingtestsneeded to be pulled into the new framework and fixed, so no immediate improvement on the gapbetweendevelopmentandtestofanewfeaturewasrealized.

Therewasconfusiononpriorities.Developmentprioritieswerenotalwaysthesameasvalidation.WehadoneProductOwnersoprioritieswereexpectedtomatch.

Workingculturesweredifferent.Itwashardtobreakdownthebarrierof“it isourjobtodo…”,or“theyshould…”Infact,westillhearthatcomingupnowandthen.

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-4

5. GETTINGEVERYONEINVOLVED

Wekeptour3-weeksprintcycleandretrospectivesafterincorporatingKanban,whichprovedtobeimportant.Ourteam’spractice foroverayearhasbeentohaveadifferentmember leadtheretrospectiveattheendofeachsprint.Thenewteammembers jumpedright in.Retrospective leaderscansearch for techniquesorgetcreative and make up something fun. It is sometimes hard to keep the attention of creative people in aretrospective,butourteamrocksatcomingupwiththese.Wehavetowatchourtime,asweoftenrunoutoftimesincewearesoinvolvedinthegame.Havingvariedtechniquesforretrospectivesmeanspullingvarioustypesof ideasand information fromthe team.For instance, the “What Iknow, Idon’tknow” focusedon theteam’sknowledgebasearoundtheproduct,procedures,developmentandreleaseplans,etc.Thisfiredoffasetof bi-weekly team sessions for sharing themissingknowledge.The “WorstPossible Situation” retrospectivewasa funexplorationofwhattheworstpossibleoutcomeofournextstack integrationwouldbe.Wetalkedaboutcatsgettingintothelabandknockingthingsover,causingameltdownoftheentirecity,andblackholes.Granted,notlikely,butfunfortheteam,anddidactuallymakeuslookdeepintoapartofthecodethatcouldbemademoresecure.Duringthe“BreakupLetter”retrospectiveweeachwroteabreak-uplettertosomethingwedreadeddoingorwasinhibitingprogress.Thisallowedustoventandfocusonwaystospeedthingsuporimproveaprocessoraction.Let’s justsaysomepeopleareabitcolderthanotherswiththeirbreakups.Oneteammember’s original version of “Apples to Apples” allowed for some creative releases in a fun, slightlycompetitivegamewhilestillleavingwithsomegoodactionsonwaystoimprove.Severalotherspointedustoprocess changes to getmore communication goingduring the analysisphase tomake sure everyone agreeswhatitmeansforaspecificworkitemtobedone,eliminatingconfusionandreworkingtheitemattheendofthecycle.

Wetrackedcycletimeeachsprintandreviewedstatisticsduringourretrospectivesaswellascameupwithteamagreedpracticestohelpreducecycletime.

Figure2.CycleTimeGoalAgreement

Itwasno surprise that our cycle time increasedbefore it decreased.Our average sprint cycle timewentfrom10 to28 to60daysovera4monthperiod.Weunderstood thiswasbecause testswerebeingwritten,frameworkswerebeingput intoplace,andwearenowmeasuringthroughthevalidationacceptanceforthefirst time.Someof thestories thatwereon theKanbanboardwhenwecombined forceswerenowworkingtheirwayofftheboard.Wecontinuedtoreviewcycletimeandtalkaboutwaystodecreaseit,includingbeingsurestorysizeswerereasonable.Atthetimethenewvalidationteamjoined,developersweremakingchangestoacomplicatedfeatureusingvariousworkitemstotrackthesechanges.Validationwasusingoneworkitemtocreateallthetestsforthiscomplicatedfeature,anditturnedouttobeamuchbiggerjobthanexpectedandcouldnotbecompletedinasinglesprint,orevenseveralsprints,sotheitemsatinoneplaceontheKanban

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-5

board for several sprint cycles. Splitting user stories helped us better see actual progress by having thecombinedwork itemsmoveacrosstheboardagainonaregularbasis.Seeing itemsmovingtothe ‘accepted’columnisalsogreatfortheteammorale.Thereisanexcitementpeoplefeelwhiledraggingtheirworkitemstothe‘accepted’column.

Westruggledwithcommunicationaroundacceptancecriteria.Thatis,whatdoesitreallymeanforaworkitemtobedone.Ifdevelopmentandvalidationarenotinsync,theresultwillbedefectsfiledforunexpectedbehavior.Westartedoutbytalkingaboutworkitemsafterstand-upastheywerepulledintothe‘analysisinprogress’ column, and adding the agreed upon criteria to the work item description. This was hard to dowithoutbeingabletoresearchthestoryfirst,andpeopledidnotwanttostayafterstand-upsforthis.Wethenallowedthemtotaketheresponsibilityofgettingitdoneoutsideofteammeetings.Thisdidn’tseemtoalwayshappenandwe still endedupwithquestionswhen it came time for testing, sometimes causingdefects andrework. We then moved to requiring a template with more information to be included in the work itemdescriptionbefore itcanbepulled into ‘analysisdone’.Details includetheexpectedbehavioroncethisworkitemiscomplete,aswellasbothavalidationandadevelopmentpersonsigningoffinagreement.Thisatleastforcedsomekindofconversation,butwestillseemedtomissthepurposeoftheconversation,andthatistolookatwhatmustchange for thisparticularwork item,andwhat theendingbehaviorwillbe,agreedonbyeveryone.Thismade ita littleeasier tosee that thediscussionshappened,aswellasknowingthe impact toeachside,ifany.Whenthisgotdone,itworkedwell.Whenitdidn’ttherewasonceagainconfusionwhenwegot to the testing phase. Remember, the code was already checked into the master repository, so whenquestions and issues arose, defectswere filed since developers had alreadymoved on to otherwork items.Let’sfaceit.Wetendtofocusonwhatthecurrentpriorityorworkathandis,sogettingstoriesanalyzedthatyouwon’tworkonforamonthorreviewingdefectsforsomethingyoudidamonthagoisnottoponourlists.Westillgetdefects fileddueto lackofcommunicationontheagreeduponexpectedbehavioroncetheworkitemiscompleted,orbecauseawork itemwasnotanalyzedcompletely.All themorereasontorequirethatcodeisverifiedbeforeitischeckedintotherepository.

When the teamwas smaller, a 15minute stand-up was often enough time to ask questions along withtalkingaboutaccomplishmentsandplans.As the teamsizegrew,we justcouldn’t cover itall in15minutes,anymore.However,immediatelyafterstand-upbecameagreattimetoholddiscussions.Inpersondiscussions,oroverthephoneseemedtogetthequickestresponses.However,sometimesweneededmoredetailsonthesystemsetup,andemailworkedjustfineforthat.Wealsousedtoallowstand-upstorun5minutesovertimeasweweregettingstarted,butdecidedtocurbthediscussionandkeepthe15minutetimelimit inordertokeepthemshort,andtoallowsometeammemberstoattendtheirnextmeetingwithouthavingtoleavewhilediscussionsarestillhappeningduringourteamstand-up.

Theexceptiontodiscussingworkitemdetailsduringstand-upisforthosethathavebeencolorcodedhotpink or have discussion notes added in CATechnologies (formerlyRally). These can be color coded by anyteammemberforvariousreasons.Perhapsitisahighpriorityitem,ithasbeenontheboardalongtimeandweneedtogetitmoving,oritismissinganalysisinformationbutsomehowgotmovedacrosstheboard.Onceeveryonegivestheiraccomplishmentsandplans,theseareupfordiscussionduringtheremainderofstand-up,ifthereistime.Iftimerunsout,theyarewelcometostayonthecalllongertogetthesediscussed.

Mornings are prime time on the Colorado side. There is a short window betweenwhenwe can get USpeopleintotheofficeinthemorning,andthetimePolandpeopleleaveattheendoftheirday.Thisiswhenweholdourstand-ups(Monday-Thursday),andthisiswhenthemajorityofourdiscussionshappen.WerespectPoland’s Friday evenings and choose to not hold stand-ups on Fridays. Convincing someUS people to starttheirdayearlierwasnoteasy.Asateam,weinitiallydecidedtostartstand-upsalittleearlierthannormal.Afewmonths later,aftera teammemberandmanagerattendedaretrospective fromPoland,hungryandpastdinner time,we decided to start retrospectives even earlier. Coming in early once every 3weeks is totallydoable,andkeepsthePolandsidefromstayinglateintotheirevening.Ourvalidationfolksaretroopers.Theynevercomplained.

Even though we started sharing stand-ups and retrospectives, it is sometimes difficult to get to knowremoteteammembers,whenyouonly talkasa teamfor15minutesorsoeachday.Westartedusingvideoconferences forourretrospectives,allowingus toget toknoweachotherbetterbyseeing thewaythe teammembersworkwith eachother, andbeing able to see the facials and the energyon the screen.Thismakesretrospectivessomuchmoreentertainingandhelpsbondtheentireteam.Sincethevideoconferenceroomsare in different buildings on both the Colorado and Poland side, and they cannot be reserved for just 15

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-6

minutes,itisnotpracticaltousethemforourstand-ups,butIamworkingonotherwaystoincorporatevideointoourstand-ups.

Spreading the knowledge has also helped decrease cycle time. The developers have the philosophy thatanyoneshouldbeabletopickupthenextmostimportantworkitemandbesuccessful,regardlessinwhatpartof the code the change is needed. Validation initially assigned certain people to test specific pieces of themanageability application. They found it helpful and freeing to start sharing the knowledge of the variouspiecesthroughout,sothingsarenotheldupifthereare4itemstobetestedinoneleveloftheapplication,andnoneinanother.Theynowcanalsopickupthehighestpriorityworkitemtovalidate,regardlessofwhereinthecodeithappenstobe.

OurProductOwnerstartedholdingaweeklysyncmeetingwiththetechnicalleadstobesureallprioritieswerealigned.Inadditiontogettingeveryoneinsync,wearealsoabletocoordinateandpullindefectsthatareblocking a lot of validation tests onto our Kanban board to be fixed sooner rather than later, unblockingvalidationtests,whichresultsinquickeracceptanceofstories.

6. AREWETHEREYET?

Iwasjustabouttogiveuponour14daycycletimegoal,thinkingtherewasnowaywecouldhitthissinceour27daycycle time increasedto60daysandourteammakeuphadchangedseveral times.However,patienceandpersistencepaidoff.Aftersometeamchangesandnotcheckingforacoupleofsprints,withthehelpofateammate, I put together a scatter chart showing cycle times for each completedwork item, differentiatingbetweennewworkanddefects.Wewereallsurprisedtoseeanaveragesprintcycletimeof15.32days.Wecouldseethatourcycletimeperworkitemwasgettingmoreconsistent,withtheexceptionofafewoutliers.Stillnotquitewherewewanttobebutsomuchbetter.Nowthechallengewastofigureoutwhatwecoulddotogetevenmoreconsistent.

Figure3.CycleTimeScatterChart

Oneoftheitemsindiscussiontodayisthatattentiontoanalysisdetailsisstillnotbeingrecognized.Emailisnot answered quickly when the subject is not in the radar of the recipient. We are either not having thecompletediscussionsaroundexpectedbehavioroncetheworkitemiscomplete,ortheaffectedteamsarenot

0

20

40

60

80

100

120

140

160

180

CycleTimeinDays

EndofSprintDate

2016CycleTime

Goal UserStory Defect

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-7

fullyunderstandingtheimpactoncodeortests.Therearestillquestions,andevenstoryblockages,happeningintherightsideoftheKanbanboardforthingsthatshouldhavebeencaughtearlier.

Wearealreadycommittedtosomecurrentuserstories,butnowhavesetadateafterthesecommitmentsshouldbecompletefromwhichgoingforwardwewillnotallowcodetobecheckedintoourmasterrepositoryuntil it is testedbybothdevelopmentunit testsandvalidationtestsuites. Thisshould forcemorethoroughdiscussionsduringtheanalysisphase,beforecheckingincode,andshouldavoidanynewdefectssincenothingwillgetcheckedinuntilitpassesbothsetsoftests.

Figure4.FutureKanbanBoardRequiringTestAcceptanceBeforeCodeCheck-in

Afterthisdatewewilltakeonlythehighestprioritycodechangerequests,andinsteadspendtimecleaningup our defects andworking on some development code or build process improvements. By looking at ourscatterchart,wenoticedthatdefectsseemtohaveshortercycletimesthanuserstories,whichmakessense.Mostof thedefectsare filedbyvalidationsotests likelyalreadyexist for themsothereshouldbe little timebetweenmodifyingcodeforadefectfixandbeingabletoactuallytestandacceptit.Thisshouldhelpshortenthetimebetweenwhenanitemin‘developmentdone’canbemovedtothe‘accepted’column.Wehavesomelogisticstoworkoutonhowtohandlebuildsforthis,butIamconfidentthatthisamazingteamwillfindawaytomakeitwork,asusual.

AsofMay,thegapbetweendevelopmentcompletingaworkitemandvalidationpickingupthatsameworkitemwasabout1.5(3-week)sprints.Somuchcloserthanayear,butwestillneedtodosomethingtoshortenthattimegap.Itishardtobreakdownthebarrierof“itisourjobtodo<xyz>”.Ifdeveloperscannothelpbydesigningtests,whichonecouldargueisnotagoodideasincethetestswillworkjustlikeourcode,therearethingsdeveloperscando.Theycanbetheretoanswerquestions,andspeedtheknowledgetransferwithrapidstyle communication such as video or over the phone. The decisionwemade is to stop new development,beginningona specificdateafterour current commitmentsare complete.Wewill acceptonlya critical fewcode change requests, and just work on defects and some items to improve the development process thatwouldhaveno impactonvalidation.Weplan todo this for2sprintsgivingvalidation timetodevelopmoretestswithoutbeingbombardedwithmorerapidchanges.

IhavecreatedphysicalteamKudosboardsthataredisplayedbothinColoradoandinPoland.Thisiswhereteam members can thank another person for helping them with something, showing appreciation, orcongratulating a teammember for a jobwell done. I will admit it is difficult to form new habits, but I amenjoyingposting to it, andpeoplealwaysenjoy reading that something theydidwasmeaningful toanother.Teammembersareslowlyfollowingmyexampleandpostingkudoscardsoftheirown.Iamhopingthisboardgetsusedbyotherteamsinourlocation,andcanbecomeabuilding-widekudosarea.Everyonelikestoknowthattheyareappreciated.

DevelopersandValidatorsWorkingRemotelyTogetheronaSingleKanbanBoard-8

Figure5.ColoradoKudosBoard

I am also starting to look into trying some lean techniques that may work with our current processes.Alwayslookingtoimprovethewaywework,butIguessthat’sapaperforanothertime.

7. WHATWELEARNED

Communicationisthekey.Themoreweincreasedcommunication,thesmootherthingswent,andthecloserwegot toourgoals.Communication forus takesplace indailystand-upsretrospectives,knowledgesharing,phonecalls,IM,andemails.Realtimecommunicationgetsthequickestanswers,andusingthetimejustafterstand-upsisimportantbecauseofthetimedifference.

Ourwindowofsharedworkhoursisminimal,andweneedtotakefulladvantageofthecommonworkinghours. Our team respects each other, and for that I am thankful. I pay close attention to be sure the samerespect is given to all members, and we are sure to include the remote teammembers in discussions anddecisions.Theyareimportantinthesuccessofourproduct.

Breaking stories intomoremanageable sizedpieces allows for smaller code reviews, and validation testupdates at one time. Smallerwork items take less time to complete, which keeps itemsmoving across theKanbanBoard.Thiskeepsteammembersfrombeingtiedtoasinglestoryfortoolongwhichallowstheteamtomorequicklyreacttoprioritychanges.

Retrospectivescontinuetobevaluable.Weacknowledgethechallenges ina funwaythatkeepstheteaminvolved,thenwedigintoafewselectedchallengesandfindwaystoovercomethem.

Wedon’t just share aKanbanboard.We also sharework items.Developers and validators analyze eachworkitemtogether,andbothsidesmayhavetasksonthesameworkitem.

We share resources such as specs, requirements, and best known methods in a common location. Ourcodebasesandbuildsareavailabletotheentireteam.

8. ACKNOWLEDGEMENTS

Thankyoutomymanager,DeniseVitt,whohasshownconfidence inmeandallowedmetheopportunitytoleadtheteamaswetakerisksbyadjustingourprocessesonaregularbasis,aswellashavingencouragedmeto submit this paper. Thank you to our architect and product owner, Tiffany Kasanicky, for not onlyintroducingmetoagileprocesseswhenIfirstjoinedIntel,butalsobeingtheretobounceideas,andhelpkeepthe team moving in the right direction. Thank you to my entire team for being BSTEs, for being greatcommunicators,andforalwaysbeingwillingtojumpinandgetinvolvedinordertobetterourselvesandourproduct.Thankyoutomyshepherd,RebeccaWirfs-Brock,forherencouragement,valuableinsights,andquickfeedback.Youhelpedmeorganizemythoughtsandnotstressout,which iswhy Iwasable tocomplete thispaper.