De Reset Sprint in Scrum: wat is het?

Leestijd: 4 minuten

“Hello IT.... Have you tried turning it off and on again?” In de digitale wereld een veelgehoorde uitspraak, maar ook in het ‘dagelijks leven’. Iets resetten zorgt ervoor dat je weer fris kunt beginnen. Denk aan je laptop even uit en aan zetten; daarna doet hij het vaak weer. Zelf een weekendje even bijkomen, uitwaaien en bijtanken zodat je de werkweek weer goed kunt starten. Waarom doen we dit dan niet in de digitale productontwikkeling? En in het bijzonder; waarom doen we dit niet binnen de Scrum Methodiek? Ik wil hierbij pleiten voor “een regulier weekendje in een spa-resort”: de Reset Sprint.

Om maar gelijk met de deur in huis te vallen, mijn definitie: "Een Reset Sprint is een terugkerende afgebakende periode, liefst niet langer dan een normale sprint, waarin opgelopen technical en non-technical debt weggewerkt kan worden om zowel teruglopende velocity te reduceren, als team-commitment te verhogen.” Een prachtige volzin met veel jargon. Deze definitie bestaat uit drie gedeeltes, die ik hieronder zal toelichten.

... terugkerende afgebakende periode, liefst niet langer dan een normale sprint...

De terugkerendheid van een Reset Sprint heeft een aantal voordelen. Allereerst verhoogt het de transparantie naar de organisatie. De organisatie weet dat er 1x per zes maanden geen additionele feature request gebouwd worden, maar dat er ‘gereset’ wordt. Door dit structureel in te plannen, kan iedereen hier rekening mee houden en komt het voor niemand als verrassing.

Aan de andere kant kan het team zich verheugen om de dingen waar ze al een tijdje tegen aan lopen, beter te maken. Doordat sprints afgebakend zijn, mvp’s opgeleverd worden en er weleens onder tijdsdruk keuzes gemaakt worden die wel werken, maar niet optimaal zijn, wil je als development team deze dingen een keer écht goed doen. Het team ziet dagelijks dingen die in hun ogen beter kunnen, maar waar vaak geen tijd voor is. Al is het legacy code, uitlijning die niet klopt, of slecht geschreven copy. Het team kan zich dan uitleven om jouw product van 80% naar 100% te brengen.

Een reset sprint zou in mijn ogen niet langer, of korter dan een reguliere sprint moeten duren. Hierdoor blijft iedereen in dezelfde sprint cadans van 2-4 weken. En langer dan een normale sprint kost veel tijd, en dus geld, om te kunnen verantwoorden. In mijn ervaring is (bij een organisatie waar weinig structurele technical debt is) deze periode goed te verantwoorden en lang genoeg om weer te ‘resetten’.

... waarin opgelopen technical en non-technical debt weggewerkt kan worden...

Agile ontwikkelmethodes als Scrum steunen op drie pilaren: transparancy, inspect & adapt. Het doel hiervan is om zo snel mogelijk, zoveel mogelijk waarde toe te voegen voor de klant. Echter, één van de nadelige kanten van Scrum in mijn ogen, is het razende tempo waarin Sprints elkaar opvolgen. Volgens de Scrum Guide 2016* begint de volgende sprint, direct na de retrospective van de vorige. (A new Sprint starts immediately after the conclusion of the previous Sprint - Scrum Guide 2016). Dit geeft weinig tijd om te reflecteren op technische implicaties van hetgeen gebouwd is, en daarop te acteren. Inspect & Adapt zogezegd. Hierdoor loopt een team snel ’technical debt’** op.

Ongeacht hoe goed je de code ook integreert met de legacy code, ergens ga je tegen complicaties oplopen. Dit houdt in dat je telkens meer tijd moet spenderen aan het goed integreren en testen van de code. Deze tijd gaat af van de kwalitatieve ontwikkeling van je product. En dat is waar je het voor doet. Mooie waardevolle producten maken voor jouw klanten.

Binnen Scrum wordt de term Minimal Viable Product (mvp) nog weleens verward met; ‘het minimale doen’. Het allemaal zo klein en minimaal maken dat het net werkt. Om maar zo snel mogelijk, zo veel mogelijk te doen. Dat is níét de gedachte achter het mvp. De klant, jouw doelgroep, jouw medewerkers moeten ook met jouw product willen werken. Niet alleen kunnen werken. Wat dat betreft is er wel wat te zeggen voor een Minimal Loveable Product, maar dat is een heel ander blog. Het houdt echter vaak wel in dat je in het kader van snelheid van de sprints een 80% variant oplevert, die goed werkt, die mensen ook willen gebruiken maar wat net even wat extra liefde nodig heeft om echt top te zijn. Deze laatste 20% (non-technical debt) is net de 20% waarom een klant van jouw product echt gaat houden. En waar designers en jouw team ook blij van worden. Deze 20% toevoegen is het ‘wegwerken van non-technical debt’. Die zaken waar het team al een tijdje tegenaan hikt, omdat ze het nou eenmaal goed willen doen. Net dat extra stapje. Die extra aandacht. Dit is wat het verschil kan maken tussen een goeie en een top experience.

 

Technical Debt

... om zowel teruglopende velocity te reduceren, als team-commitment te verhogen.

De snelheid waarmee je kunt ontwikkelen wordt binnen Scrum uitgedrukt in Velocity. Het aantal storypoints wat je per sprint kunt verbranden. Zoals hierboven beschreven kan het ‘resetten’ van het proces jouw teruglopende velocity weer back on track krijgen. De ‘spaghetti code’ is weer ontrafeld, en we kunnen weer full speed ahead. De 80% zaken zijn weer meer ‘loveable’ gemaakt, en dat stukje product is weer van goed naar top gegaan. Al deze zaken leveren, in mijn ervaring althans, op dat het team weer met frisse moed aan de slag gaat. Alsof ze een weekendje weg zijn gegaan. Even de laptop uit en weer aan gezet hebben.

Mijn pleidooi is dus om regelmatig een weekendje weg te gaan met jouw team. Om even de batterij op te laden. “To turn it off and on again”.

 

 

Resources:

* Scrum Guide - Scrum.org
** Technical Debt - Technopedia

img: http://blog.agilistic.nl/how-to-deal-with-technical-debt-in-scrum/
img: https://www.pexels.com/photo/woman-girl-beauty-mask-3192/