The way Kanban helped us to get maintenance in control
Inleiding
In de drie jaar dat we werken op basis van de Agile principes, zijn we geruime tijd op zoek geweest hoe we maintenance issues op een Agile manier kunnen aanpakken. Uiteindelijk biedt Kanban ons de oplossing. In dit artikel beschrijf ik hoe we zowel Kanban als Scrum gebruiken binnen onze development afdeling.
Achtergrond
We zijn een innovatief software bedrijf die zich richt op een SaaS oplossingen voor online accounting. De development afdeling bestaat uit vier teams verdeelt over drie locaties. Elk team werkt gedurende een sprint, die bij ons twee weken duurt, aan een specifiek project. Deze projecten worden geïnitieerd vanuit de product council en hebben onder meer betrekking op het toevoegen van nieuwe functionaliteit, wijzigingen i.v.m. gewijzigde regelgeving, implementeren van nieuwe technologieën, enzovoort.
Historie
Drie jaar geleden zijn we overgegaan tot het toepassen van Agile principes in het software ontwikkel proces. Vooral in het begin hebben we moeite gehad hoe maintenance issues op een Agile manier te kunnen aanpakken. Belangrijk voor ons is om issues met een hoge prioriteit snel op te lossen en snel beschikbaar te stellen aan onze klanten. Daarnaast willen we ook een goede voorspelling kunnen doen wanneer projecten klaar zijn en in gebruik kunnen worden genomen door onze klanten.
Maintenance in een sprint
We zijn begonnen met het toevoegen van issues aan een sprint. Nadeel hiervan was dat de velocity van het team fluctueerde. Hierdoor was het zeer lastig om in te schatten wanneer een project afgerond zou zijn. Kenmerkend voor issues is, dat het vaak lastig is om in te schatten hoe lang het duurt voordat het issue is opgelost. Start je aan het begin van de sprint met het oplossen van de issues die aan de sprint zijn toegevoegd, dan verlies je een stuk dynamiek. Komt er een issue binnen met een hoge prioriteit, dan moet je die alsnog in een lopende sprint opnemen, waardoor de gehele sprint in gevaar komt. Wacht je tot de volgende sprint, dan laat de uiteindelijke oplossing voor de klant op zich wachten. Begin je pas aan het einde met het oplossen van de issues, dan loop je het gevaar dat de sprint al is afgelopen, maar de issues nog niet opgelost.
Dedicated maintenance team
Het volgende dat we hebben geprobeerd is het gebruik maken van een dedicated maintenance team. Voordeel hiervan is dat het geen verstoring geeft op de projecten. Daarnaast is er een team full-time bezig met het oplossen van issues. Nadeel is, dat het uitvoeren van maintenance niet altijd als even leuk wordt ervaren. Uiteindelijk zijn we hier ook mee gestopt.
Onze oplossing
Uiteindelijk zijn we tot een structuur gekomen, die tot nu toe erg goed bevalt. De basis is dat elk team ook het maintenance team is. Dit niet iedere sprint, maar op roulatie basis. Concreet houdt dit in dat een team één keer in de vier sprints een sprint alleen maar bezig is met het oplossen van maintenance issues.
Scrum
De projecten die we uitvoeren worden via de Scrum methodiek uitgevoerd. Features en user stories worden uitgewerkt en tijdens grooming sessies van story points voorzien. Tijdens de sprint planning worden user stories op basis van prioriteit en story points aan een sprint toegevoegd. Deze werkwijze is echter niet gemakkelijk te hanteren voor maintenance issues. Immers er is een continue wisselwerking van prioriteit en het uitdrukken in story punten is lastig.
Kanban
Dat heeft ons er uiteindelijk te doen besluiten om binnen de maintenance sprint gebruik te maken van Kanban. Net zoals bij Scrum maakt Kanban ook gebruik van een product backlog. In het geval van maintenance bevat deze product backlog alle maintenance issues. De issues staan gesorteerd op basis van prioriteit, startend vanaf hoge prioriteit en aflopend naar lage prioriteit.
Het principe van Kanban is dat er wordt gestart met het issue dat bovenaan staat. Zoals al gezegd is dit het issue met de hoogste prioriteit. Vervolgens wordt er gestart met het eerst volgende issue, enzovoort. Het is wel belangrijk om voor ogen te houden dat er maar een beperkt aantal taken op hetzelfde moment in bewerking staan. Dit om ervoor te zorgen dat de werkzaamheden worden afgerond voordat er met een nieuw issue wordt begonnen. Doorgaans wordt er door één of twee ontwikkelaars aan een issue gewerkt. In een team van zo’n vijf ontwikkelaar houdt dit in dat er aan twee à drie issues op hetzelfde moment wordt gewerkt.
Deze manier van werken biedt ons een aantal voordelen:
- Het geeft ons de dynamiek die we graag willen om belangrijke issues snel opgelost en in productie te krijgen;
- Het heeft geen invloed op de voorspelbaarheid;
- Het tijdsaspect tot het oplossen van een issue is van minder invloed.
Dynamisch werken
Voordeel van het gebruik maken van Kanban is, dat op het moment er een nieuwe issue binnenkomt deze eenvoudig geprioriseerd kan worden. Heeft het een hoge prioriteit, dan zal het snel worden opgepakt omdat het issue in het bovenste deel van de backlog komt te staan. Vooral dit biedt ons de mogelijkheid om hoge prioriteit issues snel opgelost en uitgerold te krijgen.
Voorspelbaarheid
Hoewel een team dat in maintenance zit niet aan een project werkt wordt de velocity ook niet beïnvloed. We zijn dus nog steeds goed in staat om in te schatten wanneer een project afgerond is.
Tijdsaspect
Een ander voordeel is dat door te werken via Kanban het tijdsaspect een kleinere rol speelt. Er van uitgaande dat user stories goed zijn voorbereid zijn deze voor een sprint team met de nodige ervaring zeer goed in te schatten. Hierdoor is het ook relatief eenvoudig om een sprint goed te vullen. Met maintenance issues ligt dat moeilijker. Het komt regelmatig voor dat vooraf niet precies bekend is wat er uiteindelijk allemaal moet gebeuren om een issue opgelost te krijgen. Wat is er bijvoorbeeld aan verder onderzoek nodig en hoe snel kan de uiteindelijke oorzaak gevonden worden. Het vullen van een sprint met issues is dan niet triviaal. Ook hier helpt Kanban ons een handje.
