Hoe zorg je met Scrum voor Kwaliteitsproducten en Diensten?

CooperationSteeds meer organisaties werken met Scrum om softwareproducten en -diensten te ontwikkelen. Ze gebruiken Scrum om flexibel in te kunnen spelen op wensen van de klant, sneller te kunnen ontwikkelen, en hogere software kwaliteit te leveren. Over flexibiliteit en snelheid is al veel geschreven, dit artikel vertelt wat Scrum voor de kwaliteit van producten en diensten kan doen en hoe samenwerking met de gebruikers zorgt voor een betere kwaliteit.

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 met Scrum kan zeker bijdragen aan een hogere kwaliteit (zie ook Agile Werkt, maar is daar bewijs van?). Laten we eens kijken hoe dat dat mogelijk is.

Wat is Kwaliteit?

Allereerst 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 software ontwikkelteam. 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. HetManifest voor Agile Software Ontwikkeling beschrijft de waarden:

‘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 gaan uit van een waterval projectaanpak 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. Projectmatig werken met agile teams is gebaseerd op een agile mindset. Ze gaat ervan uit dat je de kwaliteit van een product er niet in kunt ‘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 als het fout gaat, om dan van fouten te leren 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 het product en de manier van werken continue verbeterd mbv agile. En ook belangrijk: Het borgen van de veranderingen in de manier van werken doe je dmv leren ipv afdwingen. Blijvende verbetering!

Even voor de compleetheid: In sprint retrospecives kijk je niet alleen naar wat er mis gaat, maar ook (en juist) naar wat goed gaat, en naar de sterktes van het team. Met bv oplossingsgericht werken en Open Spaces kun je die sterktes benutten van de medewerkers, om daarme het team te verbeteren, en hogere kwaliteit tegen lagere kosten te kunnen leveren. Veranderen vanuit je sterktes, een andere aanpak die heel effectief kan zijn!

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. Teams organizeren zichzelf, passend bij het werk wat nodig om waarde voor de gebruiker te kunnen leveren. 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 de gebruikers het product zien en beleven, en gekeken wordt of het product voldoet. De product review geeft 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, zowel de samenwerking binnen agile teams, als de samenwerking met de gebruikers. 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!

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.

Dit artikel is deels gebaseerd op een artikel eerder dit jaar van mij in Computable: Kwaliteitsproducten en diensten met scrum. Ik werk samen met Computable als expert voor de topics ICT Management en BPM (zie ook about BenLinders.com).

Share this Experience
  • 24
    Shares

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.

This Post Has 3 Comments

  1. Agile kan een goede methode zijn voor ontwikkeling. Echter de praktijk is wat weerbastiger, zeker gezien de dynamiek in een bedrijf. De sponsers en business representatie is vaak niet aanwezig en de afgevaardigde heeft niet altijd de juiste bevoegdheid. Een ander probleem is het verloop van de teamleden, ingehuurde consultants kunnen zomaar vertrekken, door bezuinigen worden teamleden weg gehaald en/of vervangen. Een basis voor mislukking van Agile!
    Met andere woorden, zorg er voor dat een team, ook een tijd na oplevering van het product in stand blijft, als de kennis weg loopt is kan er een uitdaging ontstaan.
    Ook documentatie is een punt, hoeveel moet je aanleggen zodat onderhoud gepleegd kan worden. Bij wat grotere projecten blijkt in code die bij de eerste scrum gecodeerd zijn toch vaak aanpassingen gedaan moeten worden, dit geld ook na oplevering als er iets nieuws bij gebouwd gaat worden. Bij het laatste zijn de teams niet meer aanwezig en is de kennis weg gevloeid. Bij te weinig documentatie heeft men dan wel wat extra uitdagingen.

    Helaas zijn er praktijk voorbeelden te over dat agile niet de weg is om te gaan. Maar een combinatie met traditionele methoden werkt vaak heel goed. En uiteraard is het helemaal afhankelijk van de organisatie, zijn zij klaar en hebben ze de mindset dan is agile 1 van de goede methoden om te gebruiken. Lean en mean.

    Ronald

  2. Dank Ronald voor je reactie. Stabiele teams zijn inderdaad zeer belangrijk is agile, zie ook een eerder artikel hierover: Establishing and maintaining stable teams.

    Over documenteren, en ook bv pair programming en reviewing volgt nog meer, in een artikel over agile technieken voor kwaliteit wat ik nog aan het schrijven ben. Stay tuned 🙂

Leave a Reply

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

Close Menu
×
×

Cart