Een kijkje in de keuken van een agile team

In mijn eerste blog vertelde ik dat je op zoek kan gaan naar je eigen agile (agility) en je niet zoveel moest aantrekken van de agilepolitie. Mijn tweede blog ging over dat je eerst moet beginnen bij het gedrag. In deze blog wil ik het hebben over een praktijkvoorbeeld. Ik beloofde jullie om over een team te schrijven die het risico loopt om afgefakkeld te worden door de agilepolitie. Ik ben er al 2 jaar onderdeel van: de gele kanaries!

 

Geen zuurstof

Denk je meteen aan een kanarie in een kooitje die diep in de mijn in de gaten moet houden of er gevaar dreigt voor de mijnwerkers? Onze naam komt van de bar in Rotterdam: de gele kanarie. Maar als team zijn we eigenlijk wel een kanarie als er iets mis is. We gaan dan niet dood, maar we kunnen wel flink om ons heen kwetteren en de verbinding met de rest van de organisatie zoeken.

 

Stichting Inlichtingenbureau

Een beetje context: binnen stichting Inlichtingenbureau zijn wij een projectteam dat nieuwe producten ontwikkelt. Zo ontwikkelen we VUM en VWI die de gemeentes en daarmee ook de burgers sneller, makkelijker en betrouwbaarder kunnen ondersteunen bij het uitvoeren van de verschillende werkzaamheden. Voor de uitvoering van hun werkzaamheden heeft een gemeentelijk consulent veel verschillende informatiebronnen nodig, zoals BRP, UWV en SVB. Dit om informatie te verzamelen, samen te voegen en er conclusies uit te trekken of bijvoorbeeld iemand recht heeft op een uitkering. Of we hebben een berichtenservice gemaakt die werknemersprofielen en vacatures vanuit het hele land deelbaar maakt. Hierdoor helpen we de medewerkers met het matchen, want dat blijft mensenwerk. Aangezien deze projecten grote maatschappelijke voordelen met zich mee brengen worden ze vanuit het ministerie bekostigd. De opgeleverde software wordt gratis aangeboden aan overheidspartijen zoals gemeentes en andere gemeentelijke samenwerkingsvormen.

 

Als je diep zit, kan je alleen nog maar omhoog

Op een gegeven moment was het projectteam van VUM uit elkaar gevallen en moest alles weer langzaam opgebouwd worden. Nieuwe mensen kwamen erbij, het team werd flink uitgebreid, er kwam meer structuur, we kregen minder dubbelrollen, we gingen een scrumbord en een backlog gebruiken enz. Dat laatste was zeker nodig, want het valt niet mee als je de userstories van Word-document versie 3.5 moet koppelen aan de userstories van Exel-document versie 3.6. En dan misschien ook nog verifiëren met wat mailtjes. Kortom er viel een hoop te verbeteren.

 

Continue verbeteren

Het belangrijkste hierbij was dat we de lijntjes korter probeerden te maken. We wilden sneller weten wat het programma wilde. We zijn ook gaan kijken wat nu echt belangrijk is en wat waste. Bijv. voor het testen schreven we ellenlange testrapportages, die misschien door 1 persoon gelezen werden.

We moesten per se zo snel mogelijk opleveren met een pipeline, maar waarom eigenlijk? Hoe vaak zit de gebruiker op een update te wachten?

Zo had het programma een acceptatietester ingehuurd en die nam contact met ons op. We kwamen erachter dat hij bijna dezelfde behoeftes heeft als ons team. En dat we hetzelfde aan het testen waren. Ook was hij al erg ver met geautomatiseerd testen. Na een aantal maanden hebben de acceptatietester en ons team besloten om een gezamenlijke automatische test te maken en daarmee ook een robuuste testgenerator. We hebben gezorgd dat de geautomatiseerde kant van de acceptatie meegenomen werd in onze pipelinetesten.

Doen om het doen

