Scrum light: een vereenvoudigde manier van agile scrum

Hoewel scrum al in 2001 het levenslicht zag, lijkt het de laatste jaren de heilige graal te zijn geworden bij veel internetbureaus. Je hoort er eigenlijk niet meer bij wanneer je nog nooit van een MVP, user stories, product owner of scrum master hebt gehoord. Dat scrum zo populair is is best begrijpelijk. Het biedt namelijk handvatten voor een gestructureerd proces, geeft een heldere taakverdeling (wie wil er nou geen scrum master genoemd worden), een sterk teamgevoel (en daarmee een nauwe betrokkenheid van de teamleden) en de mogelijkheid voor een opdrachtgever om zelf te sturen in budget en functionaliteit.

Door

Milan

Maar is scrum wel geschikt voor elk type project? En voor elke omvang? Bij grote maatwerk projecten is er zeker wat voor te zeggen, maar hoe zit het met een minder complexe website? Kortom: moet je wel altijd de volledige scrum werkwijze willen toepassen op elk project? Voor ons is het antwoord op die vraag nee. Onze vereenvoudigde agile werkwijze noemen we daarom ‘Scrum Light’.

Even een stoomcursus scrum jargon…

Hoe wij Scrum Light aanpakken

Don’t obey your Scrum Master

We werken niet met scrum masters, of product owners. Maar streven er wel altijd naar om echte product-experts te worden, zodat we het product begrijpen en klanten een geweldige gebruikservaring voorgeschoteld krijgen. We bewaken samen met de klant het backlog, maar voelen ons ook verantwoordelijk voor het product. Er wordt altijd intern (bij Pixelpillow) iemand aangewezen die verantwoordelijk is voor de begeleiding van het proces. Dit is altijd de persoon die inhoudelijk de grootste betrokkenheid heeft bij het project.

De begeleiding van een project doen we dus samen, waardoor de rol van een scrum master deels overbodig wordt. En da’s mooi! Want die tijd kunnen we inzetten om uw website of applicatie nog beter te maken!

Keertje sparren? Plan een afspraak in

1. Wel de stories, niet de lasten

Voor elke project – groot of klein –  maken we samen met de product owner een backlog met user stories. We gebruiken het backlog als een middel om eisen en wensen boven water te krijgen. Vaak doen we dit in één of twee sessies van maximaal 4 uur. Voor aanvang van zo’n sessie doen wij ons huiswerk en vragen we de klant dit ook te doen. Zo kunnen we in een relatief korte tijd een compleet backlog opstellen.

2. Planning poker

Zodra we de user stories bepaald hebben gaan we met de product owner om tafel met een set planning poker kaarten. Elke user story passeert de revue en wordt gewogen door een aantal punten toe te kennen. Wanneer deze punten per teamlid ver uit elkaar liggen is waarschijnlijk de user story te complex of niet goed gedefinieerd. In dit geval wordt de user story opgesplitst of moet deze beter omschreven worden. Nadat aan alle stories een aantal punten is toegekend is het tijd om opnieuw het backlog te bekijken en te ‘groomen’ (zie begrippenlijst hierboven). User stories die bij nader inzien toch minder prioriteit hebben, omdat ze bijvoorbeeld een te hoge inspanning vergen, kunnen lager op het backlog geplaatst worden. Het grote voordeel van planning poker – naast het feit dat je geen geld kunt verliezen – is dat het hele team dezelfde verwachtingen heeft bij de inspanning die nodig is om het product te realiseren.

3. MVP, Minimum Viable Product

In een sessie met de product owner wordt bepaald hoe het Minimum Viable Product (lees: het product in z’n meest basale, minimale vorm) live zou kunnen gaan. Vaak doen we dit aansluitend aan de planning poker sessie. User stories die niet binnen het MVP vallen worden tijdelijk ‘in de koelkast’ geplaatst om tijdens de doorontwikkeling op te pakken. Een simpele rekensom (combinatie van beschikbare capaciteit en de totaal ingeschatte uren ten behoeve van het MVP) leidt tot het aantal benodigde sprints om het MVP te realiseren.

