Kanban

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.

Continuous Delivery Continued

An updated version of the mind map.

Traditionally, releasing software was a time consuming process. Done by hand in combination with ad-hoc configuration changes.

By adopting techniques of automated build, test, and deployment, it's possible to gain many benefits: verify changes, make the process reproducible across environments.

 

Staging omgeving

Als onderdeel van ons release en test proces kunnen we beschikken over een staging omgeving. Gebruik kunnen maken van een dergelijke omgeving is ideaal, maar wat test je nu eigenlijk op zo'n omgeving en waarvoor gebruik je die?

Op dit moment gebruiken we het voor het testen van het deployment proces. Deployment is een proces dat semi-automatisch gebeurd. Nog niet alles is op dit moment geautomatiseerd. Zo nu en dan hebben we nog te maken met een aantal handmatige update stappen. Overigens wordt een groot deel van dat proces al wel automatisch uitgevoerd. Een gemiddelde update van onze productieomgevingen vindt doorgaans plaats binnen één uur.Het testen van die handmatige stappen en het testen van het deployment proces doen we dus op die staging omgeving.

Naast het testen van het deployment proces testen we ook of onze productieomgevingen ten opzichte van elkaar correct werken. Op dit moment bestaat die productieomgeving uit twee clusters. Een klant kan beschikken over een omgeving op één van beide clusters. Bij het uitrollen van een nieuwe release beginnen we altijd met het bijwerken van het eerste cluster. Doorgaans wordt het tweede cluster na een week na het bijwerken van het eerste cluster bijgewerkt. In die week tijd draait op productie dus twee versies van ons product. Daarnaast zijn er onderdelen (bijvoorbeeld de login server) die gedeeld worden door beide clusters. Het is dus belangrijk om te testen of het tweede cluster nog goed functioneert nadat het eerste cluster al is bijgewerkt. Ook hiervoor zetten we de staging omgeving in.

Continuous Delivery

As part of my job as release manager at Twinfield, I'm wondering if and how we can improve our release process. As we adopted the Scrum development methodology, we want to release frequently. Some weeks ago I bought a book about continuous delivery. 

During reading the book I decided to create a kind of mind map:

Note that I just started reading the book, so the mind map is far from complete yet.