Silver bullets bestaan niet in softwareontwikkeling. Effectieve softwareteams bepalen zelf hoe ze hun werk doen, passen zich continu aan en verbeteren zichzelf. Continue verbetering is ingebed in de Agile-mindset en -principes en helpt zo om de flexibiliteit in bedrijven te verhogen en meer waarde te leveren.
Softwareontwikkeling is een creatieve bezigheid. Het is geen productiewerk dat vooraf gedetailleerd is te definiëren en te plannen, om het daarna volgens plan uit te voeren. Het is een complex proces, waarbij kenniswerkers intensief samenwerken om de behoeften van hun klanten te begrijpen en een geschikte aanpak te vinden om producten te ontwikkelen die voldoen aan deze behoeftes.
De behoeftes die tegenwoordig worden gesteld aan softwaresystemen zijn uitdagend. Cloudontwikkeling en het internet of things zorgen voor nieuwe mogelijkheden en organisaties willen de eerste zijn met een oplossing om marktaandeel te pakken. Pas wanneer klanten softwaresystemen gebruiken, worden de werkelijke behoeftes duidelijk en vaak worden dan ook nieuwe behoeftes zichtbaar. Organisaties moeten kunnen innoveren en kunnen omgaan met veranderingen om succesvol te zijn.
We hebben allemaal weleens gehoord dat silver bullets niet bestaan, en dat is zeker het geval bij softwareontwikkeling. Er is geen ‘enige juiste manier’ of ‘beste manier’ die altijd voor succes zorgt; in feite zijn er zo veel verschillende manieren dat het onpraktisch en te duur is om zelfs te proberen de beste manier te vinden. Agile en DevOps helpen teams om hun eigen werkwijze te definiëren en te verbeteren.
De kans bestaat dat het bij een eerste poging om een softwareproduct te leveren niet helemaal goed gaat. Van de fouten en mislukkingen kunnen teams echter leren. Het is altijd mogelijk om de softwareontwikkeling te verbeteren. Aangezien er een noodzaak is om beter te worden en meer waarde te leveren aan klanten en stakeholders, moeten we de mogelijkheden benutten om te verbeteren. Dit is waar het bij continue verbetering uiteindelijk om draait: beter worden zodat je blijft voldoen aan de wensen van je klanten en stakeholders.
Zelforganisatie
Agile heeft ‘ingebouwde’ continue verbetering; het is een integraal onderdeel van de Agile-mindset en van de Agile-principes en -practices. Het begint met het Agile Manifesto, waarin staat:
We are uncovering better ways of developing software by doing it and helping others do it.
Dit manifesto legt de basis voor een agile mindset, waarin leren door te doen en voortdurend verbeteren (uncovering better ways) centraal staat. Agile is nooit ‘af’; we zullen nooit perfect worden in het ontwikkelen van software. Voor mij maakt het Agile Manifesto duidelijk dat continue verbetering essentieel is om een agile cultuur en organisatie te laten slagen.
Het twaalfde Agile-principe stelt:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Agileframeworks zoals Scrum schrijven niet voor hoe het werk gedaan moet worden. Van teams wordt verwacht dat ze zichzelf organiseren en hun eigen werk managen. Agile benadrukt dat teams regelmatig reflecteren en zichzelf aanpassen. Als er problemen zijn geweest, zullen ze onderzoeken wat er is gebeurd om manieren te vinden om soortgelijke problemen in de toekomst te voorkomen.
Een agile team maakt afspraken over de manier waarop de teamleden samen zullen werken om softwareproducten en services te kunnen leveren. Effectieve agile teams beslissen zelf hoe ze hun werk doen, leren hiervan en verbeteren hun werkwijze continu. Door mensen de vrijheid te geven om zelf te beslissen hoe ze hun werk zullen doen, voelen ze zich empowered.
Zelforganisatie geeft vrijheid aan teams. In dergelijke teams is de motivatie vaak hoog omdat mensen het gevoel hebben dat ze zelf de touwtjes in handen hebben. Het bereiken van het doel is wat telt voor het team en elk teamlid zal zijn of haar best doen om zo
veel mogelijk bij te dragen.
Agile Retrospectives
Retrospectives is een Agile-techniek die teams kunnen gebruiken om continu te verbeteren. In de retrospectieve bijeenkomst, georganiseerd aan het eind van de iteratie, kijken ze terug: wat ging er goed en wat kan beter? Vervolgens definiëren ze acties voor verbeteringen in de volgende iteratie.
De meeste agile teams gebruiken retrospectives als een middel om de tijd te nemen en na te denken over hun manier van werken. Ze definiëren en voeren verbeteracties uit om voortdurend beter te worden in wat ze doen. Mijn ervaring is dat variatie van de oefeningen in de retrospective en aanpassing van hoe de retrospective wordt uitgevoerd aan de gegeven situatie ervoor kunnen zorgen dat teams effectieve acties definiëren die leiden tot duurzame continue verbetering.
Een mooi voorbeeld is een team dat een userstory niet kon afmaken in de iteratie omdat de tester niet beschikbaar was. In de retrospective hebben we toen samen een root cause analysis gedaan, die aan het licht bracht dat het testwerk alleen door testers werd gedaan. Ontwikkelaars pakten geen testactiviteiten op omdat ze onzeker waren of ze dat werk wel konden doen.
Naar aanleiding van de retrospective besloot het team om meer pairing te gaan doen en ontwikkelaars en testers samen tests te laten uitvoeren. Het resultaat op langere termijn was dat ontwikkelaars userstory’s van andere ontwikkelaars gingen testen, waardoor het team flexibeler werd en meer userstory’s kon afwerken in de iteratie.
Een ander team dat ik coachte, was gewend om retrospectives met geeltjes te doen. Toen ze grote problemen hadden gehad in een iteratie en het team er helemaal doorheen zat, stelde ik voor om eens een een-woord-retrospective te proberen uit mijn boek Waardevolle Agile Retrospectives. Deze oefening hielp de teamleden om hun gevoelens te bespreken. Ze konden hun frustraties uiten en brachten begrip op voor elkaar. Er kwamen geen acties uit deze retrospective, maar hij was van vitaal belang voor het herstel van de goede samenwerking tussen de teamleden.
Continue Verbeteren met Agile
Naast retrospectives zijn er nog meer Agile practices die teams kunnen gebruiken om hun werkwijze continu te verbeteren. Zo hebben agile teams scrummasters die zich richten op het proces. Ze coachen teamleden bij het doen van hun werk en om manieren te vinden om daarin beter te worden. Scrummasters zijn altijd alert op dingen die gebeuren, ze signaleren potentiële problemen en helpen teams om ze aan te pakken voordat ze het werk te veel gaan verstoren.
Verder gebruiken agile teams veelal een Definition of Done (DOD). Hierin staan de werkzaamheden of stappen die noodzakelijk zijn om software te kunnen leveren. De DOD helpt teams om zichzelf te organiseren en af te stemmen hoe ze hun werk doen. Bij de teamvorming is het zinvol om te bespreken hoe de leden willen (samen)werken, en zo een eigen DOD te creëren.
Wanneer teams leren van fouten (of dingen die goed gaan) en ze besluiten om hun manier van werken aan te passen, dan is het vaak nodig om dat te verwerken in de DOD. Mijn advies is om de nieuwste versie van de DOD op te hangen in de ruimte waar het team werkt, zodat iedereen hem kan zien en er geen twijfel is over de te volgen werkwijze.
Feedback is van cruciaal belang voor continue verbetering. Waar Agile zich in eerste instantie richt op de interactie en samenwerking met klanten, gaat DevOps nog verder door de kloof tussen ontwikkeling en operations te dichten. Met DevOps krijgen ontwikkelaars bijvoorbeeld toegang tot de operationele data die inzicht geven in hoe klanten de softwaresystemen gebruiken. Deze gegevens helpen om problemen sneller aan te pakken, de software te optimaliseren voor de gebruikers en fouten te vinden en op te lossen voordat klanten ze rapporteren.
Opmerking: Dit artikel is eerder gepubliceerd in Bits&Chips nr 4. Bits&Chips publiceert een magazine over ontwikkelingen in de high-tech industrie en organiseert de jaarlijkse smart systems conferenties (Software-Centric Systems Conference in 2016).
