Kender I den situation hvor hverdagen i dit team er blevet lidt for meget brun sovs og kartofler? I refiner på en måde I fandt frem til for 6 måneder siden, I nedbryder i tasks som I lærte da I var på Scrum kursus og I producerer i Sprintet som I har gjort i en menneskealder.

Hvis det lyder genkendeligt, så læs videre og bliv inspireret til at prøve at arbejde anderledes i teamet.

I dette indlæg vil jeg forsøge at beskrive en metode kaldet mob-programming som er en “whole team approach” til opgaveløsning. Kort fortalt, så er det par-programmering på steroider:

• traditionel par-programmering udføres af to udviklere; een der skriver koden og een der løbende reviewer og giver inputs
• mob-programming udføres af et helt team; een person styrer tastaturet og mus mens resten af gruppen navigerer inputtet

Essensen i mob-programming er at enhver ide skal gå fra din hjerne via en anden persons hænder før det rammer computeren

Mob-programmering udføres ved hjælp af to roller:

1. Chauffør: Personen der sidder ved tastatur og mus. Personen handler på det input som navigatørene giver.
2. Navigatør: Gruppen af personer som står bag chaufføren. Gruppen diskuterer og giver input til chaufføren om hvad der skal gøres på computeren.

Rollerne skifter efter round-robin metoden, hvor alle personer på skift sidder 15 minutter som chauffør. Når hele gruppen har prøvet at være chauffør afholdes et retrospektiv for at forbedre processen fremadrettet.

En dag med mob-programming kan stykkes sammen som følger:

1. Velkomst og introduktion til mob-programming
2. Specifikation af arbejdshypotese for dagen
3. Selvorganiser i teams af 5-9 personer
4. Mob-programming i runder af 15 minutter
5. Retrospektiv efter hver runde af mob-programming
6. Demo resultat af arbejdet
7. Planlæg handlinger fremadrettet for opgaven
8. Diskuter hvilken læring dagen har tilvejebragt

For at sikre størst muligt udbytte anvendes elementer fra hypotesedrevet udvikling. Hypotesen specificeres i fællesskab i starten af dagen og i slutningen af dagen evalueres produktet i forhold til denne. Det er vigtigt at specificere en realistisk, men ambitiøs, hypotese der sætter rammerne for en kompleks problemstilling.

Hypotesen kan med fordel udformes efter denne skabelon:

Vi tror at <denne evne eller egenskab>
Resulterer i <dette produkt>
Vi ved vi har nået målet <når vi kan indfri dette mål>

Eksempel på en hypotese:

Vi tror at sporbarhed på tværs af systemlogs
Resulterer i mindre tid brugt på support / lettere support i teamet
Vi ved vi har nået målet når fejl kan fremsøges på 2 minutter

For nylig faciliterede jeg et udviklingsteam i mob-programming og deres feedback på dagen var:

• Kender sine kolleger bedre
• Prøver at arbejde uden for sin tryghedszone
• Arbejder i en anderledes konstellation end normalt
• Teamet tager fælles ansvar for opgaven
• Kort proces fra ide til prototype
• Alle i teamet har mulighed for at give inputs

Indlægget er også udgivet på Ugilic’s blog.