Produktivitetsparadoxen – en arbetar och sju tänker

with No Comments

Att arbeta i team istället för var för sig som olika individer i ett projekt som styrs från centralt håll har tidigare varit kontroversiellt men är knappast längre något som man lyfter på ögonbrynen för. Steget att gå över till ytterligare en samarbetsform som t ex parprogrammering där man sitter två personer vid en dator har haft lite samma resa – från att vara rent bortkastad tid till att ge synliga resultat och vara åtminstone accepterat inom utvecklarkretsar där man har ett agilt synsätt på sin omvärld.

Mobbprogrammering

Men man måste ju inte stanna där utan ta med sig alla bra saker från dessa två förhållningssätt och utöka det ytterligare. Det är precis så Woody Zuill uttrycker sig – “turn up the good” när han pratar om hur de experimenterade sig fram till mobbprogrammering som är ett helteamsgrepp på systemutveckling. Woody är idag den kanske främste förespråkaren inom ämnet och ger workshops runt om i världen.

Man kan sammanfatta konceptet med “att hela teamet jobbar som ett team tillsammans med en uppgift i taget, en aktiv dator, ett aktivt tangentbord, en skärm (eller projektor). Som parprogrammering för ett helt team”.

Faciliteringshjälp

För att få en liten smak av hur det här fungerar så beslutade vi oss för att göra ett experiment inom området. Som tur är så känner jag Lennart Fridén som är landets enda (?) expert inom området. Vi avsatte en dag för att han skulle kunna facilitera en övning där teamet kunde få testa på detta.

Lennart inledde med att berätta lite kort om vad mobbprogrammering handlar om och vävde in lite berättelser och bilder från sin gesällresa som han gjorde under ett par månader 2015. Han slutade sitt jobb och bestämde sig för att resa runt till olika arbetsplatser för att bjuda på sin tid och arbeta tillsammans samt lära sig av teamen på plats. En underbar korspollinering i många olika led. Han tog med sig just konceptet mobbprogrammering till flera ställen och plockade upp saker på varje ställe som kunde spridas vidare på de andra platserna.

Hur funkar mobben?

Men dagen handlade inte så mycket om teori som om praktik så vi fortsatte snabbt till teamrummet där vi hade satt upp en arbetsstation uppkopplad till vår stora TV. Runt platsen som var “förarplats” gjorde vi också sittplats till alla så kallade navigatörer. I mobbprogrammering, precis som i parprogrammering (strong-style), så är det bara föraren som skriver och alla navigatörer som säger vad som ska skrivas. Detta betyder att föraren bara ska skriva saker som navigatörerna har sagt. What!? Så man är bara en “intelligent input device”? Ja det kanske låter lite slösigt men låt mig ta ett abstraktionssteg uppåt och förklara tanken bakom detta. Att lösa en uppgift består av att lösa en rad olika problem på olika abstraktionsnivåer. En är på radnivå där man måste skriva rätt syntax för att uttrycka det man vill få fram. En annan är på metodnivå (som också ska hålla sig till en abstraktionsnivå). Ytterligare en är sammansättningen av metoder och så kan man fortsätta tills man har hela syftet uppfyllt. Mobben runt omkring kan även hålla koll på vad som händer ett eller flera steg framåt i skedet. Fördelen med “strong pairing” och en strikt förar- och navigatorroll är då att navigatörerna jobbar med den lite större bilden och kan bolla en eller tre abstraktionsnivåer upp, medans föraren bara behöver jobba på den lägsta. Arbetssättet är att navigatörerna beskriver för föraren vad hen ska uttrycka i kod och föraren översätter detta till kod. Om föraren inte vet hur eller förstår vad hen exakt ska skriva så ber hen om hjälp och navigatörerna får beskriva bättre. Det här sättet att arbeta på sprider information om uppgiften och arbetssätt väldigt fort. Det dröjer inte länge innan snabbkommandon eller andra fiffiga trick för att snabba upp arbetet poppar upp när “mobben” ser att någon inte går så snabbt som det borde. Mobben runt föraren kan tänka flera steg framåt och även ha små diskussioner om vad man ska göra härnäst, utan att föraren behöver ta fokus från sin tankeverksamhet för stunden. En regel som kan vara bra att hålla reda på är att den som har bäst koll på vilket håll man ska åt just nu inte ska sitta vid tangentbordet. Det låter bakvänt men det är det bästa sättet att sprida den kunskapen inom mobben via ord istället för via kod som det kan bli om den personen bara hackar på.

mob2

One-piece-flow, riskhantering och inga möten i ett slag

