terug
2018-01-11

Olger Warnier

Flow based development - focus op afmaken

Gepubliceerd op 2018-01-11 door Olger Warnier

Een beetje geschiedenis

De afgelopen 15 jaar zijn we in de IT industrie 'agile' gaan werken, vaak door Scrum in te voeren. Bij Scrum gaat het om timeboxing waardoor er een kadans ontstaat van sprints, die elk een paar weken duren. In elke sprint worden user stories gemaakt, en die user stories worden geplanned, gecommit, gebouwd en geleverd. Daarnaast is er ruimte voor evaluatie van het werk met het doel om samen beter te worden.

De laatste 5 jaar zijn sprongen gemaakt in hoe snel software geleverd kan worden. De DevOps-beweging heeft in denken en doen geregeld dat we software volledig geautomatiseerd kunnen leveren. Hierdoor zijn er geen obstakels meer om nieuwe software direct –als het klaar is en door gebruikers geaccepteerd– uit te leveren.

De combinatie van Agile denken en de mogelijkheid om direct te leveren met DevOps heeft voor een verdere evolutie van het voortbrengingsproces in de IT geleid: KanBan heeft zijn intrede gedaan. Met KanBan wordt het voortbrengingsproces in stappen verdeeld en de hoeveelheid werk beperkt die per stap uitgevoerd mag worden. Met KanBan wordt een limiet gezet op de hoeveelheid onderhanden werk.

Onder het gebruik van een KanBan zit een dieperliggende filosofie, die van de Theory of Contraints. Theory of Containts (ToC) kijkt naar de doorlooptijd van werk en heeft als doel deze doorlooptijd te beperken. Het is handig dat je iemand snel iets kan leveren.

Hoe lang moet je wachten op resultaat?

De basis voor het verminderen van de doorlooptijd kan volgens ToC door het aantal dingen dat tegelijk moet gebeuren te beperken. Precies wat je in KanBan terugziet met de limiet op onderhanden werk. Dat KanBan werkt, kan aangetoond worden met de wet van Little. Deze wet stelt dat:

Doorlooptijd = Voorraad * Doorstroomsnelheid

Oftewel: als je taken hebt die alle 2 dagen werk vergen (doorstroomsnelheid), ben je na 6 (doorlooptijd) dagen klaar als 3 (voorraad) van deze taken nog onderhanden zijn. En, als iemand je vraagt om iets extra’s te doen, duurt het 8 dagen voordat het af is omdat de voorraad toegenomen is tot 4.

Hoe doe je dit als team?

Nu we weten dat het handig is om niet teveel tegelijk te doen en om niet teveel onderhanden werk te hebben, hoe organiseer je je dan als team? Een team creëert maximale doorstroming als het de volgende stappen zet: 1) Maak je voortbrengingsproces zichtbaar. 2) Bepaal welk deel 'het onderhanden werk' is 3) Zet een limiet op het onderhanden werk

Deze 3 stappen zorgen ervoor dat je inzicht krijgt in wat er gaande is. Maar er moet meer gebeuren om te zorgen dat de doorstroom soepel verloopt. Er wordt pas iets nieuws gestart als het onderhanden werk af is. Op deze manier zorg je ervoor dat het werk door het proces heen getrokken wordt, het is een pull based systeem. Deze aanpak staat bekend als Flow Based Development.

Van team naar proces

Een team bestaat in de regel uit specialisten met elk hun eigen kennis en kunde; wat ze kunnen overlapt elkaar meestal niet, daarvoor is het werk vaak te specialistisch. Het gevaar hiervan is dat 'wait states' kunnen ontstaan: de ene specialist kan pas verder als de andere specialist klaar is. De specialisten in een team moeten zo op elkaar ingespeeld raken dat ze samen het werk dat gestart is ook netjes kunnen afleveren.

Het kan voorkomen dat een specialist even geen werk te doen heeft omdat er andere zaken eerst afgerond moeten worden. De grote valkuil hier is dan om nuttig 'ander' werk te gaan doen. Hiermee vergroot je immers het onderhandenwerk vergroot en daarmee de doorlooptijd. John Cutler heeft een blog geschreven met dit en andere problemen bij de implementatie van Flow Based Development.

Dit betekent dan ook dat mensen bereid moeten zijn om elkaar te helpen, ook op een gebied dat niet direct eigen specialisatie is. Kortom, je hebt echt een team van mensen nodig en geen verzameling individuen. Daarnaast kun je door als team het werk slim te verdelen er voor zorgen dat iedere specialisatie door kan werken en dat al het werk goed op elkaar aansluit.

Daarom is ook de manier waarop specificaties gemaakt worden van belang. In het team van specialisten moet er ruimte zijn om naar een oplossing te zoeken voor het gegeven probleem. Een formaat van strakke user stories die stellen dat een knop in de webpagina geplaatst moet worden, zorgt ervoor dat niet ieder teamlid mee kan werken aan de vraag. Een probleemstelling die ruimte geeft om als team goed te functioneren is de basis van slagen bij Flow Based Development.

Flow based development

Flow based development richt zich op het verkorten van doorlooptijd tussen start en gebruik. Het proces wordt uitgevoerd door een team van specialsten die verantwoordelijk zijn voor het vinden van een functionerende oplossing, de technische implementatie en de ingebruikname ervan.

Door het gebruik van limieten op onderhanden werk wordt er gezorgd dat de dingen die starten ook snel geleverd kunnen worden. Dit proces is zichtbaar te maken en de data die hieruit voortvloeit kan gebruikt worden om te forecasten en in scenarios te denken waardoor ook minder tijd nodig is om te plannen.