Scrum in het groot bij bol.com

Interview: Liesbeth Westenberg

Ooit gestart als een initiatief van het Duitse mediaconcern Bertelsmann AG, is bol.com uitgegroeid tot een van de grootste webwinkels van Nederland en België. Sinds 2012 maakt bol.com deel uit van het Ahold-concern. Aanvankelijk richtte bol.com zich op de verkoop van boeken en cd’s, maar in de loop van de jaren is het assortiment steeds verder uitgebreid. Onlangs is de onlinewinkel uitgebreid met sieraden en horloges en twintigduizend kledingstukken voor baby’s en peuters. De enorme groei die bol.com heeft meegemaakt vraagt veel flexibiliteit van de systemen (zowel de webshop als de back-endsystemen) en vanwege de dynamiek in de markt wordt een steeds kortere time-to-market verlangd om vernieuwingen door te voeren.

In 2009 is bol.com gestart met agile (Scrum) ontwikkelen. In dit interview vertellen Scrum-coach Marc van Dongen en Rosine de Leeuw (informatieanalist en projectmanager) hoe Scrum is geadopteerd en hoe op basis van de ervaringen van de organisatie in de loop van de jaren de werkwijze is aangepast en verbeterd.

Zouden jullie willen omschrijven hoe bij jullie het agile werken is ingericht?

De Scrum-teams zijn bij bol.com verticaal georganiseerd. Dat betekent dat een team wordt gekoppeld aan een businessunit en daar ook fysiek plaatsneemt. Vaak werken de teams gericht op een thema, bijvoorbeeld het thema ‘voor 23:00 uur besteld, morgen in huis’. Maar dit kan ook het toevoegen van een nieuwe categorie zijn (zoals de nieuwe uitbreiding met baby- en peuterkleding).

De verticale organisatie betekent dat teams vaak in meerdere systemen (bijvoorbeeld zowel in front-end- als in back-endsystemen) wijzigingen moeten doorvoeren om de doelstelling van het project te halen. Met dertig teams aan het werk is goede afstemming noodzakelijk. Daarom wordt er twee keer per week een Scrum of Scrums gehouden met de dertig teams. Daarnaast zijn er domeinarchitecten (bijvoorbeeld voor het webshopdomein) die in de gaten houden wat de teams gaan doen in hun domein en die eventuele conflicterende belangen of afhankelijkheden hierin opmerken en oplossen. Architectuur is bij de voorbereiding betrokken en geeft het team (en de product owner) architectuurprincipes mee en kijkt naar de keuzes die effect hebben op de lange termijn.

Teams mogen zelf de sprintlengte kiezen, maar moeten wel in het ritme van de organisatie meedraaien, en dat ritme houdt in dat er elke vier weken een release is. De meeste teams werken in sprints van twee weken.

Om de prioriteitstelling van een team richting te geven is een roadmap geïntroduceerd. Voor elk team wordt een roadmap voor een jaar opgesteld. Deze roadmap wordt gedurende het gehele jaar continu geactualiseerd. Twee keer per jaar vindt een formele update plaats. Behalve richting geven aan de ontwikkeling helpt de roadmap ook bij het managen van afhankelijkheden tussen Scrum-teams en bij het expliciet maken van de impact van beslissingen van de business.

Wat zien jullie als de belangrijkste voordelen van agile werken?

Marc en Rosine zien veel voordelen van agile werken. In korte tijd noemen ze enthousiast een lange lijst voordelen:

• De sterke verbinding tussen business en IT.
• Het snel identificeren of iets wel of niet werkt.
• Veel minder scope creep door het werk in kleine stukjes te verdelen en vaak te releasen.
• Business en IT staan op gelijke voet en werken samen aan één doel.
• De verantwoordelijkheid ligt bij het team.
• Meer plezier in het werk.

Wat is voor jullie lastig bij het agile werken? Wat levert de meeste hindernissen op?

