Betere Productkwaliteit met Agile

Steeds meer organisaties, zowel in het bedrijfsleven als bij de overheid kiezen voor een Agile manier van software ontwikkeling. De motivatie die je vaak hoort is dat ze daarmee beter aan kunnen sluiten bij de wensen van klant, en sneller oplossingen leveren. Ook verbetering van de kwaliteit m.b.v. Agile wordt genoemd als reden. Terecht of niet?

Agile is geen silver bullit voor kwaliteit. Er bestaat voor zover mij bekend geen specifieke Agile kwaliteitsaanpak, en Agile pretendeert ook niet dat het alle kwaliteitsproblemen kan oplossen.  Maar dat de agile werkwijze bijdraagt aan een hogere productkwaliteit wordt vaak genoemd. Laten we eens iets dieper duiken in Agile en Kwaliteit. Ik neem je mee met een reis in de tijd waar we terug gaan naar enkele klassieke kwaliteitsmethoden van de vorige eeuw, om te kijken wat hun zienswijze is op kwaliteit? Daarna gaan we terug naar de 21 eeuw, om te kijken of dat past bij bij Agile.

“Klassieke” Kwaliteitsmethoden

Ik heb in de loop van de jaren diverse kwaliteitsmethoden zien verschijnen, die het belang van kwaliteit duidelijk maakte, en aangeven hoe kwaliteit bereikt kan worden. Een eerste kennismaking met kwaliteit had ik door het bestuderen van Total Quality Management (TQM) van Deming. Het klonk mij (en klinkt nog steeds) heel logisch dat doelen duidelijk moeten zijn voor iedereen voordat je kwaliteit kunt bereiken. En ook een statement als  “drive out fear”,  waardoor je in een vroeger stadium kwaliteitsrisico’s onderkent heb ik meer dan eens bewezen gezien (helaas ook gezien wat er gebeurd als je het niet doet).  In de 80er jaren ontstond het Capability Maturity Model  (CMM), later opgevolgd door het Capability Maturity Model Integration (CMMI). Dit framework is voor mij common sense, een hele logische en praktische manier om aan kwaliteit te werken, wat zich in de loop van jaren (mits op verantwoorde manier toegepast) meermaals bewezen heeft. Met al deze kwaliteitsbagage kom je in de 21e eeuw aanraking met Agile, wat voor mij een hele natuurlijke manier van (samen)werken is. En, iets wat teams aanspreekt, en dat kun je van een TQM of CMMI niet altijd zeggen. Aangezien ik overtuigd ben dat kwaliteit op de “werkvloer” gemaakt wordt, was ik meteen verknocht aan Agile.  De vraag die dan opkomt is in hoeverre de “klassieke” kwaliteitsmethodieken nog steeds bruikbaar zijn als je Agile werkt?

Laten we deze vraag eens van 2 kanten bekijken? Allereerst zijn er de Agile principes, vastgelegd in het Agile Manifesto. In hoeverre ondersteunen deze principes de klassieke ideeën over kwaliteit van producten? Ofwel, zijn de klassieke methoden bruikbaar binnen de Agile principes? Ten tweede leggen de klassieke methoden veel nadruk op controle van de kwaliteit. De vraag is in hoeverre dit conflicterend is met de Agile principes?

Agile Kwaliteit

