Agile Stonehenge

OLYMPUS DIGITAL CAMERA
Photo by garethwiscombe

Voormalig Astronomer Royal Sir Fred Hoyle heeft ooit een boekje geschreven over Stonehenge. Hij vroeg zich af waar de grote stenen van Stonehenge ooit voor gediend hebben. We weten dat de kleinere stenen die wat verder verwijderd staan van de grote stenen in het midden, een zonnewijzer waren waarmee de druïden konden voorspellen wanneer de dagen weer gingen lengen en het voorjaar dus weer in aantocht was. Zijn verklaring voor de grote stenen in de kring is de volgende.

De oude druïden hadden ontdekt dat op de korste dag, de zon altijd op hetzelfde punt aan de horizon onderging. Door dat punt te markeren, en in de winter de ondergang van de zon in de gaten te houden, konden ze de kortste dag precies voorspellen. Dat was belangrijk voor de priesters, want dan konden ze het volk melden “ook dit jaar zal de winter weer plaats maken voor het voorjaar!”. Ze markeerden het punt aan de horizon met twee enorme stenen, als een soort wijzer. Die stenen moesten groot zijn opdat de koeien of de najaarsstormen ze niet verschoven. Die priesters werden in de loop der eeuwen best wel handig in het voorspellen van de midwinter zonnewende. In de theorie van Hoyle gingen ze de zonnewende naspelen met kleine steentjes, en door de dagen te tellen konden ze na verloop van tijd de winter-zonnewende voorspellen zonder naar de grote stenen te kijken.

Eeuwen gingen voorbij, misschien wel een millennium. Toen ging er iets mis met het model van de priesters, de aard-as wentelt immers een beetje, de berekeningen klopten niet meer, en het volk raakte in panier omdat de priesters niet meer goed in staat waren te voorspellen dat er ook dit jaar na de winter weer een voorjaar zou volgen. De kennis van de grote stenen bij het punt aan de horizon was in die eeuwen natuurlijk verloren gegaan. Wat nu? Er was wel de overlevering, van de oude priesters die de goden gunstig stemden om het voorjaar te laten terugkeren. Iemand opperde “het was iets met hele grote stenen”. En dus werden grote stenen gehaald uit Wales, veel groter dan de oorspronkelijke stenen want als je te weinig kennis heb compenseer je dat door de stenen groter te maken. Natuurlijk hebben die nieuwe stenen niet geholpen om de goden gunstig te stemmen, of misschien ook wel, het voorjaar kwam immers ieder jaar gewoon weer terug.

Of Hoyle gelijk heeft, ik weet het niet, de archeologen die meer verstand hebben van de oude tijden hebben heel andere ideeën over Stonehenge dan de Astronomer Royal, maar het is een mooi verhaal.

Ik denk wel eens aan Fred Hoyle als ik in den Scrum meeting zit, of in een “daily standup”. Iemand wilde de performance van software ontwikkelteams verbeteren, herinnerde zich de briljante high performance teams waarin hij of zij ooit had gewerkt, herinnerde zich de koffie die ze in de ochtend samen dronken, staande bij de koffiemachine, en dacht toen “het was iets met ‘s ochtends in een kringetje staan”. Daarbij over het hoofd ziende dat dat kringetje ‘s ochtends een gevolg was van de werkwijze van het team, een symptoom, en niet een oorzaak. Een high performance software team doet het zo goed omdat de leden elkaar perfect aanvoelen, steeds overleggen, steeds samen aan code werken, ook als het uitkomt dagenlang alleen aan code werken, omdat ze elkaar vertrouwen en tegelijk elkaar op de vingers kijken. Ze reviewen elkaars code, ze doen suggesties, ze leren van elkaar, ze delegeren aan elkaar, en aan het eind van de dag hebben ze een berg software gemaakt van hoge kwaliteit waar ze zichzelf allemaal in herkennen. ‘s Morgens in een kringetje bij elkaar staan gaat vanzelf, omdat er goede koffie is, omdat je elkaar al zeker 12 uur niet hebt gezien, omdat je wilt vertellen wat je gisteravond hebt gedaan, en o ja, omdat je een collega wilt vragen vandaag even met je mee te kijken naar een nieuw stukje software dat je gaat maken. Of omdat je wilt aankondigen dat je vandaag wilt laten zien wat je de afgelopen twee weken hebt gemaakt.

Een “sprint” is ook zoiets. Als je een lijst met features hebt die gemaakt moeten worden (een “backlog”) dan ligt het voor de hand om steeds als je iets af hebt, een nieuw item van de lijst te nemen en daarmee aan de slag te gaan. Het ligt ook zeer voor de hand om periodiek een oplevering van je product te doen. Vroeger deden we dat door periodiek te zeggen “wat nu af is, zit in de komende release”. Wat er dan in de release zat op 18 februari, nou, dat was wat er op 18 februari toevallig af was. Hetzelfde voor 23 juli. En natuurlijk zei je dan “oh, wacht, ik maak dat nog even af, dan kan het nog net mee met de komende release”. En dan werkte je wat avonden door. En of je nou om de drie maanden of om de twee weken een nieuwe release had, altijd zat er in de release wat er op dat moment toevallig af was.

De eerste release duurt natuurlijk langer. Als je een systeem bouwt en je gaat daar een jaar over doen, dan kun je natuurlijk niet na twee weken een eerste werkende versie hebben, net zo min als dat je een huis bouwt en twee weken na het begin van de bouw kun je al in een stukje ervan wonen, of je bouwt een auto en na montage van het eerste wiel kun je al een proefritje maken. Maar iemand zegt dan “het was iets met periodieke releases” en dan richt je je project in met releases om de twee weken en je eist dat na iedere sprint er een werkend product is. Waardoor alle inspanning in de eerste twee weken erop gericht is om in twee weken “iets werkends” op te leveren en niet, zoals zou moeten, erop gericht is om aan het eind van het gehele project het beste product op te leveren.

Ik heb in de loop der jaren in heel wat Scrum teams meegedaan, en ik heb het idee dat Scrum van het middel het doel is geworden. Dat bij managers het idee heeft postgevat dat als we nou maar iedere ochtend even in een kringetje staan en om de week met genummerde kaartjes over tafel gooien en genoeg gele briefjes op een whiteboard hangen of genoeg subtasks in Jira heen en weer schuiven, dat we dan een high performance team zijn en dat we dan efficiënt en effectief werken.

Ik zou zeggen, laten we ons nou ‘s wat minder laten leiden door de boekjes en de theorie en wat meer kijken naar het resultaat van wat we doen.