Verbeter de Agility in jouw IT-teams met deze 7 stappen

Mensen die bovenstaande vraag vol zelfvertrouwen beantwoorden, noemen vervolgens alle Agile Practices op die zij gebruiken, zoals Scrum, Kanban, retrospectives, stand-ups, demo's of Test Driven Development. De terughoudendheid bij de anderen wordt grotendeels veroorzaakt doordat ze niet precies weten wat Agile inhoudt. Wat doe jij Agile? Wat is voldoende?

Wat betekent Agile werken precies?

Het helpt om Agile niet als stug concept te zien, maar als een methode om 'maturity' te meten. Iedereen en elk team werkt Agile, maar niet elk team heeft hetzelfde maturity-niveau bereikt. De verschillen tussen teams en individuen kunnen weliswaar groot zijn, maar net zoals bij Kaizen (letterlijk: continu verbeteren) of karate, zal niemand ooit echt de top bereiken. Er is altijd ruimte voor verbetering.

Dit geldt ook voor Agile werken: verbeter je Agility in het algemeen door Agile Practices toe te passen. Om echt te blijven groeien en te voorkomen dat je op een bepaald Agile niveau blijft steken, moet je meer doen dan alleen Agile Practices kopiëren en toepassen. Het is belangrijk om naar continue verbetering te streven en je werkwijze consistent te meten aan de hand van de 12 Agile principes.

Agile werken betekent dat jij je werkwijze continu vormt en verbetert op basis van de Agile principes. Controleer je proces regelmatig en gebruik de Agile principes daarbij als richtlijn en de Agile Practices ter inspiratie!

Agile werken betekent dat jij je werkwijze continu vormt en verbetert op basis van de Agile principes. Controleer je proces regelmatig en gebruik de Agile principes daarbij als richtlijn en de Agile Practices ter inspiratie!

Dit geldt ook voor Lean werken. Dit betekent dat jij je werkzaamheden continu evalueert aan de hand van de 7 principes van Lean softwareontwikkeling.

Omdat deze 19 principes vrij overweldigend kunnen zijn, heb ik op basis van deze principes 7 stappen ontwikkeld die je IT-teams helpen om echt Agile te leren werken.

7 stappen voor nieuwe of bestaande teams om echt Agile te leren werken

Denk na over het complete traject dat het product aflegt waar je momenteel aan werkt. Dit begint bij de waarde die je wilt creëren voor de klant of bij de aanname die je wilt verifiëren. En het eindigt als de kleinste oplossing voor het gewenste resultaat is geleverd aan de eindklant. Laten we met dat proces in gedachten, de 7 stappen doorlopen die je helpen om je IT-teams echt Agile te leren werken:

De 7 stappen om echt Agile te leren werken

1. Visualiseren, visualiseren, visualiseren

Visualiseer fysiek waar je teams aan werken. Visualisatie zorgt voor verbeterde transparantie en maakt het eenvoudiger voor anderen om deel te nemen aan discussies. Met een zichtbare workflow creëer je structuur in de samenwerking en kun je tijdens discussies dieper ingaan op onderwerpen. Dit zijn een aantal manieren om te visualiseren waar je team aan werkt:

• visualiseer de workflow aan de hand van een fysiek Kanban-bord, gebruik sticky notes om de waarde weer te geven die je wilt creëren en kolommen (lanes) voor de verschillende stappen die zijn vereist. Maak aantekeningen op de sticky notes om te laten zien waar er belemmeringen zijn. Voeg avatars toe om te laten zien waar iedereen binnen het team mee bezig is.
• visualiseer het traject van de klant, de productomschrijving en de releases door te zorgen dat de User Story Map zichtbaar is in de kamer van het team. Je kunt ook mockups van het scherm of screenshots van het product aan de muur hangen. Stel persona's op en geef een overzicht van de beschikbare gegevens over eindgebruikers.
• stimuleer discussies over het ontwerp van je software door architectuurdiagrammen af te drukken en op te hangen in de gezamenlijke ruimte van het team. Visualiseer ook het domeinmodel zodat iedereen dezelfde taal spreekt tijdens deze discussies.
• creëer inzicht in gebruikers door het doel van je product te visualiseren. Welke functies worden er wel gebruikt en welke niet? Hoeveel gebruikers lopen tegen fouten aan?
• zet je in voor een gezamenlijk doel door de voortgang te meten richting de volgende mijlpaal of MVP. Zorg dat belemmeringen in het proces, zoals fouten in je build pipeline, zichtbaar zijn op een tv-scherm zodat het gehele team op de hoogte is. 

TIP: Laat bezoekers, in het bijzonder zakelijke belanghebbenden of sponsors, de visualisaties in de teamruimte zien. Dit stelt hen gerust, geeft een veilig ‘Boots on the Ground’-gevoel en biedt waardevolle inzichten in het project. Het geeft een gevoel van zekerheid en vertrouwen.

