Mob Programming is een softwareontwikkelingsaanpak waarbij het hele team aan hetzelfde ding werkt, op hetzelfde moment, in dezelfde ruimte en op dezelfde computer.
Mob Programming of Mobbing gaat over samenwerking, zoals in het Agile Manifesto beschreven is. Een team wat aan hetzelfde ding werkt, op hetzelfde moment in dezelfde ruimte, kennen we allemaal. Echt anders is: het samenwerken op één gezamenlijke computer. Het is echter niet zo dat alle teamleden toekijken hoe er een ander teamlid aan het programmeren is! Hoe het wel werkt is beschreven in dit artikel.
Mob Programming is bedacht in 2011 en in 2014 voor het eerst gepresenteerd tijdens Agile 2014. Daarna hebben steeds meer teams Mob Programming ingezet.
Dit artikel is gebaseerd op diverse artikelen, de website van de bedenker (Woody Zuill) en meerdere presentaties.
Mob Programming of Mobbing
Mob Programming is meer dan een uitbreiding op Pair Programming. Een aantal beoefenaars beschouwen Mob Programming zelfs als een scaling methode van Pair Programming. Pair Programming is een praktijk waarbij twee mensen samen op een gedeelde werkplek zitten en tegelijkertijd samenwerken aan dezelfde code.
Zoals eerder beschreven werkt het hele team bij Mob Programming continu samen op één computer om één werkitem tegelijk af te leveren. Teams die overeenkomstig Mob Programming werken samen aan bijna al het werk van een typisch software-ontwikkelingsteam, inclusief het definiëren van verhalen, het werken met klanten, het ontwerpen, testen en implementeren van software. Dit dus naast het vanzelfsprekende coderen.
Het werk wordt uitgevoerd in workshops of “work meetings”.
Het team bestaat uit iedereen die betrokken is bij het maken van de software en op dat moment nodig is.
Welke concepten dragen bij aan Mob Programming?
Mob Programming is o.a. gebaseerd op de volgende concepten:
- Directe communicatie, doordat de teamleden bij elkaar zitten.
- Samenwerking.
- Betrokkenheid van het hele team.
- Team alignment.
- Continu code review.
- Zelforganiserende teams om effectief te zijn.
We doen samen één ding heel goed en snel
i.p.v. meerdere dingen tegelijkertijd.
One-Piece Flow
Volgens Woody Zuill gaat mobbing over ‘One-Piece Flow’. Woody Zuill heeft eerst Mob Programming toegepast en toen het zeer succesvol bleek is hij op zoek gegaan naar een theoretische onderbouwing.
Hij was namelijk eerst niet in staat om uit te leggen waarom Mob Programming zo succesvol was, totdat hij zich realiseerde dat steeds de dezelfde verkeerde vraag werd gesteld. Door een tegenvraag te stellen, draait hij de gevestigde gedachten over samenwerking om. Woody stelt:
‘Hoe kun je eigenlijk met aparte zaken bezig zijn
als je moet samenwerken?’
Woody Zuill
Een belangrijk component van mobbing is dus focus. Focus in de juiste omgeving, waar iedereen de kans krijgt om het beste te leveren. De regel hiervoor is ‘thinking out loud.’
3 uitgangspunten voor Mob Programming
De uitgangspunten van Mob Programming zijn Psychologische flow, Lean Flow en Individuele Flow.
1. Psychologische flow
Interessant is dat Woody het boek van Jef van den Hout: Team Flow From Concept to Application gebruikt om zijn visie op psychologische flow te laten bevestigen.
Voor dit artikel is dit voldoende, wellicht volgt later een artikel van het gedachtegoed van Jef van den Hout.
2. Lean Flow
Lean Flow is de tweede flow van de theorie. Direct uit lean: complete productie van één stuk, van start tot finish, met zo min mogelijk werk in voorraad (inventory) en met zo min mogelijk wachten (gueueing) tussen de bewerkingen als mogelijk. Dat is volgens Zuill (voor de volle 100%) ook van toepassing op softwareontwikkeling.
De kern van trage ontwikkelprocessen is het principe van gueueing waste. In product development zijn wachttijden root cause van economisch waste. Althans volgens Donald Reinertsen.
Volgens Zuill is het combineren van psychologische flow en lean flow de reden waarom Mob Programming zo goed werkt. Dan ontbreekt er echter nog 1 flow. De individuele flow.
3. Individuele flow
De individuele flow staat voor het uitgangspunt dat elk persoon de veiligheid en de ruimte krijgt om op zijn eigen manier te denken. Als je alleen wilt zijn om te denken, dan ga je weg. Om te doen wat je moet doen. Ook als je bijvoorbeeld even moet uitrusten. Het is niet de bedoeling dat het team je dan erbij probeert te houden.
Hoe ziet het eruit?
Het hele team verzamelt zich rond één (liefst groot) scherm of zelfs meerdere schermen. Iedereen zit om de beurt aan het toetsenbord en werkt samen aan een probleem. Het interessante is dat je echt alles samen gaat doen, zoals bijvoorbeeld coderen, mail, incidenten en pauzes.
Er is een vaste werkverdeling: driver en navigator.
De driver zit achter het toetsenbord en de navigators vertellen/instrueren de driver hoe de code geschreven moet worden.
Impliciet zou de driver alleen moeten sturen (code typen en vragen stellen) en weten de navigators de weg en anticiperen ze wat ze op deze weg allemaal tegen zullen komen.
De driver doet niets wat niet wordt aangeboden, de navigators krijgen denkruimte en hoeven niet te sturen (typen). Overigens mag Mob Programming ook op afstand gebeuren, remote werken is heel goed mogelijk. Het lijkt immers dezelfde ruimte.
Het hele team doet mee, dus ook de tester, Product Owner en ontwerper. In sommige teams is ook de klant aanwezig. Voor Mob Programming geldt: iedereen werkt samen aan één taak achter dezelfde computer.
Aanvullende (nieuwe) rollen:
Oorspronkelijk bestond het concept uit één driver en waren er meerdere navigators. Zoals met elke methode, worden er aanvullingen door anderen bedacht. De navigators kunnen nu allen een andere achtergrond hebben, het waren in het begin ontwikkelaars. Als snel kwam de Product Owner ook in beeld.
Onderstaand een beschrijving van een aantal aanvullende (nieuwe) rollen die in de praktijk gebruikt worden.
1. De driver
De driver zit aan het toetsenbord en wordt gebruikt als de bliksemafleider voor ieders ideeën.
Enerzijds trekt de ideeën uit de hoofden van de navigators om code naar voren te halen. Anderzijds denkt de driver niet te hard na. De focus ligt op de implementatie van de vervolgstap die met de navigator is afgesproken.
2. De navigator
De navigator begrijpt wat de groep heeft besloten. Waar ze op weg naar zijn en heeft een plan de bestemming te bereiken. De rest van het team zal de navigator(s) volgen. Vragen of uitdagingen die niet direct bijdragen aan het beoogde doel worden uitgesteld tot een later moment.
Alleen als de navigator en driver op een een goede manier communiceren blijft de energie hoog. De driver krijgt vooral de intentie mee en is geen ‘uitvoerder’ van een ‘voorgedragen’ te schrijven code.
3. De facilitator
De facilitator rol is een bekende rol en wordt hier niet volledige beschreven. Samenvattend: observatie, afspraken en samenwerkingen.
4. De verkenner, de scout, de onderzoeker
Ook Mobs lopen tegen problemen aan, veelal door een gebrek aan informatie. Verkenners lopen vooruit en gaan informatie verzamelen door bijvoorbeeld te praten met klanten of zich in te lezen op een specifiek (technisch) onderwerp. Scouts kunnen een huidig teamlid zijn, of een teamlid die uit de Mob stapt om een periode solo op pad gaan.
5. De kolonist of huishouder
Gaat de verkenner op pad, de huishouder of kolonist blijft thuis. Hij zorgt ervoor dat alle code die gebouwd is en niet gebruikt, of later gebruikt wordt, of nog te doen is goed wordt bijgehouden.
De belangrijkste taak is om de ‘code’ schoon te houden. Zodat navigatie en gebruiksgemak van de code groot blijft. Dit is een minder geliefde taak, want het lijkt er vooral op dat je de rommel van een ander opruimt. Maar, net als andere taken zal ook deze rol worden gerouleerd.
6. De Advocaat van de duivel
Richt zich op “groepsdenken” scenario’s. Zorgt ervoor dat alle argumenten zijn gehoord en zoekt naar gaten in het besluitvormingsproces van de groep, voor het geval er iets over het hoofd wordt gezien. Is scherp op mogelijke problemen, mogelijkheden, tegengestelde ideeën en op kwaliteit. Deze rol kan ook bij de facilitator liggen, maar de facilitator is veelal geen deskundige op de materie.
De Product Owner
Veelal niet (continu) aanwezig in het team. Toch neemt deze een belangrijke positie in. Vragen die alleen de Product Owner kan beantwoorden mogen niet op zich laten wachten. Binnen Mobbing is wachttijd niet acceptabel.
Er is een hele simpele afspraak. De Product Owner krijgt snel zijn product(aanvullingen) of increments opgeleverd, mits de reactietijd op vragen uit het Mob-team uitzonderlijk snel is. De gewenste reactietijd is hooguit enkele minuten.
Overige rollen
Er zijn ook andere rollen in gebruik, want elk team zal zijn eigen afspraken over de benodigde rollen maken. Een driver en navigators zijn echter de noodzakelijke rollen.
Starten?
Het filmpje ‘A day of Mob Programming‘ toont een timelaps hoe mobbing er uit kan zien.
Voordat men start als Mob moet eerst worden uitgezocht welke taken gedaan moeten worden. De User Story is bepalend. Dit leidt veelal tot een gesprek over de taken die moeten worden verricht. Welke benaderingen er allemaal mogelijk zijn en dit brengt interessante discussies.
Mobs kiezen voor roulerende rollen. De tijd van een cyclus wordt door het team bepaald en na de afgesproken tijd, wisselt de driver naar navigator en neemt een andere navigator de rol van driver over.
Een ander gebruik is dat degene die even wegloopt, bij terugkomst direct de rol van driver overneemt. Hij of zij zal dan binnen enkele minuten weer begrijpen wat er is gebeurt tijdens zijn of haar afwezigheid. Ook korte pauzes worden vaak in gezamenlijkheid gedaan.
Hoe kan dit efficiënt zijn?
Buitenstaanders die nog nooit als Mob hebben gewerkt reageren allemaal hetzelfde. Ze zijn er altijd vrij zeker van dat Mob Programming niet efficiënt kan zijn. En toch wordt Mob Programming over de hele wereld gebruikt.
Dat Mob Programming niet efficient kan zijn lijkt inderdaad een logische reactie. We zijn er immers aan gewend geraakt dat meer mensen, meer kunnen typen en doen dan een enkeling. En dat is nu net de kern van de zaak. Het gaat bij software ontwikkeling NIET over code schrijven en typen.
Want deze benadering doet heel erg denken aan de vraag: hoeveel regels heb je geschreven? Waarbij het aantal regels soms belangrijker lijkt dan een optimaal product.
Bij mobbing gaat het om het bouwen van een product. Waarbij de opbrengsten en kosten liggen bij het oplossen van een probleem, het voorkomen van waste (m.n. wachttijden) en first time right. Aspecten die niets te maken hebben met jouw type snelheid en alles met een goede onderlinge afstemming.
Wanneer werkt MP niet?
Een van de belangrijkste voorwaarden van Mob Programming is dat alle teamleden zich comfortabel moeten voelen bij het stellen van vragen in het bijzijn van het hele team. Daarom is Mob Programming niet geschikt voor alle teams.
Je kunt het gebruiken voor het oplossen van één fout, sommigen doen het een paar keer per week en anderen gebruiken het continu.
Als het een methode is om één fout op te lossen zal je Mob Programming vermoedelijk fantastisch vinden. De dynamiek, de snelheid, het open gesprek en het nieuwe is super aantrekkelijk.
Op het moment dat je gaat starten met MP op continu basis dan kunnen er ook andere reacties plaatsvinden. Hoe denk jij erover om jouw methoden, ideeën, snelkoppelingen, mail en kennis non-stop te moeten delen?
Wat je in jaren heb opgebouwd kan ter discussie worden gesteld, zelfs jouw denk- en praatsnelheid zal je wellicht aan moeten passen. Je denkt heel dicht bij je collega te staan, blijken jullie veel verder uit elkaar te staan dan je dacht.
Sommige teamleden worden door de intense samenwerking vrienden, sommigen kunnen hier niet goed mee overweg. In het slechtste geval is de eerste week of zelfs de weken erna niet de fijnste periode in jouw carrière.
Maar er valt ook veel te winnen!
Het intense samenwerken binnen de Mob levert voordelen die reguliere ontwikkelteams niet kunnen overbruggen.
1. Geen communicatieproblemen
Je hoeft niet meer te wachten op je vraag, geen mail meer te sturen of te bellen. Iedereen die je nodig hebt is aanwezig. De tijd die je moet wachten voordat je antwoord heb op je vraag. Dit heet in het Engels: question queue time. Een van de grootste belemmeringen in software ontwikkeling.
2. Besluitvorming gaat snel
Het hele team is, alle informatie is beschikbaar en elke beslissing leidt tot continue leren. Dus ook degene die de beslissingen kan nemen: de Product Owner is nabij.
3. Geen verspilling.
Elke dag wordt alleen gedaan wat echt nodig is, geen stokpaardjes of onnodige toevoegingen. Wachttijden worden niet geaccepteerd. Dus weinig tot geen verspilling.
4. Minder Technical debt
Iedereen werkt aan hetzelfde, het opbouwen van technical debt wordt direct geconstateerd door de deelnemers. Het invoeren van software met technical debt wordt velen malen kleiner.
5. Continuïteit
Het vertrek of komst van een nieuw teamlid heeft minder impact. Alle kennis is gedeelde kennis.
6. Teambuilding
Teamleden hebben allemaal profijt van het beste product, er is geen individu die het geheel kan claimen. Politiek is niet meer nodig.
7. Afstemming
Werk, kennis, besluitvorming vinden plaats in een non-stop overlegmodel. Een beter afstemmingsmodel is er niet. Door deze afstemming zal de actie effectiever zijn.
Samenvatting
Mob Programming is eenvoudig uit te voeren, het concept is namelijk in de basis simpel. Doe één ding tegelijkertijd en doe dit heel goed en zo snel mogelijk.
Het hele team neemt deel aan het ontwerpen, coderen, testen en werken met klanten, gebruikers en andere stakeholders. Mob Programming maakt gebruik van de kennis van de hele groep om snellere en betere beslissingen te nemen. Dit verhoogt de productiviteit van het team en de kwaliteit van hun output.
Wellicht zijn er andere mogelijkheden voor dit concept, zoals: marketing, leiderschap en overal waar ontwikkeling van nieuwe producten of concepten nodig is. Vergaande samenwerking leidt tot nieuwe mogelijkheden.
Toch is een waarschuwing ook op zijn plaats. Mobbing is niet voor iedereen geschikt en het is zeker wijs om de andere vormen van programmeren ook te blijven overwegen. Soms is solo programmeren of pair programming geschikter. Ook team varianten als kleine teams, grote teams, remote teams en Dynamic Reteaming zijn alternatieve mogelijkheden.
Als je geïnteresseerd bent in Mob Programming kan ik mij voorstellen dat je een presentatie van de bedenker wilt bekijken. Bijgaand de link voor een presentatie in India van ca. 45 minuten: Mob Programming door Woody Zuill – Agile 2019.