Development

Software-ontwikkeling

Agile is geen haastwerk

22 januari 2015

Veel organisaties stappen over op agile werken om sneller te kunnen reageren op veranderingen in de markt of wijzigende vragen van klanten. Maar is sneller altijd beter? Een sterke focus op functionaliteit op de korte termijn, leidt in de praktijk al snel tot kwaliteitsproblemen op de langere termijn. Daarnaast krijgen de zelforganiserende teams alle vrijheid om zelf beslissingen te nemen die grote impact kunnen hebben op kwaliteitsaspecten – nu en in de toekomst. Als we goed kijken naar veel gestelde vragen over agile en kwaliteit dan zien we doorgaans twee dingen. Enerzijds dat de combinatie van agile werken en kwaliteit nog niet goed begrepen wordt. Anderzijds zien we inderdaad een categorie reële gevaren voor de praktijk.

Constante kwaliteit

De klassieke benadering van kwaliteit in software kenmerkt zich door een uitgebreide testfase. Het product is pas af als het uitgebreid getest is en alle gevonden fouten zijn verwijderd. Doordat het product pas ‘af’ is aan het einde, vinden het testen en de kwaliteitsverhoging plaats aan het einde. Vandaar ook dat het noodzakelijk is de ‘scope’ te bevriezen. Veranderingen in de scope leiden namelijk tot extra werk waardoor testactiviteiten in het gedrang komen – met nadelige gevolgen voor kwaliteit. Daarnaast wordt kwaliteit in de klassieke benadering bewerkstelligd door processen en richtlijnen. De verwachting is namelijk dat een goed proces een randvoorwaarde is voor een goed product (zie AutomatiseringGids 15 juli 2014: ‘CMMI is dood, problemen zijn springlevend’).

Agile werken is gebaseerd op een totaal andere benadering. Feitelijk dwingt agile werken af om kwaliteit te leveren (zie kader). Agile werken vraagt om telkens het product af te maken. Afmaken betekent: werkend én getest. In de praktijk betekent dat dus dat teams elke ‘sprint’ een product hebben dat leverbaar is. Kwaliteit vanaf het allereerste moment. Dus niet pas aan het einde testen, maar vanaf het begin al. Hoe eerder je fouten ontdekt, hoe meer tijd je krijgt om ze goed op te lossen.

Agile vereist dat het product op elk moment in de tijd het kwaliteitsniveau heeft om uitgeleverd te worden. Om de kwaliteit constant te toetsen worden testen daarom zo veel mogelijk geautomatiseerd. Een testfase aan het eind is daardoor overbodig geworden, want kwaliteit is er op elk moment in de tijd. Daarnaast is er minder noodzaak voor uitgebreide procesbeschrijvingen en richtlijnen. De nadruk ligt bij agile namelijk veel meer op samenwerking en kennisuitwisseling tussen mensen, in plaats van op procedures en richtlijnen. Ontwikkelaars stellen bijvoorbeeld samen met de testers eerst alle testgevallen op voordat de aanpassingen in het product worden gemaakt. En dit wordt gezamenlijk gedaan in een team van testers en ontwikkelaars. Samenwerken in plaats van over de schutting gooien. Hierdoor is het leerproces om kwaliteit te leveren binnen een team belegd en is er geen noodzaak meer dat via overdracht naar testteams of via procedures en documenten te organiseren.

Gevaren

Maar het is niet alles goud wat er blinkt. In de praktijk zien we dat veel organisaties niet vanaf dag één begrijpen wat agile werken betekent. Het effect is dat agile maar half wordt opgepakt en dat leidt dan weer wél tot slechte kwaliteit. Een voorbeeld hiervan is een organisatie waar directe sturing vanuit de business plaatsvindt. Een product owner met een primaire blik op kortetermijnfunctionaliteit verliest dan het zicht op kwaliteit van het geheel. Vooral in organisaties met weinig kennis en ervaring met agile werken is dat aanwezig. Teams hebben dan nog onvoldoende inzicht in hun risico’s en pakken vaak ook nog niet zelf de verantwoordelijkheid om kwaliteit te leveren. Een goed en gelijkwaardig gesprek over risico’s en kwaliteit vraagt om mondige ontwikkelteams en om product owners die verantwoordelijkheid nemen voor kwaliteit op korte én lange termijn (zie AutomatiseringGids 21 oktober 2014: ‘De dode hoek van Scrum’).

Een ander voorbeeld dat we helaas nog regelmatig in de praktijk tegenkomen is het scheiden van ontwikkeling en beheer. Het team dat het product maakt, is een ander team dan het team dat het onderhoud doet. Gevolg is dan dat een ontwikkelteam het halen van planningen als belangrijker ervaart dan het leveren van kwaliteit. Onvoldoende kwaliteit wordt immers opgevangen door de onderhoudsafdeling. Dit is onwenselijk. Een team moet verantwoordelijk zijn voor alle kwaliteit, nu maar ook voor de toekomst. Voorkomen van kortetermijndenken doe je door alles in hetzelfde team te beleggen: ontwikkeling, beheer én onderhoud. De praktijk is op dit punt helaas vaak nogal weerbarstig met alle negatieve gevolgen voor kwaliteit.