2. Samenwerking > documentatie

Voor het bouwen van gecompliceerde producten zijn uiteenlopende vaardigheden en mensen vereist. Creëer geen documenten om ze daarna simpelweg aan de volgende persoon binnen het proces te geven, maar stel persoonlijke samenwerking en kennisoverdracht centraal. Documenten kunnen snel achterhaald raken en het kost tijd om alles te actualiseren. En jij houdt je liever bezig met het verzetten van het echte werk.

Deel informatie persoonlijk of neem deel aan brainstormsessies, zodat alle betrokkenen bij het ontwikkelingsproces meer inzichten verwerven en hun taak beter en hoogwaardiger kunnen uitvoeren. Dit zijn enkele ideeën:

• Doorloop samen met het hele team regelmatig het softwareontwerp, de architectuur, het traject van de klant en het domeinmodel.
• Begin de ontwikkeling van een story met een kick-off waarbij de story en onderbouwing rechtstreeks door de analist worden toegelicht. Vergeet ook niet om je tester hierbij te betrekken, als die er is!
• Pair programming is een van de beste manieren om van elkaar te leren en het hele team op één lijn te krijgen.

3. Snelle feedback

Het bouwen van een product doe je samen met het team en vergt veel werk. We willen de juiste keuzes maken en goede kwaliteit bieden. De enige manier om te zorgen dat je waardevol werk levert is door snelle feedback te geven én ontvangen. Dit betreft feedback die je van gebruikers krijgt over de functies die je hebt gebouwd, maar ook van de volgende persoon in je workflow. Hoe sneller je feedback krijgt hoe kleiner de kans dat de volgende persoon teleurgesteld is over de kwaliteit van het werk dat je hebt geleverd voordat je het verbeterde. Dit zijn enkele manieren om snelle feedbackcycli te bouwen:

• valideer vroege mockups of snelle prototypes van de oplossing eerst met de eindgebruiker voordat je daadwerkelijk van start gaat met de ontwikkeling. Zorg dat iedereen in het team zich beter in de gebruikers kan verplaatsen door het product dat ze hebben gebouwd regelmatig te gebruiken en testen.
• zorg voor snelle en frequente releases. Je weet bij één release per jaar pas na een jaar of het de moeite waard is geweest.
• voer een technische controle van elke story uit na afloop van de analyse om de kwaliteit van de analyse te verbeteren en belemmeringen tijdens de ontwikkeling te voorkomen. Voer ook na het uitbreiden van een story een technische controle uit om de kwaliteit van de uitbreiding te verbeteren.
• valideer de voorgestelde architectuur en de daaruit voortvloeiende aanpassingen bij het team om al in een vroeg stadium feedback te krijgen over de haalbaarheid. Organiseer daarnaast regelmatig retrospectives met het team en externe belanghebbenden of vakgenoten om frequent van iedereen feedback te ontvangen. Gebruik deze feedback om je product of processen te verbeteren!
• zorg dat nieuwe functies zo snel mogelijk beschikbaar zijn voor testgebruikers, belanghebbenden en daadwerkelijke eindgebruikers. Vergeet ook niet om te controleren hoe gebruikers de functies gebruiken die je in een eerder stadium hebt gebouwd.

4. Ontwikkel een probleemloze workflow

Om te zorgen dat je team functioneert als een goed geoliede machine, moet je een probleemloze workflow garanderen. Geplande werkzaamheden kunnen dankzij een goede workflow in korte tijd worden geleverd. De organisatie hoeft minder te investeren voordat de opbrengsten zichtbaar worden.

Zorg voor een expliciete epic- en story-workflow door alles inzichtelijk te maken met een Kanban-bord. Blijf daarna verbeteringen doorvoeren. Dit zijn enkele tips:

• bepaal welke beperkingen er gelden voor de verschillende stappen in je proces in de categorie WIP (Work In Progress). Voorkom dat er 'doelloze' werkzaamheden worden verricht door wachtrijen te verkleinen, zoals bij 'gereed voor ontwikkeling', 'te testen' en vooral bij 'wachten op implementatie'. Trap niet in de Scrum-val en denk niet dat je klaar bent als je de story hebt geïmplementeerd. De waarde wordt pas geleverd als de functionaliteit in productie beschikbaar is.
• bekijk hoeveel post-its er in behandeling zijn in je workflow, dit kan een story zijn die wordt geanalyseerd, gecontroleerd, ontwikkeld of geïmplementeerd. Worden het er op den duur steeds meer? 
• herhaal deze mantra: “Stop starting. Start finishing!” Begin niet zomaar met het analyseren of ontwikkelen van een nieuwe story als je ook een collega kan helpen om een lopende story te voltooien.
• verdeel belemmeringen, gecompliceerde story's of de eerste opzet van een project over het hele team. De doorlooptijd zal aanzienlijk korter worden en met minder neveneffecten gepaard gaan.

