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.
@Ben Linders Daarom begrijp ik die giga omslagen bij die grote partijen niet. Ineens moet alles Agile. Let op: ik ben niet tegen Agile. Wel tegen kortzichtigheid.
@CK Herken het. Ook ik ben voorstander van stapsgewijs en continu veranderen, ook als je Agile en/of Lean gaat toepassen. Wel met doel in het vizier maar flexibel in de reis er naar toe. Top down voorwaarden scheppen, en bottom up verbeteren. Agile en opleggen, iets zegt me dat je self steering teams niet kunt afdwingen 😉
Ja, jullie berichten begrijp ik allemaal, maar mijn vraag is: where is the money.
Uiteindelijk gaat het daarom.
Niet ‘gek’ doen, maar met de (big) chief meedenken.
Aanvulling, zou je zo maar beter van kunnen worden.
@Ben Linders Helemaal mee eens. Maar naast dit issue speelt er naar mijn mening nog een issue. Namelijk dat men Agile als excuus gebruikt. Een “gedegen” fase om specs duidelijk te krijgen is minder van belang als je weet dat je dit in de toekomst toch nog recht kan en mag breien. Een dergelijke instelling zorgt voor extra tijd en kosten. Is hier wel eens naar gekeken?
@Jurgen Hele valide opmerking, wat levert agile op vanuit kwaliteitsperspectief? De kwaliteitswinst die ik zie voor bedrijven is dat het juiste product gemaakt wordt, dat wat de klant nodig heeft, en waar hij/zij dus ook geld aan uit wil geven omdat het voor hem/haar waarde heeft. En dat komt juist door de samenwerking tussen ontwikkelteams en de klant, en het continue bijsturen.
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!
@ck jazeker! Er zijn agile frameworks, zoals Disciplined Agile Delivery die ingaan op hoe je specificeren en architectuur inpast in Agile. Real options, wat ingaat op hoe je mogelijkheden open kunt houden, maar wel beslissingen neemt. Er is volop aandacht voor technical debt en refactoring. Geen eenvoudige materie, maar wel iets waar zeker voor agile in grotere organisaties / enterprises heel belangrijk is.
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.
Oude wijn in nieuwe zakken zit ik hier te lezen. Klinkt een beetje negatief maar het is positief uit te leggen denk ik. Niet alleen door puir over kwaliteit te praten maar in zekere zin is Agile de nieuwe uitleg van wat al jarenlang “gezond verstand” heet. Agile breekt een groot en complex geheel op in kleine brokjes en die pak je stuk voor stuk aan. Eenvoud en overzicht. Ik vergelijk het vaak met een mooie gebeurtenis uit 1969. Toen zijn drie mannen in witte pakken weggeschoten vanaf een lanceerplaats, in een raket richting de maan. Ze vlogen weg, reisden door de ruimte en ze landden ook daadwerkelijk…. op de maan! Eén stapt eruit en maakt een wandeling. De tweede stapt uit en loopt ook een rondje. De derde bleef binnen (en dat terwijl hij daar waarschijnlijk nooit meer terugkomt, maar dat terzijde). Op een mooie dag stijgen ze weer op, reizen door de ruimte en landen weer op de meter nauwkeurig op de plek die al lang van tevoren was berekend. En dat in een tijd waarin Prince II nog niet bestond, computers super langzaam waren, er gerekend werd met slechts 2 cijfers achter de komma met slechts een paar K geheugen en…… geen Agile. Althans, dat denken we! Maar zoals ik al zei, Agile brengt ons weer terug bij gezond verstand. Zo kwamen we op de maan en zo lossen we tegenwoordig een goed deel van de IT-projecten op. En als je Agile leest, het IS gewoon gezond verstand! Alleen is iemand zo slim geweest het nog eens op te schijven en zo het door vele ingewikkelde methodieken verstoorde wereldje weer even wakker te schudden. Die oude wijn, dat klopt dus wel. Maar wat als niemand Die oude wijn nu “Agile” had genoemd?
@Wilco gezond verstand en agile heeft zeker overeenkomsten. Het agile manifesto klinkt logisch, en Scrum is in 1 A4tje te beschrijven. Agile denken en doen blijkt soms toch lastiger. Ik blijf mij daarover verbazen. Common sense is not that common zegt men in het Engels. Zou dat dan echt waar zijn?