De essentie van agile werken is niet zoveel mogelijk werk in een korte iteratie proppen. Agile is niet quick & dirty. Geen haastwerk dus. De kunst zit in het slim doorvoeren van aanpassingen die maximale waarde opleveren en in het minimaliseren van risico’s door de aanpassingen zo klein en simpel mogelijk te houden en volledig geautomatiseerd te testen. Altijd aangetoonde kwaliteit dus. Niet aan het einde, maar vanaf het allereerste moment.

Zeven redenen waarom agile werken kwaliteit afdwingt

  1. Ritme en regelmaat
    Agile zorgt voor een vast, terugkerend en visueel proces dat elke sprint wordt herhaald. Herhaling zorgt voor ritme en brengt een stabiel tempo. Dit verkleint de kans om onder druk slechte kwaliteit te leveren. Teams weten precies wat ze moeten doen om een product op te leveren. En de teams leren wat de hoeveelheid werk is die ze aankunnen zonder concessies te doen aan kwaliteit.
  2. Kwaliteit is expliciet en staat vast
    Agile dwingt om zaken af te maken. Aan het eind van elke sprint is het product namelijk klaar: werkend én getest. Testen is niet een slotactiviteit die onder druk komt te staan, maar krijgt al alle aandacht die het verdient. Kwaliteit vanaf het allereerste begin. Dit wordt expliciet gemaakt in de Definition-of-Done: het is pas klaar als het aan alle acceptatiecriteria voldoet: elke iteratie opnieuw. Daardoor doen teams juist minder concessies aan kwaliteit, zij doen concessies aan de scope.
  3. Continu leerproces
    Korte iteraties zorgen ervoor dat je sneller leert en deze ervaringen direct in de praktijk kunt brengen. Constante aandacht door regelmatige retrospectives zorgen voor procesverbetering vanaf het begin, zodat leerervaringen direct worden omgezet in acties. Teams leren daarnaast ook waarom bepaalde functionaliteit gewenst is of juist niet. Eerder leren wat de klant nu écht nodig heeft en waarom.
  4. Waarde als stuurinstrument
    Agile helpt om direct waarde te leveren én te toetsen. Er wordt constant gestuurd en bijgestuurd op de vraag: maken we wel de juiste dingen? Agile dwingt om nauw samen te werken met de klant en continu zijn feedback te vragen. Requirements worden ‘vers’ besproken met betrokkenen. Er wordt alleen gekeken naar de benodigde details voor de komende sprints, en niet naar details voor werk dat nog lang niet aan de beurt is. Teams leren ontdekken waar de échte waarde zit. Liefst door minder software te maken, want hoe minder software hoe minder te testen en te onderhouden, dus hoe groter de kans op kwaliteit.
  5. Geen grote projecten meer
    Agile dwingt om grote dingen op te knippen in kleine. Grote projecten gaan altijd mis. Changes zijn veel kleiner, het risico is daardoor ook kleiner. Teams hebben focus en werken maar aan een beperkt aantal dingen en maken dat écht af. Hierdoor verkleint de kans dat ontwikkelaars elkaar dwars zitten en dat ingewikkelde combinaties van changes leiden tot moeilijk vindbare defects.
  6. Automatisering van kwaliteit
    De businesscase voor testautomatisering is vele malen beter/sterker bij agile. Immers, integrale keten- en regressietesten worden veel vaker gedaan, namelijk elke sprint. Continu geautomatiseerde toetsing van kwaliteit is daardoor haalbaar en ook financieel interessant. Dit is overigens niet het enige herhaalbare werk dat veel beter geautomatiseerd kan worden. Onder het label van Continuous delivery wordt het hele OTAP-proces van ontwikkeling tot en met het in productie nemen geautomatiseerd. Dit legt de focus op vakmanschap, want de rest wordt geautomatiseerd.
  7. Autonome teams
    Agile dwingt om in cross-functionele zelfverantwoordelijke teams te werken. Disciplines zitten dicht op elkaar. Kwaliteitsverantwoordelijkheid ligt in het team. Normaal zit hier afstand tussen, waardoor er minder verantwoordelijkheidsgevoel is en veel kennisverlies ontstaat in de overdracht. Nu hebben teams een gezamenlijke verantwoordelijkheid tot en met productie. Als je zelf ’s nachts wakker gebeld kunt worden omdat de kwaliteit onvoldoende is, dan is een bochtje afsnijden opeens een stuk minder interessant.
 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!