Mob programming med Woody Zuill

Han dök upp när vi satt och åt frukost vid matbordet. Han hette Woody Zuill. Vi hälsade snabbt, men flyttade oss snart till rummet där vi skulle hålla till med dagens workshop:

Mob Programming med Woody Zuill

Som första uppgift bad han oss att skriva lappar med våra förväntningar på workshopen. Han blandade genomgången av dem med roliga historier och gott humör. Sedan drog han igång.

Vi började med att introducera oss själva i gruppen och skapa namnskyltar och lägga på golvet. För övningens skulle fördelade vi roller som produktägare, testare etc mellan oss i teamet på ett sätt som kändes lämpligt.

Huvudtanken med mobprogrammering är att den som tänker inte ska skriva kod. Det liknar parprogrammering, fast det blir fler par ögon än två. Ett exempel Woody tog upp visade att utveckling som skulle ha tagit flera veckor blev färdig inom några dagar med mobprogrammering. Detta eftersom alla berörda var på plats och det då blir färre missförstånd. Buggar och fel upptäckts tidigare och det gör att utvecklingstiden minskas markant samt att det blir bättre kvalitet på koden. Hans upplevelse var att även erfarna utvecklare brukar bli överraskade över hur mycket fel de gör. Genom mobprogrammering kan också nya teammedlemmar sätta sig in koden snabbare och det blir bättre kunskapsöverföring. Kodandet blir mer en social upplevelse och det leder till bättre samarbete i teamet.

Principen är samma som parprogrammering. En navigatör som vägleder och en förare som kör (skriver kod). Även i mobprogrammering finns en navigatör. Skillnaden är att det i mobprogrammering dessutom är fler par ögon på koden. Alla tittar på en stor skärm och tänker medan den som sitter vid tangentbordet blir guidad av enbart navigatören. Hur mycket en navigatör behöver guida beror på hur mycket föraren vet om vart vi ska någonstans.

Han drog ett exempel om detta:

När han satt i bilen med sin fru och hon körde bilen. Frun frågar, “ Vart ska vi någonstans” . “Hem, snabbare att ta motorvägen” svarar han och hon visste exakt hur hon skulle köra då. Sen frågar frun var den där billiga bensinstation han visat en gång förut ligger, vilket inte är exakt på vägen hem utan skulle göra att det blir en omväg. Då behövs mer hjälp för att hitta fram.

Mobprogrammering kan vara som båda fallen, ibland behöver inte föraren så mycket instruktioner från navigatören utan det räcker med enkla instruktioner, som “hem via motorvägen”. Ibland behövs det tydligare guidning, men det ska inte bli “read aloud code” där navigatören dikterar ord för ord, utan då är det bättre att ge riktlinjer och kommunicera hur hen tänker för att hjälpa föraren.

Ett annat misslyckande blir när föraren tar över både navigering och körning, då blir navigatören utan uppgift. De övriga i gruppen tittar på utan att förstå vad föraren gör, förrän kanske efter att föraren redan är klar.

Sen finns det ett fall när alla i gruppen vill bli navigatörer, pratar samtidigt och lyfter fram sin egna ideer. När föraren får instruktioner från alla håll samtidigt blir det bara kaos. Det gäller att vara öppen för att testa olika ideer och inte prata samtidigt. Han skämtade om att många problem skulle försvinna om man inte pratade så mycket. Hur gör man då om någon plötsligt får en ingivelse? Jo man skriver ner dem, för man vill inte att de ska glömmas bort så klart.

Woody gick även kort igenom en rad andra utmaningar, t.ex. hur man kan få med teammedlemmar som arbetar remote genom delade skärmar.

Dagen avslutades med reflektioner över hur man kan använda detta i Scrum. Retrospektiv skulle kunna göras som “Just in time retrospective” där man snabbt i slutet av dagen fokuserar på en fråga som verkar viktig i stunden. Stand-ups skulle inte behövas längre eftersom alla har koll på läget efter att arbetat tillsammans hela tiden.