Waarom zijn korte sprints beter?

De sprint: een afgebakende korte tijdsperiode waarin teams aan de hand van vaste rituelen werk plannen en uitvoeren. Het hart van Scrum werken zoals de Scrum Guide het omschrijft. Als scrum master sluit ik me daar helemaal bij aan. De sprint is namelijk één van de krachtigste tools om bottlenecks te ontdekken. Let wel; ontdekken, niet oplossen. Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op. De sprint verlengen is sowieso geen goed idee vanwege de volgende redenen: – Feedback komt later – Sprints verlengen betekent automatisch dat de feedback pas op een later moment komt, terwijl je juist feedback zo snel mogelijk wilt ontvangen om het mee te kunnen nemen in je volgende sprint. – Minder Agile – Kortere sprints betekent meer mogelijkheid om in te spelen op verandering. Hoe langer de sprint, hoe groter de kans dat de sprint open gebroken moet worden om nieuwe items met spoed op te pakken. – Minder verbeteringen – Als sprints langer zijn voelen teamleden al snel dat er meer tijd is om werk uit te voeren en ontstaat er minder drang om te verbeteren. – Prioriteren wordt moeilijker – Als sprints langer worden willen stakeholders al snel dat hun items in de eerst volgende sprint opgepakt worden, omdat ze anders voor hun gevoel te lang moeten wachten.

Langere sprints ≠ Minder overhead

Te vaak hoor ik als scrum master het argument voorbij komen dat langere sprints in verhouding minder “overhead” hebben dan kortere sprints. Maar dat is niet zo. De lengte van alle rituelen schalen namelijk mee volgens de scrum guide [1].

Timeboxes volgens de Scrum Guide

Zo gaat de timebox voor de sprintplanning bijvoorbeeld van 4u naar 6u als je de sprint van twee naar drie weken verlengt. Dat klopt ook want je moet immers een extra week werk inplannen. Daarbij speelt ook nog eens dat hoe verder in de toekomst, hoe lastiger het inschatten is of je iets wel of niet op kunt pakken en af kunt maken. Je weet immers beter wat je morgen gaat doen dan wat je over drie weken gaat doen. De onzekerheid neemt toe naarmate de sprint langer wordt. De sprintplanning zal dus in verhouding eerder langer dan korter worden. Vooral voor teams die niet dagelijks bij elkaar zitten is er nog een groot nadeel bij het verlengen van de sprint. Bij een tweewekelijkse sprint passen de review, de retrospective en de planning exact op één werkdag. Je kan dus zo een echte “sprintwisseldag” creëren waarbij iedereen op locatie aanwezig is. Verleng je de sprint naar drie of meer weken dan passen deze drie rituelen niet meer op één werkdag en zullen ze over twee of meer werkdagen verspreid moeten worden. Het is dan ook niet zonder reden dat het Agile Manifesto korte sprints als één van de belangrijkste principes noemt: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale [2]”.

De sprint verlengen? Voer dan eerst deze checklist uit

Speelt het team tegen beter weten in met het idee om de sprint te verlengen? Vul dan eerst onderstaande checklist in om te ontdekken of er een ander probleem speelt binnen het team: ☐ Het team is bezig met het uitvoeren van “mini-watervallen” (Eerst design, dan ontwikkelen en als laatste testen). Zie ook mijn eerdere artikel. ☐ Het team heeft moeite met het splitsen van user stories. ☐ Teammeetings zijn niet efficiënt. ☐ Het team heeft moeite met deployments (incl. merge & integration). ☐ Het team heeft niet genoeg ervaring met test driven development of andere quality practices. ☐ Technical debt is zo groot gegroeid dat werk langer duurt. ☐ Team werkt aan te veel items buitenom de sprint. ☐ Skills en vaardigheden zijn niet goed verdeeld binnen het team waardoor het team afhankelijk is van één of enkele specialisten binnen het team. ☐ Team werkt en worstelt met oude technologie. ☐ Uitzoekpunten en antwoorden laten te lang op zich wachten. ☐ Het team worstelt met afhankelijkheden buiten het team. ☐ De communicatie met teamleden die niet op locatie werken verloopt moeizaam. ☐ Problemen met prioriteren of gebrek aan een actieve Product Owner. ☐ Moeite met het concept van een MVP’s. ☐ De product owner of stakeholders bemoeien zich met de sprint backlog tijdens de sprint. ☐ Het team is bang om “niet genoeg” op te leveren aan het eind van de sprint aan de stakeholders. ☐ Het team vreest te moeten overwerken om aan de commitment te voldoen. [1] Bron: https://agilescrumgroup.nl/duur-scrum-meetings/ [2] Bron: https://agilemanifesto.org/iso/nl/principles.html Door William van der Maas, consultant bij Towson