Voorspelbaar agile werken

aan digitale projecten

Bij Driebit hebben we het graag over itereren. Om tot een goed product te komen, moeten er veel iteraties worden gedaan waarbij het product steeds iets beter wordt dan de vorige versie. Hoewel we deze filosofie religieus toepassen op onze productontwikkeling, lijkt ons projectproces soms immuun voor verandering. We passen al jaren vrij dogmatisch de Scrum methode toe zoals die staat omschreven in de literatuur over agile werken. Dat terwijl lang niet elk project vlekkeloos verloopt. Tijd om te itereren op ons eigen werkproces.

Van push naar pull

We merken vaak dat het werken in sprints een zeer onrealistische planning oplevert. We plannen soms met oogkleppen op voor al het werk dat we moeten doen naast het werk dat is ingeroosterd voor de sprint. Die hoeveelheid werk kan vaak een aanmerkelijk deel van de tijd in beslag nemen. Denk bijvoorbeeld aan het bedienen van klanten met bestaande websites en productontwikkeling. Wanneer een sprint voorbij is, staat de volgende sprint alweer op de stoep; ongeacht of de werkzaamheden wel of niet zijn gedaan. Het inplannen van sprints zorgt er zo voor dat er elke keer aan nieuw werk wordt begonnen, zonder dat er rekening wordt gehouden met de hoeveelheid werk waar al aan begonnen is. Dit kun je een push-georiënteerd proces noemen. Ongeacht de capaciteit wordt er met nieuw werk gestart, omdat het nou eenmaal zo in de planning staat. 

Het zou veel realistischer zijn als je commitment geeft aan nieuw werk op basis van de daadwerkelijk beschikbare capaciteit. Pas als er capaciteit beschikbaar komt, start je met nieuw werk. Die capaciteit is vrij eenvoudig te berekenen: als je er van uitgaat dat de hoeveelheid werk waar je tegelijk mee bezig kunt zijn constant blijft, dan is de hoeveelheid werk die je op je kunt nemen gelijk aan de gemiddelde output van je proces. Het maakt daarbij niet uit hoe groot elke taak die we afronden is, het gaat erom dat er niet te veel werk tegelijkertijd wordt gestart. Deze methode is pull-georiënteerd, je trekt werk het proces in, in plaats van dat je het er doorheen drukt. We passen een dergelijke pull strategie inmiddels met succes in een van onze teams toe. Dat is een essentieel verschil met het berekenen van je velocity aan de hand van story points, waarbij de geschatte omvang van het werk wordt bepaald op de hoeveelheid werk waaraan commitment kan worden gegeven. Onafhankelijk van de capaciteit om nieuw werk op je nemen.

Van voorspellingen naar voorspelbaarheid

Het voorspellen van een realistische opleveringsdatum is iets wat keer op keer onmogelijk lijkt binnen de IT-branche. Daar liggen meerdere redenen aan ten grondslag, maar verreweg de beste plek om te beginnen met het verbeteren van de situatie is het proces zelf zich voorspelbaarder mogelijk te laten gedragen. Om dit te doen moet de focus binnen het proces liggen op het zoveel mogelijk afmaken van werk in de volgorde waarop er aan wordt begonnen. Dat klinkt voor de hand liggend, maar in werkelijkheid is dit bijna nooit het geval. Je kunt dit gegeven ook eenvoudig kwantificeren door de doorlooptijd van een taak af te zetten tegen de tijd dat er actief aan een taak is gewerkt. Hoe meer die twee factoren uit elkaar lopen, hoe minder efficiënt het proces is. Maar ook hoe onvoorspelbaarder de opleveringsdatum van het werk dat je doet.

Wanneer je ergens aan begint is het zaak om zo min mogelijk voorrang te geven aan werk waar later aan is begonnen. Een van de manieren waarop je dat kunt proberen af te dwingen is door de hoeveelheid taken waar tegelijk aan mag worden gewerkt te beperken. Dit is de zogenaamde 'work in progress limit', afkomstig van de methode Kanban. Wanneer de limiet is bereikt, mag er niet aan nieuw werk worden begonnen en moet je elkaar eerst helpen de reeds begonnen taken af te maken.

Hoewel deze aanpak wat contra-intuïtief kan aanvoelen, wierp het vrijwel direct zijn vruchten af toen we het hier bij Driebit gingen uitproberen. Het werk komt eerder bij onze testers terecht, waardoor er sneller feedback op de ontwikkelde software wordt gegeven. Er is meer samenwerking tussen werknemers en kennisoverdracht komt op een natuurlijke manier tot stand. Taken worden grondig afgemaakt. Kortom, zowel de efficiëntie als de kwaliteit van het werk is er op vooruit gegaan.

Onze volgende iteraties?

Om te voorkomen dat we alleen maar op ons gevoel afgaan bij het evalueren van nieuwe iteraties van ons proces willen we voortaan de verbeteringen gaan toetsen aan de hand van statistieken. Daarom zijn we bezig om de gegevens uit verschillende registratiesystemen die we in gebruik hebben te koppelen, maar dit heeft nog wat voeten in de aarde.

Op basis van die data kunnen we gaan experimenteren met verschillende methoden die het mogelijk moeten maken om een betere voorspelling te doen over wanneer er capaciteit vrijkomt om aan nieuw werk te beginnen. We hopen daarmee met meer precisie vooruit te kunnen kijken wanneer we een planning opstellen.

Een ander aspect van het proces waar volgens ons nog veel te winnen valt is de definitiefase van het werk. Op welke manier kunnen we nog scherper kijken naar de prioritering en definitie? Kortom, er zullen bij Driebit nog veel iteraties volgen.

Wil je misschien...

Content

Name

Role