'In ons Scrum team hoeven we geen reviews uit te voeren' is vaak een van de eerste reacties als ik over toetsen praat. Mijn ervaring is echter dat er onbewust meer gereviewed wordt dan men denkt en dat men het vaak over de specifieke vorm ‘reviewen’ heeft. Hieronder mijn eerste gedachtegang waarbij ik toetsen voor het gemak maar even reviewen noem.
Scrum: het start met items op de backlog
Zijn de stories op de backlog duidelijk voor iedereen die ermee te maken heeft? Wat betekent ‘duidelijk’ eigenlijk? Is de story te bouwen, te testen en te accepteren, of is er behoefte aan meer informatie om dit te kunnen doen? Eigenlijk is het jezelf deze vragen stellen al een vorm van reviewen van de items op de backlog! Waarom zou je deze review dan niet op gestructureerde wijze aanpakken en met meer zekerheid profiteren van de samenwerking, tijdbesparing en kwaliteitswinst? De scrummaster kan deze actie initiëren en faciliteren.
- Ga tijdens de retrospective eens na of er punten zijn die het team had kunnen voorkomen door items op de backlog eerder te verduidelijken.
- Evalueer eens voor jezelf: heb je voor meerdere items op de backlog dezelfde soort verduidelijking moeten vragen?
- Zijn verduidelijkingen die gedurende de sprint gegeven worden altijd direct in beschrijvingen van de backlog-items verwerkt? Indien dat niet zo is, overweeg dan de optie om (met behulp van de Definition of Ready) tijdens de backlog grooming sessies, refinementsessie of planningpokersessie een beperkte review uit te voeren. Update de backlog-items vervolgens direct zelf zodat tijdens de sprint minder updates nodig zijn.
- Overweeg het Three Amigos process waarin een architect, developer en tester de backlog-items verduidelijken.
Scrum: reviewen gedurende een sprint
Voert het team codereviews, checks op (web)content of regressie-testgevallen uit? Dit zijn óók reviews! Afhankelijk van de situatie kun je je bevindingen direct aan de po voorleggen, of ze verzamelen en in één keer opleveren en bespreken. In beide situaties kan een gestructureerde aanpak helpen in een effectieve review. Gebruik checklists (die je bijwerkt tijdens de sprint retrospective) om er zeker van te zijn geen specifieke onderwerpen bij de review te vergeten.
- Code review: soms worden teamleden gevraagd een stuk code aan een review te onderwerpen. Door niet alleen met gezond verstand te kijken, maar ook een checklist te hanteren, wordt het makkelijker grip op de review te houden. Het maakt de review ook voorspelbaarder in geval een ander teamlid gevraagd wordt de review uit te voeren. Vaak zijn de bevindingen direct te repareren.
- Review content: in sommige situaties is tekstuele content onderdeel van een deliverable. Bijvoorbeeld in websites, nieuwsbrieven, datamigraties, communicatie naar klanten, facturering en dergelijke zou een review van de content nodig kunnen zijn om aan de Definition of Done te kunnen voldoen. In sommige situaties zijn bevindingen weer direct door het scrumteam op te pakken, in andere situaties zou het kunnen zijn dat de review moet worden uitgevoerd door mensen van buiten het scrumteam. Zeker in dat laatste geval zou een gestructureerde aanpak van pas komen. Een proces zoals beschreven op www.structuredreviewing.com zou daarbij als uitgangspunt kunnen dienen.
- Review van (regressie) testgevallen: sommige scrumteams beschouwen testgevallen als wegwerp-testgevallen. In dat geval is een desk check of een peer review bij het koffieapparaat wel voldoende. Regressietestgevallen daarentegen hebben vaak een langere levensduur en hebben gedurende langere tijd de functie van het aantonen van stabiliteit van het systeem en haar business value, dat een meer intensieve review nuttig kan zijn. Indien daarbij meer dan een of twee reviewers betrokken zijn, zéker als deze niet allemaal onderdeel van het scrumteam zijn, zal een gestructureerd reviewproces handig zijn. Bijvoorbeeld voor het limiteren van de doorlooptijd, de communicatie omtrent de review, het betrekken van de juiste stakeholders en het verdelen van de rollen en aandachtspunten.
- Reviewen van documentatie afkomstig van bronnen van buiten het team, zoals vanuit andere teams, andere organisaties of organisatieonderdelen.
Aan het eind van een sprint, gedurende de sprint review, geeft het scrumteam een demo van de items die klaar zijn om op te leveren. Deze demo is eigenlijk ook een soort van review; immers, het product wordt in een live setting voorgelegd aan enkele stakeholders die ook tijdens de demo nog opmerkingen kunnen leveren. Het kan nuttig zijn de stakeholders voorafgaand aan de demo te wijzen op hun rol en inbreng: kritisch en vanuit de eigen rol. Het verwerken van opmerkingen kan gelijksoortig een formele inspectiemeeting georganiseerd zijn. Time-boxed (binnen de tijdlijnen van de demo), een notulist voor de opmerkingen (bijvoorbeeld de scrummaster) en voorgezeten om discussies tijdig te stoppen of naar een ander moment door te verwijzen.
In scrum zijn reviews eigenlijk van nature al onderdeel van de dagelijkse gang van zaken. Ook zonder formeel reviewproces kunnen de reviewactiviteiten zélf wel degelijk gestructureerd van aard zijn, passend in de situatie. De structuur, bijvoorbeeld in de vorm van checklists of afspraken (vastgelegd in de Definition of Done!) helpt scrumteams om efficiënter te werken en meer voorspelbaar te worden ten aanzien van de velocity.
