Kwaliteitsproducten en -diensten met Scrum
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.
- 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 :)
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.
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.
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'.
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.
"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.
De product owner heeft veel meer mogelijkheden om te sturen met Scrum: iedere sprint. Dat is veel effectiever dan requirement specificaties en change requests. Moet de product owner dat uiteraard wel benutten, waar ik dat heb zien gebeuren werden projecten inderdaad succesvoller met Scrum.
Uiteindelijk gaat het daarom.
Niet 'gek' doen, maar met de (big) chief meedenken.
Kunnen we hard maken dat agile deze kwaliteitswinst levert? In cijfers blijkt dat lastig, je weet niet of er met een waterval project ook een juiste product uitgekomen zou zijn (alhoewel er volop horror stories zijn waar het met waterval mis is gegaan). Maar agile past bij "no cure - no pay", al na enkele sprints heb je producten die waarde hebben, en heb je een return on investment. Als dat niet zo is, dan lijkt me dat iets om samen als business en IT eens heel kritisch te onderzoeken (retrospective?), en actie te ondernemen!
Agile is niet bedoeld om 'later recht te breien', maar om bij nieuwe kennis (feedback!) en groeiend inzicht (ervaring!) betere beslissingen te nemen, en bij te sturen waar nodig. Niet je kop in het zand steken aan het begin, maar wel reeël zijn en beseffen dat je gewoon niet alles kunt weten als je start.
24-05 Profiteer van virtualisatie in hybride omgeving
24-05 Laat je niet overvallen door BYOD
24-05 Cloudintegratie is een ware uitdaging
23-05 Van 3D-film naar 3D-document
23-05 Gevaren van silostorage kun je ondervangen met SSD
22-05 Documenten dubbel zien in de cloud
22-05 Denk in diensten en niet in uren maal tarief
21-05 Beveilig je site tegen DDoS-aanval
21-05 Maak je proces mobiel met een app
17-05 De Red Diesel Blues
24-05 ISProjects helpt Daelmans Banket met facturen
23-05 Opiniebijdragen voor Computable
23-05 Nederland houdt voorsprong in UCC-technologie
23-05 Computable zoekt testers voor HP ElitePad
22-05 ITPH organiseert regionale IT-branchedag...
17-05 Hans Wanders, Randstad
17-05 Luc Verbist, De Persgroep
17-05 Marcel Krom, PostNL
17-05 Robbert-Jan Stegeman, Alliander
17-05 Friso van den Berg, Leger des Heils
|
|
In vijf stappen een brug slaan tussen IT en business
![]() |
Van een informatiemanager wordt verwacht dat hij of zij optimaal inspeelt op de wensen van de business. Dat vereist......
Prominent Comfort Producten B.V. , Nunspeet
Davinci Products , Amsterdam Zuidoost
United Retail B.V. , Nijkerk GD
Michael Page IT , Volendam
Universiteit Leiden , Leiden