Er konden nog een aantal zaken beter. De refinements liepen slecht. Het waren veel items, die in een sneltreinvaart voorbijkwamen. Een userstory bestond uit wat halve zinnen en we hadden geen gezamenlijk beeld wanneer een userstory goed uitgewerkt was. Zo werd er niet stilgestaan bij de testbaarheid van de userstory. Uiteindelijk heb ik de 3 amigo’s methode geopperd. Deze hebben we uitgeprobeerd en die werkte goed, maar leek ons uiteindelijk te zwaar om bij iedere userstory in te zetten. Tegenwoordig komt onze PO van tevoren bij iedereen langs met de userstories voordat het de refinement in gaat. Dus we hebben wel iets van die methode geadopteerd. En zo zijn we eigenlijk overal te werk gegaan. We werken met sprints, we schatten userstories in, we hebben een standup, retro en een sprintplanning. Kortom we scrummen? Zo schatten wij userstories in, maar letten wij niet op de velocity. Er is wel eens geopperd: maar moeten wij niet op onze velocity letten en de burn-down chart? Kijken of de geschatte punten overeenkomen met de werkelijk? Mijn wedervraag was: voor wie doen we dat? Doen we dat omdat scrum het voorschrijft? Is er iemand buiten ons team geïnteresseerd in onze velocity? We merkten namelijk dat we plannen lastig vonden. Dus ik opperde: waarom zoveel tijd investeren in iets wat we niet doen en niet kunnen? Dan kunnen we de tijd beter gebruiken om er een tandje bij te zetten als we een keer wat harder moeten.

 

Volwassenheid

Onze sprintplanning gaat zo: “heeft iedereen genoeg werk? Dit zijn de belangrijkste userstories die af moeten en als je zonder werk zit, dan pak je er maar wat bij of je meld je bij mij” (de PO). Wij hebben geen scrummaster, deze is opgegaan in de functie van de PO en ook de projectleider. Samen zorgen ze ervoor dat wij als team niets te kort komen. En halen ook zoveel mogelijk hordes weg. Ik ben van mening dat wij allemaal volwassen genoeg zijn dat we weinig sturing nodig hebben. We nemen zelf verantwoordelijkheid, we helpen elkaar wanneer het nodig is, we zoeken elkaar regelmatig op, we doen ook leuke dingen met elkaar en we kunnen elkaar aanspreken op de goede en minder goede dingen. En dat allemaal op een respectvolle manier, waarbij je kan zeggen wat je wil zeggen. Niemand heeft de overhand, we vertrouwen elkaar. En hierdoor kunnen we ons aan iedere situatie aanpassen. Wij maken ons niet druk dat we de sprint niet halen of dat testautomatiseringstaken wat langer op het bord staan. Wij zorgen dat we op tijd en met de juiste kwaliteit software opleveren. En we betrekken de klant er zoveel mogelijk bij. We willen zoveel mogelijk laten zien en transparant zijn. Tot nu toe heeft dit een aantal blije klanten opgeleverd. Ze voelen zich betrokken en het resultaat is snel te zien. Ons team is goed op elkaar ingespeeld, maar je kan er ook zo nieuwe mensen inpassen (niet te veel tegelijk natuurlijk). En stap voor stap willen we steeds een stapje beter.

 

Conclusie

Is dit nou scrum? Nee. Is het agile? Ja. Is scrum agile? Ja. Is agile scrum? Nee. Dit is iets wat werkt voor ons, dit is maatwerk. Ja maar in het scrumboekje staat dit en dat. Ja dus? Dan werken we niet volgens scrum. Waarom moeten we volgens iets werken? Wij werken op onze eigen manier. Maar pas op: we kijken wel degelijk om ons heen. Van alles wat we aangereikt krijgen gaan we kijken wat we ervan kunnen gebruiken en de rest is waste. Ik vind dat pas echt agile. Want wie werkt nou echt helemaal 100% agile volgens alle regeltjes, richtlijnen, boeken etc.? Die gaan uit van de ideale situatie. Ik heb gemerkt dat niemand in de ideale situatie zit. Iedereen zit nog in de beginfase of ergens in het midden. En dan is het een kwestie van gedrag en iedere keer een stapje beter. En alleen maar als het de klant verder helpt, die is leidend. Anders ben je weer aan het verbeteren om het verbeteren. Kortom als je in het midden zit en het loopt lekker, dan zit je al in de ideale fase. En natuurlijk kan je je laten inspireren om een stapje verder te gaan met agile. Het is zeker geen onzin, maar doe het in je eigen tempo en als je er klaar voor bent.

Jochem Gross - Agile Tester (https://www.linkedin.com/in/jochemgross/)

Naar het overzicht