Tagcloud

Knikkebollende samenwerking

Geschreven door: gertjan oude vrielink

Pair programming, je haat het of je bent er dol op. In de Agile community wordt het gezien als een van die middelen die je eigenlijk niet links kunt laten liggen. En wel om de simpele reden dat pair programming zorgt voor software van hoge kwaliteit in relatief korte tijd (Cockburn & Williams 2000). Eén van de grootste uitdagingen met pair programming is hoe degene die niet achter het toetsenboard zit betrokken blijft. Een mens is nu eenmaal snel afgeleid door allerlei interne gedachten die niets te maken hebben met de taak waaraan gewerkt wordt. En laten we eerlijk zin, staren naar opdrogende verf houdt niemand lang vol. Promiscuous Pairing (Belshee 2006) lijkt een antwoord te bieden op focus en betrokkenheid.

Promiscuous pairing

Pair programming is één van de meest opvallende (en controversiële) principes afkomstig uit Extreme Programming  (XP). Hierbij wordt een opdracht door twee ontwikkelaars samen uitgevoerd. Daardoor worden menselijke fouten sneller opgevangen, zo luidt de theorie. In de praktijk zorgt het wel eens voor wrijvingen, zeggen de critici van XP. Maar het zorgt wel voor een snelle doorstroming van informatie, kennis en een borging van kwaliteit.

Bij pair programming heb je meestal één iemand achter het toetsenboard (de ‘tacticus’) en één persoon die observeert (de ‘strateeg’). De tacticus is minder snel afgeleid door het simpele feit dat deze gefocust is op een uitvoerende handeling: het typen. De strateeg is echter minder actief met zijn handen en daardoor meer vatbaar voor allerlei gedachten die hem of haar afleiden. De beloofde productiviteitswinst is daarmee in het geding.

Op de Agile 2005 conferentie, presenteerde Belshee (2005) een model om een koppel betrokken en gefocust te houden. In essentie wisselt in dit model elke 90 minuten steeds één lid van ieder koppel van taak. Dit doen ze op een wijze waardoor niemand langer dan 180 minuten achtereenvolgens bezig is met dezelfde taak.

Hoe ziet dit er in praktijk uit? Stel je hebt zes ontwikkelaars in je team. Het uitgangspunt is dat de taak op een werkplek blijft en dat juist de teamleden zich verplaatsen. In de onderstaande tabel is te zien hoe de teamleden wisselen in drie opvolgende tijdvakken van 90 minuten. De lunch heb ik gemakshalve maar even buiten beschouwing gelaten 😉

Tijdvak 9:00 – 10:30 Tijdvak 10:30 – 12:00 Tijdvak 12:00 – 13:30
Tacticus Strateeg Tacticus Strateeg Tacticus Strateeg
Werkplek 1 Erik Hans Hans Ilse Ilse Rob
Werkplek 2 Ilse Rob Rob Peter Peter Gerrit
Werkplek 3 Peter Gerrit Gerrit Erik Erik Hans

Bekijk de verschuiving van teamleden van het eerste naar het tweede tijdvak. Te zien is dat teamleden per rij een plekje naar links verschuiven. Om het linker plekje vrij te maken verschuift het teamlid door rechts naar boven. Erik tot slot, schuift rechtsonder door. Teamleden roteren feitelijk van werkplek. (Merk op dat afhankelijk van de taakgrootte, de mensen die starten aan de taak op werkplek 1 misschien deze niet meer opnieuw in handen krijgen.)

Maar wie houdt de taak waar aan gewerkt wordt op gang? Het is de verantwoordelijkheid voor degene die op z’n plek blijft zitten, de nieuweling van het duo snel bij te praten. Immers na 90 minuten is hij of zijn zélf met de noorderzon vertrokken. Dat is een hoop om te absorberen in 90 minuten, hoor ik je zeggen. En krijg je zo wel code af? En heb je überhaupt wel voldoende tijd om een nieuw lid in het koppel bij te praten?