In de ruim vijf jaar dat bol.com scrumt, zijn heel wat hindernissen genomen. Een van de grootste hindernissen was hierbij de architectuur. Deze bestond uit zeven silo’s van systemen die onderling gekoppeld waren, waardoor de flexibiliteit ontbrak en er veel afhankelijkheden waren. Daarom is/wordt overgegaan naar een servicegerichte architectuur, waardoor er een ‘separation of concerns’ ontstaat. De architectuur houdt nu ‘continuous delivery’ nog tegen. Dit is wel iets waarnaar wordt gestreefd.

Het plannen van het werk blijft lastig, zeker met dertig parallelle Scrum-teams. Daarom wordt veel aandacht besteed aan het opknippen van plannen. Ook de roadmap helpt hierbij.

Het is grote winst dat de IT’ers bij de business zitten en goed samenwerken, maar ze zijn door hun expertise ook verantwoordelijk voor de technische houdbaarheid van oplossingen, op de lange termijn. We zien dat het belangrijk is daar focus op te houden.

Als laatste noemen Marc en Rosine de ‘Scrum-puristen’, die soms zo vasthouden aan het proces dat dit de teamdynamiek verstoort. Hierdoor wordt vergeten dat het gaat om de waarde van de rituelen en niet om het uitvoeren van de rituelen zelf. De Scrum-coach (die de teams adviseert) kan hierin helpen.

Houden jullie kengetallen bij? Meten jullie? Zo ja, wat?

Bij bol.com worden geen uitgebreide metrieken bijgehouden. De belangrijkste metingen zijn:

• velocity per team;
• voortgang op de roadmap (bijgehouden door de product owner);
• aantal user stories klaar voor sprint (is de sprint goed voorbereid?).

Deze metingen worden groen, oranje of rood gescoord.

De teams worden onderling niet vergeleken.

Hoe voeren jullie testen uit? Voeren jullie acceptatietesten uit na iedere iteratie? Betrekken jullie ook eindgebruikers bij het testen?

In elk Scrum-team zit ten minste één testexpert. Hij is ervoor verantwoordelijk dat er goed wordt getest (waar zitten de risico’s?, niet alleen de happy flow et cetera), maar de testwerkzaamheden kunnen door iedereen in het team worden uitgevoerd.

Bol.com maakt gebruik van geautomatiseerd testen. Dit wordt ook beschikbaar gesteld voor het uitvoeren van de acceptatietesten.

Omdat bij een release het werk van dertig teams bij elkaar komt, wordt er vóór een release ook getest. Hierbij wordt met name gecontroleerd of alles er wel in zit.

In de sprints worden geen testen gedaan door externe gebruikers (consumenten). Bol.com maakt gebruik van gebruikersonderzoeken waarin het succes van de gebruikersinteractie wordt gemeten. Interne gebruikers worden wel tijdens de sprint betrokken bij het testen van wijzigingen.

Hoe gaan jullie om met continue verbetering binnen/over de teams?

Het is voor elk team verplicht om een retrospective te houden en terug te kijken op wat er wel en niet goed ging tijdens de sprint. Vaak wordt een thema gekozen en worden onder het genot van een kop koffie stickies op de muur geplakt om de verbeterpunten te identificeren. Als Scrum-coach ziet Marc dat de kwaliteit van de retrospectives per team varieert. Een voorbeeld hiervan is de neiging om externe factoren de schuld te geven. Het is de rol van de Scrum-coach om hierop te letten en teams en Scrum-masters scherp te houden.

Hebben jullie nog een goede tip voor andere organisaties?

Een van de belangrijkste tips die Marc en Rosine geven is om de IT’ers bij de business te plaatsen. Hierdoor worden de lijnen kort, ontstaat er wederzijds begrip en wordt er gezamenlijk naar één doel gestreefd.  Daarnaast geeft Marc aan dat het heel belangrijk is om buy-in van de directie te hebben. Als laatste geven Marc en Rosine mee dat het goed is om eens buiten de deur te kijken en open te staan voor vernieuwing.