Steeds meer organisaties passen Agile toe om softwareproducten en -diensten te ontwikkelen. Redenen die genoemd worden om Scrum te gebruiken zijn: flexibel inspelen op wensen van de klant, sneller ontwikkelen, en hogere software kwaliteit. Over flexibiliteit en snelheid is al veel geschreven, dit artikel vertelt wat Scrum voor de kwaliteit van producten en diensten kan doen en beschrijft de Agile kwaliteitstechnieken die daarbij gebruikt worden.
Even vooraf: Agile is geen silver bullit voor kwaliteit, er bestaat geen specifieke Agile kwaliteitsaanpak en Agile pretendeert ook niet dat het alle kwaliteitsproblemen kan oplossen. Maar een Agile werkwijze, bijvoorbeeld met Scrum kan zeker bijdragen aan een hogere kwaliteit. Laten we eens kijken hoe dat dat mogelijk is.
Wat is Kwaliteit?
Om te beginnen, mijn definitie van kwaliteit: Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide. De gebruikers zijn diegenen die met het product of dienst iets doen en er voordeel aan hebben. De opdrachtgever is de eindverantwoordelijke die beslist heeft dat het product of de dienst ontwikkelt moest worden en die de middelen (geld, mensen, etc) beschikbaar heeft gesteld.
Met bovenstaande definitie wordt de kwaliteit van een softwareproduct of -dienst dus duidelijk bepaald door de gebruikers en opdrachtgevers, en niet door het Scrum team. Scrum teams kunnen m.i. alleen kwaliteit leveren als ze de behoeften van de gebruikers kennen en een daarbij passende oplossing leveren.
Agile waarden
Het belang van kwaliteit wordt door de waarden waar Agile op gebaseerd is onderstreept. Het agile manifest beschrijft de waarden:
Manifest voor Agile Software Ontwikkeling
‘Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we
Mensen en hun onderlinge interactie boven processen and tools
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan
Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.’
Mijn mening is dat de Agile waarden de levering van kwaliteitssoftware ondersteunen. Bijvoorbeeld door ‘werkende software boven allesomvattende documentatie’, wat het belang aangeeft van het leveren van producten aan gebruikers. Agile moedigt aan om vroeg en vaak te leveren, waardoor gebruikers de software kunnen gaan gebruiken en die voor hun waarde oplevert, kwaliteit dus. Ook ‘inspelen op verandering boven het volgen van een plan’ resulteert in hogere kwaliteit omdat het Agile-teams aanmoedigt om software aan te passen die niet aan de behoeften van de gebruiker voldoet.
Vaker en tijdiger actie ondernemen
Agile verschilt met ’traditionele’ kwaliteitssystemen die de nadruk leggen op het borgen van de kwaliteit met documenten. Die systemen hanteren veelal een waterval aanpak met milestones waarop documenten formeel geïnspecteerd en goedgekeurd moeten worden. Ze kennen kwaliteitsdoelen, rapportages en audits, en geven veel aandacht aan het testen van producten. Maar de kwaliteit van een product kun je er niet in ‘controleren’. Van milestone checks, reviews en testen wordt het niet beter. Een controle geeft signalen, maar pas als je met die signalen wat doet dan wordt het product of de dienst beter. Het gaat om een balans tussen controleren en het nemen van actie en daar gaat het vaak mis.
Projectteams komen om in de grote hoeveelheid fouten die gevonden zijn en kunnen maar een deel ervan oplossen. De diepere oorzaken van de fouten zijn onbekend en daar wordt niets aan gedaan, waardoor er steeds nieuwe fouten bijkomen. Kwaliteitssystemen die voornamelijk gebaseerd zijn op controleren blijken vaak niet de gewenste kwaliteit op te leveren, of doen dat tegen zulke hoge kosten dat ze in de praktijk niet uitvoerbaar zijn.
Een Agile-aanpak gaat uit van minder controleren en van beter gebruiken van de resultaten van de controles door vaker en tijdiger acties te ondernemen. En van leren van fouten en de manier van werken (het proces) te veranderen. Daarmee wordt de kwaliteit beter en gaan de kosten omlaag. Scrum levert, door het kortcyclisch werken in sprint en de frequente feedback, volop informatie over de kwaliteit van de producten. Deze informatie wordt gebruikt om de producten te verbeteren (Sprint Review / Demo -> Planning Game) of om effectiever samen te werken (Sprint Retrospective -> Definition of Done). Op die manier wordt continu het product en de manier van werken verbeterd.
Samenwerken met gebruikers
Samenwerking met de gebruikers van de software is essentieel als je wilt begrijpen welke kwaliteit nodig is. Bij het plannen en ook tijdens de ontwikkeling werken de eigenaar van het product en het Scrum-team nauw samen om zo de vereisten te kunnen definiëren en te bepalen wat prioriteit heeft, door gebruik te maken van gebruikersverhalen (User Stories).
Het begint al met de planningsgame, waarin het team en de Product Owner (die de gebruikers vertegenwoordigt) afstemmen wat de gebruiker van de volgende sprint mag verwachten. Telkens opnieuw wordt gekeken wat de hoogste prioriteit heeft, om ervoor te zorgen dat de juiste dingen gemaakt worden waar de gebruikers wat aan hebben. In de dagelijkse stand-up bespreken de teams hun voortgang en benoemen dingen die mogelijk de levering kunnen bemoeilijken. Aan het einde van de sprint is er de product review waarin met de gebruikers bekeken wordt of het product voldoet. Die product review geeft veel bruikbare feedback, die meegenomen wordt in de plannings game van de volgende sprint.
Samenwerken met korte communicatielijnen is een sterkte van Scrum, die helpt om de kwaliteit te verhogen. Ontwikkelaars hebben een beter inzicht wat gebruikers willen en waarom. Gebruikers zien het product in een vroeg stadium, en kunnen het ook eerder gaan gebruiken. Een duidelijke win-win!
Agile kwaliteitstechnieken
Omdat de Agile-waarden kwaliteit onderstrepen en de Scrum-teams intensief samenwerken met de gebruikers, is het geen verrassing dat veel Scrum-teams software van hoge kwaliteit leveren. Maar hoe doen ze het, welke technieken gebruiken ze?
Een voorbeeld is ‘pair Programming’, waarbij twee ontwikkelaars samen een keyboard en scherm delen. De ene ontwikkelaar typt terwijl de ander de code leest en mogelijke problemen aankaart en daar verbeteringen voorstelt. Bij pair programming wordt de code nagekeken terwijl hij geschreven wordt, waardoor er snel feedback wordt gegeven aan de ontwikkelaar en fouten voorkomen worden. Bijkomend voordeel is dat meerdere ontwikkelaars de code leren, waardoor men minder afhankelijk is van individuele teamleden.
Een andere manier die de kwaliteit van producten verhoogt is Test Driven Design (TDD). Als eerst de test geschreven wordt en daarna pas de code, dan weet je door het uitvoeren van de test dat de software werkt. Tests worden toegevoegd aan de regressietest, die het team tijdens de ontwikkelingsfase gebruikt om te controleren dat de software correct blijft werken.
‘Refactoring’ past bestaande code aan, waarbij het product hetzelfde blijft werken. Het kan gebruikt worden om de prestatie van een product te vergroten of om het voor te bereiden zodat een nieuwe functionaliteit toegevoegd kan worden. Teamleden ontwikkelen hun ‘refactoring’ vaardigheden, zodat zij de code efficiënt kunnen aanpassen en tegelijkertijd de kwaliteit van het softwareproduct kunnen waarborgen. Om er zeker van te zijn dat het product correct blijft werken worden regressietesten gedaan, TDD en refactoring worden op die manier gecombineerd.
Scrum-teams verbeteren hun manier van werken constant door te werken met retrospectives. Door te reflecteren na een sprint kan het team zien welke dingen goed gingen en welke beter kunnen en ze evalueren ook wat ze geleerd hebben. Agile vindt verbetering erg belangrijk en teams leren constant om beter te worden in wat ze doen, waardoor zowel hun effectiviteit als efficiency vergroot worden.
Conclusie
Scrum-teams worden gedreven door de Agile-waarden die kwaliteit ondersteunen. Door frequente feedback nemen Scrum-teams vaker en tijdiger actie om de kwaliteit te verbeteren. Ze werken nauw samen met de gebruikers van de software en gebruiken kwaliteitstechnieken om softwareproducten en diensten van hoge kwaliteit te leveren.
Scrum: sneller ontwikkelen en een hogere software kwaliteit. Het is informatief om te lezen over Agile waarden, vaker en tijdiger (nb als iets tijdig is, hoe kan het dan nog tijdiger?) actie ondernemen, samenwerken met gebruikers etc. Maar wat levert Agile/Scrum nu echt op ? Wat is het nuttig effect op het aantal uren/functiepunt en wat is het effect op de projectduur vergeleken met gelijksoortige projecten in het verleden?
@Cees: Mijn ervaring met Agile software ontwikkeling zijn:
– meer betrokkenheid van de eindgebruikers (worden regulier uitgenodigd om de voortgang te tonen, goed in het kader van verwachtings- en veranderingsmanagement).
– problemen/fouten worden sneller gevonden (en kunnen dus ook sneller opgelost worden, kosten omlaag en kwaliteit omhoog)
– ontwikkelteam hoort uit eerste hand wat de klant wenst en kan ook sneller met de klant om de tafel over (on)mogelijkheden en alternatieven
– risico wordt verkleind (de klant wordt niet aan het eind geconfronteerd met het product)
– projectmanagement eenvoudiger (voortgang veel beter meetbaar)
– invloed klant vergroot (klant kan aan het eind van een sprint de prioriteit bijstellen en continu functionaliteit toevoegen)
Zo maar wat redenen die Agile software ontwikkeling bijzonder veel toegevoegde waarde geeft. Wel moet ik erbij vermelden dat ik dit vanuit een ontwikkelaarsperspectief geschreven heb 🙂
@Cees Dit artikel gaat juist niet over hoeveel sneller en efficienter Agile/Scrum is (daar schrijven anderen over), maar over de kwaliteitsverbetering met Scrum. Eerder op Computable is wel een boek besproken wat over de business case van Agile gaat, zie https://www.computable.nl/artikel/nieuws/detachering/4569590/3484209/lezers-lezen-agile-werkt.html.
Mbt kwaliteit en Agile, ik heb onderzoek gedaan samen met het Software Engineering Institute (SEI). Zie http://www.benlinders.com/2011/lean-software-ontwikkeling-introductie-en-verminderen-van-verspillingen/. Het onderzoeksrapport laat zien dat de kwaliteitswinst beperkt was. Maar wat wel een groot voordeel was, is dat het juiste product gemaakt werd: Dat wat de klant nodig had! En dat sluit aan op mijn definitie van kwaliteit, een product wat beter voldoet aan de wensen van de klant.
Leuk artikel waar ik op maar een paar elementen niet mee eens ben. Zo is de kwaliteit voor mij de bijdrage aan het doel van de opdrachtgever. Dus bv de omzetgroei. Daarvoor moeten gebruikers hun doel kunnen vervullen, ze leveren (misschien ongemerkt) een belangrijke bijdrage aan het uiteindelijke resultaat.
Verder zie ik wederom dezelfde foute manier van eindgebruikers betrekken > quote ‘product review waarin met de gebruikers bekeken wordt’ Maar ook de goede > quote ‘kunnen het ook eerder gaan gebruiken’.
Ik pleit ervoor om gebruikers echt te laten werken met de deeloplevering zodat je echt de gebruiksvriendelijkheid en begrijpelijkheid kunt testen. Neem een gebruiker, zet hem achter het scherm en vraag hem wat te doen. Heel leerzaam.
Als aanvulling op het artikel kan ik aangeven dat wij tegenwoordig bij nieuwe diensten/producten vaak in sprint 1 een ontwerp maken en testen adhv een simulatie. In sprint 2 wordt dan het product ontwikkeld. Zo weet je heel zeker dat het gaat werken wat je ontwikkelt en je krijg optimale performance van de developers omdat ze niet hoeven te wachten op businessbeslissingen etc.
@Marcel Ben het met je eens dat je de gebruikers zo vaak en intensief als mogelijk is bij de ontwikkeling moet betrekken, des te eerder en beter de feedback die je van hun krijgt. En dat helpt een team om betere kwaliteit te leveren.
Ik heb agile teams gezien die dagelijks met de product owner stukjes van het product bekijken, en het laten accepteren. Heel effectief! En teams die juist de demo benutten voor een brede exposure in het bedrijf. Voor mij is er geen foute of goede manier, het zal afhangen van de situatie wat werkt.
Je oplossing om in sprint 1 een ontwerp en test te doen, en in sprint 2 het product te ontwikkelen kan een prima aanpak zijn of risico’s aan te pakken, en beslissingen voor elkaar te krijgen. Is dat dan ook de klantwaarde van de 1e sprint? Je levert in sprint 1 dan nog geen ‘werkende software’.
Ik vind dit een zeer informatief artikel maar…. soms heb ik dat wel eens … telkens als ik dit soort artikelen lees, dan heb ik het idee/gevoel ‘oude wijn/nieuwe zakken. Met alle Respect, uiteraard.
Wat ik namelijk in veel artikelen mis is namelijk materie kennis. Materie kennis in de zin wat IT als materie is, hoe het zich beweegt, aan welke wetmatigheden die onderhevig is …. minor detail, een kleinigheidje heb je al gauw.
De reden dat ik dit regelmatig naar voren breng is namelijk dat veel IT specialisten, en nog veel meer Non IT- ers, nu eenmaal met die wetmatigheden te maken krijgen en daar zo vaak tegen in gaan. De gevolgen laten zich telkens raden. Van een simpel incidentje tot gevolgen a la KPN vs een hacker of een Vodafone brand en de gevolgen daarvan.
Scrum ontbeert ook dat onderdeel en inzicht. Als je namelijk je even heel sec en eenvoudig richt op de werking van de materie end e wetmatigheden, en die informatie deelt met je klanten, dat je dan plots met zeer eenvoudige methoden toe kan i.p.v. weer een ‘nieuwere’ methode je aan moeten leren.
Gewoon even mijn bescheiden gedachte hier over.
In de basis zorgt dus de communicatie tussen business en ontwikkelteam ervoor dat de kwaliteit goed wordt. Dan kan dus ook in een niet Agile omgeving. Het gaat tenslotte om de communicatie. Dat is de oplossing die ook werkt als je waterval o.i.d. gebruikt.
@Ben: Dank voor jouw reactie. Even citaat uit de boekbespreking:
“Ronduit tegenvallend is het onderzoek. Het probleem zit ‘m vooral in de basis. Huijgens heeft slechts twee organisaties onderzocht. Weliswaar 278 projecten waarvan 29 Agile. Helaas is een groot deel van deze projecten beperkt van omvang en doorlooptijd”
Ik zie in mijn eigen omgeving ook vaak organisaties die naar SCRUM grijpen voor releasematig onderhoud. Vooraf onderhoudsvensters afstemmen, kleine partjes per keer. Die techniek hadden we met z’n allen al jaren gelden bedacht en nu noemen we het Agile. Ik zie wel positieve ontwikkelingen in kleinschalige projecten met modeldriven tools als Mendix en Outsystems. Maar ook daar gaat het meestal om kleine trajecten.
Nu ben ik zelf ook een groot voorstander van kleine beheersbare projecten. Maar dan zijn we weer bij af. Kijk maar naar FPA statistieken van NESMA. Zodra een project de 1000 funtiepunten passeert gaan doorlooptijd, uren, kosten met sprongen omhoog.
Ik hou het erop, dat zolang we project size laag kunnen houden, is de boel beheersbaar. Dat hadden we vroeger met het prototypen ook al bedacht. Agile/Scrum: Oude wijn in nieuwe zakken, goed voor de commercie.
@NumoQuest en @itk_08348 Agile en ook Scrum is deels inderdaad oude wijn in nieuwe zakken, eens. Als je teruggaat naar bv EVO van Tom Gilb dan zie je al hoe belangrijk het continu leveren van waarde is, feedback van de klant. Scrum is een bruikbare verpakking. En ja, communicatie en samenwerken zijn en blijven cruciaal.
@CK Als je frequent en veel communiceert in waterval projecten, dan gaat de kwaliteit inderdaad ook omhoog. Maar als je met die communicatie actie onderneemt, dwz product bijstellen, betere werkwijze, dan krijg je al snel een iteratieve manier van werken. Wordt je vanzelf een beetje Agile…