Agile en ISO 25010

Er wordt heel wat afgeblogd over het wel of niet kunnen mengen van Agile met alles wat we eerder al hadden. PRINCE2, RUP, MSP, CMMI, je noemt het maar. Gek genoeg een stuk minder over een van de weinige ISO standaarden die ik zelf regelmatig gebruik: ISO 25010 (opvolger van de beruchte ISO 9126 serie).

De ISO/IEC 25010:2011 standaard heet ook wel 'SQuaRE': Systems and Software Quality Requirements and Evaluation. Ook deze ISO standaard is voor velen van ons droge, theoretische kost. Waarom begin ik er dan over?

Het mooie aan deze standaard is, vind ik, dat het een indeling en beschrijving geeft van aspecten aan een systeem waarop je de kwaliteit kunt beoordelen. Requirement engineers en testers gebruiken deze lijst in klassieke software ontwikkelprojecten om zeker te stellen dat alle eisen en wensen vooraf worden bepaald en achteraf worden geverifieerd.

Als we Agile werken willen we geen lijvige documenten vooraf. En met een saaie ISO standaard onder de arm bij een Scrum team binnen lopen is de manier om direct weer weggestuurd te worden.

Er zijn manieren om de handige opsomming van karakteristieken van productkwaliteit wel effectief te gebruiken. In Agile omgevingen moeten we dan wel goed onthouden dat we deze checklist niet moeten invoeren als een verplichte meetlat of template.

Hoe dan wel? Ik zie daarvoor minimaal de volgende twee mogelijkheden:

1. Als een Product Owner toch niet geheel tevreden is over het hoe het systeem is: gebruik de vijf 'Quality in Use' karakteristieken als startpunt voor een root-cause onderzoek.
2. Als het Scrum team (te) veel werk terugkrijgt waarvan ze dacht dat het af was (technical debt): gebruik de acht Product Quality' karakteristieken als startpunt voor een root-cause onderzoek.

Als dit leidt tot inzicht dat er gebruiks- of producteisen zijn die eerst niet voldoende aandacht hebben gehad: voeg ze toe aan de 'Definition of Ready' of aan de 'Definition of Done'.