Waar we ons als Agile community lekker konden afzetten tegen al die vastgeroeste waterval collega’s, doen we nu vaak weer vrolijk mee. Zonder nadenken kopiëren we het gedrag van anderen, gewoon omdat iedereen het doet. Of zoals mijn leidinggevende ooit tegen me zei toen ik vroeg waarom we nog een prikklok hadden: “Zo doen we dat hier nu eenmaal, jongeman.”
De anekdote van apen en bananen
Een van de anekdotes die lange tijd populair was in de Agile community, is het verhaal over een groep apen in een hok met ergens bovenin een lekkere banaan. Zodra een aap deze wil gaan pakken, gaat de brandslang erop. Ook de anderen krijgen een portie koud water over zich heen. Apen houden niet van koud water en dus haalt niemand het daarna nog in zijn hoofd om die banaan te gaan pakken. In het vervolg van het experiment worden één voor één de apen geruild voor een ander exemplaar. Na iedere ruil doet de nieuweling weer een poging om de banaan te pakken, maar wordt hij fanatiek tegengehouden door de anderen. De groep corrigeert zichzelf steeds weer zonder dat er nog een waterstraal aan te pas komt. Uiteindelijk zit er geen enkele aap meer in het hok, die zelf ooit is nat gespoten. Toch blijft de banaan hangen. Niemand weet waarom. Het is nu eenmaal zo.
In 1996 werd voor het eerst geschreven over dit experiment door Hamel en Prahalad in hun boek Competing for the Future. Zij halen hierin overigens de resultaten van dit experiment aan zonder daarbij een bron te vermelden. Het experiment schijnt nooit uitgevoerd te zijn en blijkt dus een broodje-aap-verhaal te zijn. Toch wordt het veel gebruikt als we het over cultuur hebben. En laten we eerlijk zijn. Het is natuurlijk een prachtig verhaal waar we onszelf lekker mee kunnen spiegelen.
Een voorbeeld uit de praktijk
Wat dacht je van synchrone sprints ofwel dat alle scrum teams dezelfde cadans moeten hebben? Als je het waagt om te zeggen dat je er met je team niet aan meedoet dan is een verbaasde blik nog het minst erge dat je kunt verwachten. Waarschijnlijk wordt je door een agile coach, manager of release train engineer tot de orde geroepen en wordt er van je verwacht dat je netjes mee hobbelt in de corporate policy.
Waarom dan?
Als je naar het waarom vraagt dan komen de meesten niet verder dan dat je dan beter afhankelijkheden tussen teams kunt managen. Ik vraag me dan af waarom er zoveel afhankelijkheden zijn tussen teams. En gaat dat echt wel beter als we allemaal op dinsdag beginnen? Als ik iets halverwege jouw sprint oplever en je kunt er nog mee aan de slag dan kan dat toch ook best handig zijn?
Een ander veel gebruikt argument is dat je met de vaste cadans complexiteit verminderd. Inderdaad, het spoorboekje met begin en einddatums van alle teams ziet er een stuk eenvoudiger uit. Maar op andere vlakken vergroot je de complexiteit juist en introduceer je allerlei vormen van verspilling. Niet echt lean dus. Ik zal er een paar noemen.
1. Overlapping van benodigde middelen
Als alle teams in dezelfde cadans aan hun sprints werken, kan er op bepaalde momenten een tekort aan benodigde middelen ontstaan, denk bijvoorbeeld aan vergaderruimtes. Er ontstaat piekbelasting op sprintwisseldagen met wachtrijen tot gevolg. Dit kan leiden tot conflicten en het vertragen van het werk. Door de start- en einddatums van de sprints van elkaar te laten verschillen, kunnen deze middelen beter worden verdeeld en kan het werk efficiënter en sneller worden uitgevoerd.
2. Afhankelijkheden en integratie
Als de teams afhankelijk zijn van elkaars werk, kun je door de sprints te spreiden, de teams de tijd en ruimte geven om hun werk te voltooien en eventuele integratieproblemen oplossen voordat andere teams met jouw stuk verder gaan. Dit vermindert de kans op vertragingen en fouten. Je hoeft in scrum niet te wachten met opleveren tot het eind van de sprint, maar de sprint review meeting zit toch echt wel aan het eind.
3. Flexibiliteit en aanpassingsvermogen
Scrum is gebaseerd op het Agile-principe van het omarmen van verandering. Als de teams niet gebonden zijn aan vaste start- en einddatums, kunnen ze flexibeler reageren op veranderingen. Wat doe je bijvoorbeeld als een product owner een sprint heeft afgebroken omdat het sprintdoel niet meer opportuun is? Ga je wachten met de volgende sprint totdat je weer in het juiste ritme zit? Dat is pure verspilling.
4. Continu leren
Scrum is gebaseerd op empirisme. Teamleden kunnen door sprint review sessies van andere teams te bezoeken een hoop leren en waardevolle feedback geven. Die mogelijkheid wil je elkaar toch niet onthouden terwijl je wel met z’n allen aan hetzelfde product werkt met ook nog eens veel afhankelijkheden? Het is niet erg bevordelijk voor de pijlers inspect en adapt.
5. Planning
Het kan zelfs eenvoudiger zijn om de planning en coördinatie van meerdere teams te beheren als ze niet allemaal op hetzelfde moment hun sprints starten en eindigen. Het helpt bij het voorkomen van overbelasting van de scrum master of product owner, omdat ze beter in staat zijn om hun aandacht te verdelen en de voortgang van elk team te volgen. Als er bijvoorbeeld meerdere teams aan hetzelfde product werken, delen ze één product owner. Die kan zich niet opsplitsen over de scrum events van de verschillende teams heen en zal dus (verplichte!) meetings in scrum moeten laten schieten. Een oplossing hiervoor is meerdere product owners aanstellen, maar dan voldoe je toch echt niet meer aan de scrum guide.
Wel of geen cadans
Al met al kan het gelijktijdig starten en eindigen van sprints voor samenwerkende scrum teams leiden tot inefficiëntie, conflicten en problemen. Door de sprints verspreid te laten plaatsvinden, kunnen teams beter samenwerken en het beste uit hun gezamenlijke inspanningen halen.
Laat je dus niet verleiden om alle teams in dezelfde cadans te laten werken omdat het nu eenmaal zo moet. Scrum teams zijn zelf-organiserend en moeten dus ook de vrijheid krijgen om hun eigen cadans te vinden. En als ze er dan achter komen dat het toch beter is om synchroon te werken dan is dat prima. Niet omdat iemand vind dat het nu eenmaal zo moet, maar omdat erover is nagedacht.