5. Verdeel werkzaamheden in kleinere porties

Verdeel het werk in kleinere porties zodat de werklast voor het team zo klein mogelijk is voordat er daadwerkelijk functionaliteit geleverd wordt. De feedbacklijnen zijn zodoende niet alleen korter, maar je team haalt ook meer voldoening uit de delen die ze afronden.

Het opdelen van werkzaamheden in kleinere taken lijkt in eerste instantie misschien lastig. Je kunt werkzaamheden als volgt opsplitsen:

• verdeel een uitgebreid draaiboek of product in kleinere releases of Minimal Viable Product-verbeteringen (MVP) op basis van de waarde die dit oplevert en houd hierbij rekening met het traject van de klant. Richt je eerst op het leveren van de first release voordat je verdergaat met de volgende release.
• verdeel releases of MVP's in Epics of functies die je moet leveren. Richt je eerst op het afronden van de meest belangrijke Epics voordat je verdergaat met de volgende Epic.
• verdeel Epics of functionaliteiten in Story's die in maximaal 2 tot 3 dagen zijn te implementeren. Richt je op het voltooien van lopende story's voordat je aan nieuwe story's begint.

Nadat je het werk hebt verdeeld in Epics en Story's, kun je prioriteiten instellen voor de meest belangrijke onderdelen van een MVP. Zo kan het daadwerkelijke leveren met minimale inspanning worden gestart zonder het overzicht te verliezen.

6. Resultaat > output

Door je werk continu te verbeteren, kun je een soepele workflow en een hoge output garanderen. Het is echter belangrijker om het gewenste resultaat te leveren dan een hoge output. Anders geef je geld uit dat de organisatie aan andere zaken had kunnen besteden. Dus:

• evalueer je werkzaamheden. Welke waarde gaat je product leveren?
• richt je op lopende werkzaamheden en begin niet aan nieuwe taken.
• zorg dat je team het werk afrondt tot aan de live levering aan de klant. Alle analysewerkzaamheden die nog niet zijn ontwikkeld, alle code die is geschreven en die nog niet is geproduceerd, is nog steeds 'afval'. Het heeft immers geen waarde voor de eindgebruikers.

7. Kwaliteit en eenvoud

Het leveren van kwaliteit moet bij iedereen centraal staan binnen het ontwikkelingsproces. Als dat niet het geval is dan is de kans groot dat je suboptimale resultaten levert voor de volgende (of laatste) stap in het proces. Denk bijvoorbeeld aan fouten, belemmeringen en vraagtekens die uiteindelijk meer tijd en middelen opslokken. Zorg voor een optimale focus en voorkom ongelukjes, streef altijd naar de meest eenvoudige oplossing om doelstellingen te realiseren. Een eenvoudigere oplossing is gemakkelijker te begrijpen, implementeren, uit te leggen en ondersteunen.

• Implementeer uitsluitend wat je op dat moment nodig hebt en wat binnen het bereik van de huidige story, spike of epic valt. Het uitbreiden van het bereik kan resulteren in werkzaamheden die uiteindelijk niet worden gebruikt.
• Inefficiënte codes of werkwijzen leiden tot een 'technical debt' waarvoor je organisatie uiteindelijk de rekening zal moeten betalen. Verminder die technical debt door consistent kleine onderdelen te verwijderen. Door kleine onderdelen te verwijderen, zijn er op de korte termijn geen negatieve gevolgen voor de prestaties van het team en kan er wel nog steeds worden geprofiteerd van de positieve resultaten op de middellange en lange termijn.
• Gebruik tools zoals Sonar om de kwaliteit van de code te beoordelen. Zorg dat het een gewoonte wordt om bij het implementeren van nieuwe functies de technical debt te verminderen in de code die je aanpast. Continue, kleine herstructureringen hebben geen gevolgen voor de levering van waarde, maar een ingrijpende herschrijving zal een enorme impact hebben bij een te grote technical debt.

Takeaway

Het is niet in elke (IT-)organisatie gangbaar om aan de hand van Agile en Lean principes werkzaamheden continu te verbeteren. In deze blog worden enkele praktische stappen beschreven die je kunt nemen om te zorgen dat je IT-teams echt Agile leren werken. Deze stappen hoeven echter niet allemaal tegelijkertijd te worden geïmplementeerd. Begin met stappen die overzichtelijk zijn voor jou en het team en evalueer, verbeter en herhaal dit proces. Zo kun je op een Agile manier zorgen dat je IT-teams echt Agile leren werken.

Geïnteresseerd in meer informatie, tips, richtlijnen of meer? Neem contact op met onze Agile coaches en zij helpen je op weg!

Pictogrammen zijn gemaakt door Freepik van www.flaticon.com