Agile methodieken baseren zich op principes die interactie tussen medewerkers, samenwerking met de klant/opdrachtgever, en omgaan met verandering belangrijk vinden voor het te leveren resultaat. Dit moet resulteren in een betere kwaliteit. De kwaliteitsmechanismen van goeroes zoals Crosby, Juran en Deming zijn dan nog steeds bruikbaar, en soms juiste effectiever binnen een Agile omgeving. Bv. “kwaliteit is voldoen aan de eisen” (Crosby): Agile gebruikt de planningsgame om de eisen af te stemmen met de opdrachtgever, en voor het gehele team inzichtelijk te krijgen. De kans dat daarmee software opgeleverd wordt die aan de eisen voldoet wordt aanzienlijk vergroot. De Quality Trilogy van Juran, “Planning, Control and Improvement” zie je terug in de korte cycli van Scrum. Aan het begin is er de Planning game (plan), en de Defnition of Done (proces), waardoor het team duidelijkheid creëert wat er geleverd gaat worden en hoe dat gedaan wordt. Aan het eind van de iteratie is er de feedback op het product (de demo) en op de manier van werken (de retrospective).  Verbeteringen worden meegenomen in de volgende iteratie, middels de planning game en/of door het aanpassen van de Definition of Done. Idem voor de Plan Do Check Act (PDCA) cyclus, die je in Agile juist veel frequenter en dus effectiever uitvoert. En last but not least, veel van de principes uit Total Quality Management zijn een integraal deel van het Agile denken, zoals continue verbeteren, training, en het afbreken van muren tussen functies door multidisciplinair samenwerken in teams.

Agile en CMMI

Dat CMMI en Agile elkaar kunnen helpen is al langer bekend. Om dit nogmaals te onderstrepen is in de laatste versie van het CMMI uit 2010 (CMMI V1.3) de ondersteuning voor Agile verder uitgebreid en explicieter beschreven. In de procesgebieden worden de Agile practices benoemd, zodat het voor een assessor eenvoudiger is om ze te herkennen en een Agile organisatie te certificeren. Ook de integratie van Integrated Product and Process Development in de procesgebieden is een verbetering, de doelen en activiteiten zijn duidelijker, sluiten aan bij de doelen van de procesgebieden en daardoor beter toepasbaar. Dit ondersteund het werken in teams, wat in Agile een belangrijk mechanisme is. Kortom, de CMMI V1.3 versie help organisaties die Agile (gaan) werken om meer uit het CMMI te halen om Agile procesverbetering toe te passen, en de performance van Agile organisaties te verbeteren.

Bij Agile ligt de nadruk op samenwerking, men gaat uit van de wil van alle partijen om tot goede resultaten te komen. Dat kan conficteren met “controleren” wat een aanpak is die je veel ziet in de klassieke kwaliteitsmethodes. Denk daarbij b.v. aan kwaliteitsdoelen en rapportages en audit, en ook het testen van producten. We weten allemaal dat je de kwaliteit van een product er niet in kunt “controleren”. Van de controles, zoals bv. met milestone checks, reviews en testen wordt een product niet direct beter. Een controle geeft wel signalen, maar enkel als op die signalen geacteerd wordt dan wordt het product of de dienst beter. Het gaat om een balans tussen controleren, en het nemen van actie. Stel dat er minder controles zijn, maar het resultaat van de controles is wel beter bruikbaar en daardoor worden er meer en tijdige acties ondernomen. Dan zou de kwaliteit beter worden, en ook de kosten omlaag gaan. Agile levert, door het kortcyclisch werken en de frequente feedback volop informatie over de kwaliteit van de producten. Deze informatie wordt gebruikt om de producten te verbeteren (Demo -> Planning game) of om effectiever samen te werken (Retrospective -> Definition of Done). Daarme word de kwaliteit daadwerkelijk verbeterd, gebruik makend van klassieke kwaliteitsmethoden, maar dan wel toegepast om professionals te ondersteunen in het leveren van kwaliteit.

Conclusie

Kwaliteitszorg bij Agile richt zich op het continue verbeteren van de samenwerking in de teams en van de teams met hun opdrachtgevers en klanten, wat resulteert in betere producten. De klassieke kwaliteitsmethoden sluiten hierbij aan en helpen met hun denkwijzen om kwaliteit te implementeren en te verbeteren, zeker ook in een Agile omgeving.  Kortom, de waarde van oude kwaliteitsmethoden herleeft in Agile: Jazeker, de oudjes doen het nog goed! 

Dit artikel is eerder gepubliceerd op Agile Overheid, een kennisplatform voor Agile EN Overheid met als doel ICT projecten binnen de overheid succesvoller te laten zijn.

  • Agile is Not a Silver Bullet (nofluffjuststuff.com)

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

×
×

Cart