Men vilka problem är det som det här sättet att arbeta är tänkt att lösa? Utan att inbördes rangordna dem kommer här en lista med fördelar som mobben är tänkt att ge:

  • Man jobbar alltid med rätt sak, dvs den som är högst prioriterad. När den är tillräckligt löst (dvs inte till perfektion) så kanske något annat är det viktigaste. Mobben identifierar detta, speciellt om t ex Produktägare ingår i mobben.
  • Vi har ju alla toppar och dalar under dagen och om man jobbar som vanligt så blir resultatet per person också toppar och dalar under dagen. I mobben ligger istället resultatet hela tiden nära toppen för att det är alltid några som har energi. Har man för stunden låg energi kan man t o m zooma ut från mobben och göra något annan en stund.
  • Om man gillar Lean så är arbetsättet väldigt nära one-piece-flow och skapar grunden för ett dragande system (Pull) då man jobbar med en sak i taget och försöker ta det hela vägen i mål.
  • Eftersom teamet hela tiden pratar om vad de gör och ska göra så behövs inga andra möten eller överlämningar (inom mobben). Varför ska man ha en daily standup när man iaf jobbar tillsammans med en sak i taget?
  • Mobben kan fortsätta jobba trots att någon eller några lämnar eller gör annat, dvs icke fragilt
  • Teamet kan tillsammans jobba samtidigt på flera och högre abstraktionsnivåer och även tänka några steg framåt. Den enskilda individen måste inte både kontextswitscha och byta abstraktionsnivå som är fallet i större grad när man t ex parprogrammerar.
  • Mobben håller hela tiden koll på kontexten, så om en eller flera ur mobben försvinner så kan de sedan återvända utan att man behöver stanna upp och förklara vad som gjorts under tiden. Har de för tillfället minst koll på vad som ska göras så är de t o m som mest lämpliga att vara förare.

mob1

Skarp övning

För att ha ett problem att verkligen bita i tog vi tag i en uppgift som vi upplevde som komplex och där nästan ingen i teamet hade kunskap om koden. Till att börja med pratade vi om problemet och gick sedan in i ett undersökande läge med person efter person vid tangentbordet. Klockan var satt på 10 minuter per person under de första varven (och till 5 de sista 2 av sammanlagt 5 varven). Tyvärr så strulade systemen en hel del och vi hade problem att återskapa felet som vi skulle undersöka och åtgärda.  Sådana saker är givetvis en bra läropeng och det känns mycket mer kostsamt när man sitter i en mobb med hela teamet. Gör man allt arbete inom teamet i mobben så tar man tag i alla dessa saker så snart de känns. Alternativt sätter man dem på en backlog för att fixa så snart det går.

När vi hade grävt oss in i problemet lite mer hittade vi till slut det vi trodde var roten till allt ont. Eller åtminstone något som låg nära symptomet. För att lösa själva grundproblemet insåg vi snabbt att vi helst skulle vilja skriva om en stor del av koden och vi tittade istället på lösningar för att symptomet inte skulle bubbla upp till ytan och krascha programmet. Lennart coachade teamet i lite olika sätt att tänka kring detta och vi fick till slut till ett eller flera test som påvisade problemet. Med dessa väl på plats kunde vi göra den ganska enkla kodändringen som löste “problemet”.

Eftersom inte så mycket tid fanns kvar av arbetsdagen hann vi inte med att gå in på en djupare lösning av grundproblemet. Istället tog vi tag i en kata som Lennart tog fram och även satte vissa restriktioner på hur vi fick jobba rent arbetsmässigt. Det handlade om att genom testdriven utveckling lösa problemet “är året ett skottår?”. Det var en liten utmaning eftersom vi inte jobbar enligt TDD i vanliga fall men teamet kom snabbt in i det och vi fick öva på att arbeta som en mobb i lite högre fart när problemet var lite mer lättarbetat.

Saker vi lärde oss

Det känns som om vi fick en bra inblick i hur det kan gå till vid mobbprogrammering och det var ganska annorlunda än det vi testat tidigare i mindre strikt form. Några av lärdomarna som kom fram på det avslutande retrospektivet var:

  • Att det gick så bra att “inte tänka kod”
  • Hur snabbt tiden gick när man var förare.
  • Att vem som helst kan delta och bidra till mobben
  • Att man inte fastnar i roller
  • Att diskussioner om principer och kodsätt kommer upp direkt
  • Vilken snabb förståelse som mobben fick för problemet / lösningen
  • Inkluderande
  • Att snabbt få många infallsvinklar

Vad vi tar med oss

Som team kan vi sammanfatta allt detta med att vi ser ett bra värde i metoden och  gärna skulle vilja arbeta mer med det, antingen på hel- eller deltid eller koncentrerat när vi har mer komplexa och/eller viktiga arbetsuppgifter. Om det är några andra team som vill prova konceptet så hjälper jag gärna till med uppsättning och facilitering.  Kontakta mig i så fall via bjorn.tikkanen@nethouse.se

Follow Björn Tikkanen:

Agile coach with passion for helping people helping others.

Leave a Reply