Experimenteren met Mob Programming

Maar eerst even kort over wat Mob Programming is. Van de Mob Programming website van de bedenker (Woody Zuill):

All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.

Kortom: je splitst het werk van een team niet meer op in taken om er dan individueel aan te werken. In plaats daarvan voer je de taken van het team serieel uit, met iedereen uit het team tegelijk aan dezelfde taak. Eigenlijk gewoon een opgeschaalde versie van Pair Programming dus.

Vermoedelijk heb je direct een serie vragen. “Is dat niet verschrikkelijk inefficient?” en “Hoe werkt dat in de praktijk dan?”, of “Wat nu als er [praktisch punt x] gebeurt?”. Als je deze vragen hebt of krijgt van anderen, let dan goed op in welke categorie ze vallen:

• Retorische vragen, met de eigenlijke gedachte erachter: “dit kan niet werken want ik zie teveel vragen en praktische obstakels, en ben ook niet écht bereid mijn standpunt daarin te beproeven”.
• Oprechte vragen, die je eigenlijk ook over Pair Programming kunt stellen.

Veel van de vragen worden behandeld door Woody Zuill op eerdergenoemde website. Er is ook een uitstekende podcast met Scott Hanselman en Woody Zuill waar ze er dieper op in gaan.

Ons Experiment

Ik wilde die vragen vooral zelf eens aan de tand voelen. De enige goede manier om dat te doen is door het concept eens te proberen met een groep. En dan ook écht proberen, het een serieuze kans geven. Nou had ik met mijn project de perfecte baseline voor een experiment:

• Buy-in van onze project-sponsor. Heerlijk als mensen open staan voor een experiment!
• Buy-in van de beoogde deelnemers. Iedereen wilde het een oprechte kans geven.
• Een Epic die ongeveer een volle dag werk in beslag zou nemen.
• De noodzaak om kennis rondom deze Epic cross-team te delen: uit elk team waren 1 of 2 developers aanwezig.

We hebben uiteindelijk in totaal 6,5 uur met 5 mensen aan die ene Epic gewerkt. Aan het eind van de dag hadden we (a) de beoogde kennisdeling behaald, en (b) waarde voor de business opgeleverd: de feature was af. Halverwege en aan het eind van de dag hebben we een mini-retrospective gedaan om het proces te verbeteren.

Bij de eerste retro kwam vooral naar voren dat we vaker de persoon achter het keyboard moesten wisselen: dus dat hebben we daarna gedaan. Bij de laatste retro constateerden we dat we meer moeite hadden moeten doen om core stakeholders aanwezig te hebben tijdens de dag (eigenlijk wisten we al van Woody Zuill’s content dat dit belangrijk was, en dat bleek maar eens). Maar, vooral ook, we constateerden dat het een bijzonder nuttige aanpak was geweest. We vonden Mob Programming eigenlijk gewoon een groot success!

Mijn Persoonlijke Conclusie

Ik vond het een enorm succes, meer nog dan ik van tevoren had verwacht. Maar, het is nu niet zo dat ik dit de nieuwe werkwijze van mijn team wil maken. In plaats daarvan denk ik dat ik Mob Programming toch liever bewaar voor “als de planeten op één lijn staan”. Buy-in van de project-sponsor, je teamgenoten, en de stakeholders is cruciaal. En de Epic waar je aan wilt werken moet zich er voor lenen; als dat niet het geval is kost het nog veel meer moeite en buy-in van iedereen.

Mocht je ooit een kans zien: probeer het dan vooral eens, met een open blik! Ik zal zeker wat vaker de optie in gedachten houden om een taak op deze manier op te pakken.

[Jeroen is developer bij Infi]