scrummaster.nl

Wil je als team of bedrijf verbeteren dan zul je, net als sporters, daarvoor moeten gaan trainen. Dat hoeft niet altijd een cursus te zijn. Ook intern, zelf zonder budget zijn er uitstekende mogelijkheden die beter werken dan externe dure cursussen. Een interactief en ervaringsgericht concept is bijvoorbeeld de coding dōjō.

Een dōjō is de zaal waarin men op een veilige manier werkt aan zijn of haar vaardigheden van diverse Japanse vechtkunst en -sporten zoals Jiu-Jitsu, Judo, Karate en Aikido. Dit gebeurt onder andere met kata’s (型) en randori’s (乱取り).Een kata is puur gericht op de vorm en kent vaststaande stappen en technieken. Een randori is vrijer en interactiever. Een deelnemer wordt geplaatst in een gecontroleerde en veilige aanvalssituatie.

Een coding dōjō is een bijeenkomst van een aantal ontwikkelaars die bij elkaar komen om een uitdaging aan te gaan en om daarmee hun vakmanschap te verbeteren door te delen en te observeren en plezier te hebben. Dit kan met behulp van een oefening met vaststaande stappen (kata) of met een interactievere vorm (randori).

Een randori stijl coding dōjō is eenvoudig op te zetten. Het enige wat je nodig hebt is een ruimte waarin je een computer op een beamer kan aansluiten en voldoende stoelen om iedereen plaats te geven. Er zijn steeds twee mensen bezig met het probleem verder te brengen en de rest van de aanwezigen mag zich actief bemoeien met de oplossing. Om de paar minuten (5…7) wisselt een van de twee voor iemand uit het publiek en begint een nieuwe ronde. Interactiviteit en plezier verzekerd.

In lijn van de toepassing van de Japanse vechtsport termen wordt bij de coding dōjō de facilitator sensei genoemd, maar het blijft uiteindelijk faciliteren. Mocht je de rol van facilitator op je nemen dan zou ik je de volgende punten willen meegeven die ik ervaren heb:

1. Vraag je ten eerste af of de groep deelnemers die je uitgenodigd hebt überhaubt wel de technieken onder de knie heeft. Is er een groep die eigenlijk nog nooit iets met Test Driven Development gedaan heeft dan zullen zij niet spontaan begrijpen hoe ze het moeten aanpakken en wat de anderen eigenlijk aan het doen zijn. Voor hen is het verloren tijd, met veel discussies over het nut van TDD. Wellicht is het dan een betere optie om eerst een keer uit te leggen hoe TDD werkt.
2. Voor het kiezen van een opdracht zijn diverse voorbeeld kata’s beschikbaar op internet en vaak ook uitwerkingen. Stel jezelf dus de vraag hoe vroeg je van te voren bekend wil maken welk kata je wilt gaan gebruiken. Een aantal deelnemers zullen van te voren gaan kijken naar mogelijke oplossingen van iemand anders. Daarna is het moeilijk om niet het idee van die ander als basis te nemen als je het gezien hebt. Het beperkt dus de creativiteit.
3. Ook zijn er altijd mensen die die voorbereiding niet gedaan hebben, het gevolg kan zijn dat zij minder gaan participiëren. Je geplande randori stijl sessie veranderd daarmee meer naar een demonstratie, kata stijl. Dat hoeft niet fout te zijn, maar neem het mee in je overweging.
4. Zorg voor voldoende kopieën van de opdracht. Iedereen moet de opdracht tot zijn of haar beschikking hebben om zo het op zich in te laten werken, om het proces te laten werken. Een opgehangen opdracht heeft als probleem dat het niet leesbaar is vanuit de zitplaatsen van de deelnemers. Die moeten dan actief naar de opdracht toe lopen. Velen zullen dat niet doen, of uitstellen, en vergeten dan de details. Met als gevolg dat het niet meer te volgen is en ze dus minder mee gaan doen.
5. In tegenstelling tot een retrospective is het verstandig om actief te faciliteren. Het is geen oefening in groepsdynamiek, maar het zal blijken dat als je niet actief stuurt op de groepsdynamiek het meer een probleem gaat worden van hoe een groep mensen actief moet samen werken dan een oefening in de aangeboden kata. Leg desnoods af en toe de sessie stil en vraag de groep om eerst even na te denken. Het kan blokkerend werken voor hen die achter het toetsenbord zitten als de rest van de aanwezigen vol enthousiasme allerlij aanwijzingen zitten te roepen. Stimuleer hun om zelf te bepalen welke eerstvolgende test ze wensen te gaan implementeren. Ook bij een randori geldt dat als je niet weet waar je heen wilt je er ook niet gaat komen.
6. Verder kan ook blijken dat er sterke meningen zijn over stijl en aanpak. Deze sterke meningen kunnen tot verhitte discussies leiden die de aandacht weghalen van de eenvoud van de opdracht en zorgen voor een negatieve sfeer in de groep. Deze negatieve sfeer beïnvloed het vermogen van alle aanwezigen om te leren. Een coding dōjō gaat niet om stijl maar effectiviteit.
7. Dezelfde sterke meningen kunnen er ook voor zorgen dat bij elke ronde een stuk werk van de vorige weer wordt weggehaald. Daar waar de ene het prima vindt om een variable array door te geven veranderd de andere dat weer doodleuk in een lijst. Waar de ene een for-each loop gebruikt verandert de andere dat weer in een gewone for loop. Refactoren is prima, maar men kan er ook in blijven hangen.
8. 5..7 minuten wissel regel kan er voor zorgen dat de twee mensen die de oplossing ontwikkelen steeds in de fase blijven hangen om bij elkaar af te tasten wat zij als oplossing denken te zien. Dit met de druk dat je voor een groep mensen met ‘betere meningen’ zit kan een writer’s block veroorzaken.

Een sessie is geslaagd wanneer binnen de beschikbare tijd de oplossing gemaakt is en de deelnemers het gevoel hebben dit ook zelf te kunnen doen. Het is een succes als in ieder geval een aantal deelnemers het gevoel heeft dat ze iets van een ander geleerd hebben, een nieuwe strategie of techniek die ze zelf graag willen gaan toepassen.

はじめ!