4. Ready, set, sprint!

Het echte werk gaat beginnen! Vaak werken we in sprints van 2 weken, maar dit is afhankelijk van de omvang van een project. Over het algemeen geldt dat 2 weken een prima time-box is. Voor de eerste sprint nemen we vaak wel even wat meer tijd (3 – 4 weken) omdat we dan de basis van de te realiseren software moeten opzetten. En dat kost vaak nou eenmaal wat meer tijd. Want: een goed begin is het halve werk! Na elke sprint organiseren we een sprint demo. Tijdens deze demo wordt een werkende website gedemonstreerd en wordt bepaald welke backlog items in de volgende sprint gerealiseerd worden.

5. Sorry, geen daily stand-ups

Stand-ups zijn cool, stand-ups zijn hip, stand-ups kunnen erg nuttig zijn. Maar ze zijn met name nuttig als je met een groter team dedicated aan een project werkt. Aangezien er gemiddeld twee a drie mensen van Pixelpillow gelijktijdig aan een project werken is het daarom voor ons niet nuttig om dagelijks een stand-up te organiseren. Uit onderzoek blijkt bovendien dat je na elke onderbreking 20 minuten nodig hebt om weer in je ‘flow’ te komen? Elke dag 15 minuten stand-up + 20 minuten om weer je ‘flow’ te vinden = 35 minuten ‘verloren’ tijd. We werken daarom bewust niet met daily stand-ups, maar organiseren liever een weekly stand-up, waarbij niet altijd ieder teamlid aanwezig is. Binnen Pixelpillow houden we twee keer in de week een stand-up met hele team. Omdat we – vanzelfsprekend – niet allemaal aan dezelfde projecten werken is dit een goede manier om elkaar op de hoogte te houden.

Waarin verschilt Scrum Light dan van Scrum?

Wij starten niet met als uitgangspunt dat alle onderdelen van scrum voor ons nuttig zijn. Dat dwingt ons om alleen de onderdelen te gebruiken die wel waarde toevoegen in ons proces. De belangrijkste ingrediënten uit scrum die wij bewust niet gebruiken zijn de daily stand-ups en de rol van scrum master.

Dat klinkt als een minimaal verschil, maar onze ervaring is dat we tussen de 15 en 20 procent kunnen besparen op projectmanagement en communicatie, door selectief te zijn in de rollen die we inzetten tijdens een project en door niet dagelijks stand-ups te organiseren. Uiteraard is er altijd begeleiding en communicatie nodig, maar het uitgangspunt is om dit incidenteel te maken in plaats van structureel. Zo kunnen we het budget focussen op het ‘maken’ van het product, in plaats van ons blind te staren op het managen van het proces.

Tot slot

Voor de duidelijkheid: dit is geen pleidooi tegen scrum of projectleiders, maar wel een poging je na te laten denken over hoe je projecten nu aanpakt. Scrum in z’n volledige vorm is wat ons betreft niet altijd de heilige graal. Het risico van scrum in volledige vorm toepassen is dat in verhouding veel tijd opgaat aan het proces, in plaats van aan het daadwerkelijk maken van je product. Overweeg dus per project of je scrum wilt inzetten. En wil je dit wel, maar niet full swing? Overweeg dan scrum light toe te passen.

Vragen? Of wil je ons betrekken bij een project? Neem dan eens contact op voor een persoonlijke toelichting.

Meer weten...
No items found.
Ook interessant
Vraag?
Neem contact op
* verplichte velden
👍
Bedankt voor je bericht. We nemen zo snel mogelijk contact met je op.
😱
Oeps. Het lijkt erop dat bovenstaande velden niet helemaal goed zijn ingevuld. Zou je het nog eens willen controleren en opnieuw willen proberen? Kom je er niet uit? Bel dan 038 750 3491.