Uit onderzoek van Belshee blijkt dat de productiviteit het hoogst is als elk koppel elke 90 minuten switcht. En dat zelfs met de leercurve inbegrepen!
Het geheim zit in iets dat Belshee omschrijft als de ‘beginners mind’.

Beginners mind
Belseeh stelt dat als een persoon zich comfortabel voelt in een omgeving, maar één ding niet begrijpt, dan zal hij of zij meestal van alles proberen totdat dat ene ding opgelost is. Deze staat waarin iemand probeert ervaringen uit het verleden te verzoenen met een omgeving die niet helemaal past, wordt de ‘ beginners mind’ genoemd. Belshee stelt verder dat een persoon die iets voor de eerste keer doet, het vaak veel beter doet dan iemand met meer ervaring. Een beginner probeert immers verschillende mogelijkheden in een rap tempo. Dit vergroot de kans dat iemand met een beginners mind sneller tot een oplossing komt van het probleem in vergelijking met iemand die denkt te weten hoe het werkt. De opgedane ervaring maakt dat de persoon met ervaring het probleem vanuit zijn ervaring aanvliegt in plaats van zo veel mogelijk alternatieven in korte tijd de revue te laten passeren. Belshee toont in zijn onderzoek aan dat als je iemand zo lang mogelijk vasthoudt in de mindset van een beginner dat de productiviteit omhoog gaat.

Eén van de mogelijke strategieën die hij onderzocht heeft om deze mindset zo lang mogelijk vast te houden is het verkorten van de duur van de samenwerking van een koppel. Door elke 90 minuten in elk koppel een persoon te vervangen, is er te allen tijde een beginner en een gevorderde in elk koppel.

Bij pair programming is het gebruikelijk dat er één persoon in het koppel eigenaar is van de taak waaraan gewerkt wordt. In het voorstel van Belshee is er echter niemand eigenaar van de taak waaraan gewerkt wordt. Teamleden blijven net zo lang rouleren totdat de taak af is. Belshee heeft in zijn onderzoek geëxperimenteerd met de duur waarin een koppel samenwerkt. In zijn team bleek 90 minuten het meest optimale productiviteit op te leveren. Het is raadzaam om in je eigen praktijksituatie de optimale duur vast te stellen.

Praktijkuitdagingen
Nieuwe teams die met een onbekend framework werken zullen intuïtief niet zo snel voor de aanpak van Belseeh kiezen. Je zult eerder verwachten dat een aanpak als deze geschikt is voor een doorgewinterd team.

Lacey (2006) concludeert dat het aan te raden is om het koppel het ontwerp, de aannames en de beperkingen op een ‘Post-it sticky’ te laten schrijven bij de start van een taak. Dit heeft als doel dat nieuwe koppels niet in overleg hoeven te treden met teamleden die de taak gestart zijn. Anders gaat er te veel tijd verloren bij het wisselen van koppels en het doorgeven van kennis. Of de nieuwe koppels kunnen de ontwerpbeslissingen accepteren of ze kunnen ze aanpassen. In beide gevallen wordt er primair geen tijd verspeeld aan de overdracht en het verdedigen van specifieke ontwerpbeslissingen.

Hoewel een dergelijke pairing aanpak het best geschikt lijkt te zijn voor ervaren teams, geeft Lacey aan dat deze aanpak in praktijk goed werkt om nieuwe teamleden in te werken in het systeem.

Ik ben benieuwd naar jullie ervaringen.

Referenties:
Cockburn, A., Williams, L. (2000). The Costs and Benefits of Pair Programming. Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2ooo).
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/recursos/XPSardinia.pdf

Belshee, A.(2005). Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience. Proceedings of the Agile Development Conference.
http://dl.acm.org/citation.cfm?id=1122100

Lacey, M. 2006. Adventures in Promiscuous Pairing: Seeking Beginner’s Mind. Proceedings of the Agile Development Conference.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution