Waarom Scrum niet per se Agile is.

Als freelance software developer zie ik veel bedrijven die Scrum gebruiken en die agile zijn of denken te zijn. Maar Scrum is niet hetzelfde als “agile”. Je bent niet automatisch agile als je een Scrum stickertje op de voordeur plakt.

“Agile” betekent “wendbaar”. Een botsautootje is wendbaar: het kan ineens om z’n as draaien en de andere kant op gaan. Een veerpont is niet wendbaar: die kan alleen recht naar de overkant varen en weer terug. Toen ik studeerde en dagelijks op de pont over het IJ stond, zag ik daar soms grote schepen voorbij komen die door twee of drie sleepboten door het IJ werden geloodst. Mannetjes met portofoons aan dek om alles te coördineren. Als het sleepboten van Goedkoop waren, dan waren er geen portofoons: ik denk dat de stuurlui op die boten zo goed op elkaar waren ingespeeld dat ze het ook zonder overleg konden. Een zwerm spreeuwen is ook wendbaar. Soms zie je ze uit een boom opvliegen, ze vliegen een kant op, en als door magie vliegen ze ineens allemaal een andere kant op, alsof  ze elkaar aan een touwtje hebben. Optimaal agile.

Wat nodig is om agile te zijn is perfecte coördinatie. Die coördinatie kun je op verschillende manieren bewerkstelligen. Je kunt communiceren, praten, schreeuwen. Als je bij de zesde klasse zaterdagamateur voetballers gaat kijken, dan hoor je dat die maar blijven roepen naar elkaar om te zorgen dat ze als team een beetje samenwerken. Agile door permanente communicatie. Ga je bij het eerste van Ajax kijken, dan hoor je ze niet schreeuwen. Die spelers zijn goed ingespeeld en kunnen het spel zo goed lezen dat ze van te voren al weten wat de anderen gaan doen. Zoals ijshockeyer Wayne Gretzky opmerkte in Harvard Business Review: “I skate to where the puck is going to be”. Hij leest het spel, en weet dan waar de puck over een paar seconden zal zijn, en schaatst daar vast naar toe. Dat kan ‘ie alleen doen als ‘ie zeker weet dat de rest van zijn team het spel ook zo goed leest, en dat de puck inderdaad komt. En alleen als, in het geval dat de puck toch de andere kant op gaat, Gretzky in één beweging zwenkt en klaar staat voor de rebound als zijn teamgenoot op doel schiet. Allemaal zonder een woord te wisselen, helemaal vanzelf, als een zwerm spreeuwen.

Je kunt natuurlijk ook Scrum toepassen op het sportveld. Bij de start van je rugby wedstrijd hou je een “Start of Sprint” meeting, en je plant wie de bal gaat trappen, wie hem gaat vangen, wie waar naar toe loopt en wie dan gaat scoren. Je moet snel scoren, want tijdens jouw meeting heeft de tegenpartij al twee keer gescoord. In de breakdown meeting ga je vaststellen of de bal hoog of laag getrapt moet worden, en over links of over rechts. De tegenpartij scoort ondertussen weer. Dat is een grapje, maar ook weer niet helemaal. Ik werkte ooit een poosje bij een organisatie waar Scrum zeer serieus werd genomen. Iedereen was naar een training geweest, er was een hele tijd een Scrum coach geweest, het management had een heidag over agile gehad en overal hingen agile spreuken. Het boekje werd nauwgezet gevolgd. Iedere ochtend een kwartier “standup meeting”, inclusief “mood check”. Aan het begin van de sprint een “Start of Sprint” meeting waarin gezamenlijk werd vastgesteld wat de features in de volgende release van de software moesten zijn, en de dag erna een “breakdown meeting” om de user stories op te breken in sub-tasks. Een week later een “refinement meeting”, en aan het eind van de sprint een demo gevolgd door een “End of Sprint” meeting. In één van die meetings werd ook nog met “scrum poker” ingeschat hoe complex de features waren. Ik herinner me een breakdown meeting. We waren met acht mensen, er waren vijf features die de komende drie weken gemaakt moesten worden. Vijf user stories dus. Per user story werd langdurig besproken wat de story inhield. Vervolgens werd in een verhitte discussie vastgesteld welke sub-taken nodig waren. Twee features werden opgedeeld in wel twaalf subtaken omdat er heel veel gerefactord moest worden. Het ging om wijzigingen in bestaande software, ik kende die software niet, ik was net nieuw in het project, dus ik volgde geïnteresseerd hoe er gesubtaakt werd. De meeting duurde drieënhalf uur. 28 mens-uur. Ik was na afloop uitgeput en half in slaap.

De volgende ochtend ging ik aan de slag met de eerste van twaalf subtaken, en toen ik de code ‘ns goed bekeken had, vond ik ze helemaal niet zo slecht. Sterker nog, de code was precies zoals ik het zelf ook gemaakt zou hebben als ik het van scratch zou moeten bouwen. Dus in overleg met een teamgenoot trok ik me niks aan van de subtaken en maakte in een middagje de benodigde code. Al pair programmend kwamen we samen via unit tests en een klein beetje extra code en wat refactoring tot een mooie oplossing. Toen echter een ander teamlid de code ging reviewen, kreeg ik de wind van voren.

“Je hebt het niet gemaakt zoals we het in subtaken hadden opgedeeld!”

“Nee, we hebben het in een fractie van de tijd gemaakt omdat we vonden dat de bestaande code eigenlijk al wel heel goed was”.

“Maar je hebt het niet gedaan zoals we hadden afgesproken!”

“Nee want toen wist ik nog niet dat de bestaande code best wel ok was”.

“Maar we volgen Scrum hier en dan moet je de code maken zoals het in de subtaken is gepland!”

“Het is goed met je”.

In één van de beste teams waarin ik heb gewerkt hadden we nooit meetings. We hadden een feature list, en iedereen die ergens klaar mee was pakte een nieuwe feature op en werkte verder. Soms zaten er twee of drie programmeurs achter één scherm, voor stukjes code waarvan veel andere code afhankelijk was, of code die heel interessant was. Meestal hoefden we alleen maar te weten waar een ander mee bezig was om erop te vertrouwen dat die ander het ongeveer zo zou maken als dat je het zelf ook zou doen. Daarvoor moet je elkaar goed kennen, en moet je dezelfde standaarden en best practices hanteren. Maar bovenal, je moet elkaar vertrouwen. Je moet er een blind vertrouwen in hebben dat de ander daarnaartoe programmeert waar de puck zal zijn.

Veel organisaties vinden hun teams al super wendbaar als ze in staat zijn iedere drie weken na afloop van een sprint een nieuwe build van de software te produceren en in gebruik te nemen. Voor veel organisaties is dat genoeg. Sommige willen meer.

Om echt agile te zijn, zijn twee dingen nodig: je moet direct contact hebben met de klant c.q. gebruiker c.q. product manager, en je moet in staat zijn iedere nieuwe feature in je software onmiddellijk te deployen en in gebruik te nemen. Het eerste bereik je door de klant/gebruiker/product manager in je team op te nemen. Die moet meepraten en meekijken en meetesten. Anders weet je niet wat je moet maken. Het tweede bereik je met een continuous build omgeving waarin iedere feature die gemerged wordt naar de develop branch automatisch via de diverse testomgevingen naar deployment gaat.

De meeste organisaties die serieus software maken hebben hun (quasi-) continous build omgeving goed voor elkaar. Op het teamwork is echter altijd wel wat aan te merken. Vaak zit de gebruiker van de software niet aan tafel. Meestal worden Scrum trainingen gevolgd en boeken gekocht en wordt het team met zoveel bureaucratie belast dat Scrum eerder het doel dan het middel lijkt te zijn. En dat is heel jammer.

Ik pleit ervoor dat je in software ontwikkelteams alleen kijkt naar de dynamiek in het team en de aanwezige kennis. Als je de juiste mensen bij elkaar zet, ze stimuleert om iets moois te maken en ze helpt met wat ze nodig hebben, dan krijg je altijd een goed product.

Leave a Reply

Your email address will not be published. Required fields are marked *