To document or not, that’s the question

In een waterval omgeving is goede en uitgebreide documentatie een belangrijke succesfactor voor het project. Wanneer in de beginfase requirements worden gedefinieerd, is het goed om deze requirements SMART te formuleren, want deze moeten gedurende het hele project meegaan. Een jaar later zijn bij het acceptatietesten vaak andere stakeholders betrokken.

Ook de functionaliteit moet in ontwerpdocumenten goed beschreven zijn, want die dienen als uitgangspunt voor bouwers, testers, handleidingenschrijvers en functioneel beheerders tijdens het project en de levenscyclus van het softwareproduct.

En niet te vergeten de testdocumentatie:  externe accountants, interne auditdiensten, branchespecifieke toezichthouders, compliance- en riskafdelingen hebben door de jaren heen allerlei eisen in het kwaliteitssysteem laten opnemen, waardoor bij een change naar productie gedegen testplannen, uitgebreide testrapporten, specificatie van de testgevallen, bewijs van de testresultaten, traceability naar requirements, en de juiste goedkeuringen op de release moeten worden meegeleverd.

Met behulp van checklists, standaard templates, tooling en gedetailleerde procesbeschrijvingen wordt het de teams gemakkelijk gemaakt om aan al die eisen te voldoen.

Maar wat als je agile wilt werken? Dan passen de templates niet in je werkwijze, kloppen de procedurebeschrijvingen niet meer, en staat de hoeveelheid verplicht op te leveren documentatie niet in verhouding tot het werk dat je in één sprint oplevert. Maar de genoemde stakeholders blijven om de documentatie vragen.

Is hiervoor een generieke oplossing? Nee. En toch: ja. Want uiteindelijk is kwaliteit mensenwerk. In welke organisatie je ook zit, het komt erop aan voortdurend met elkaar in gesprek te blijven en te blijven nadenken over waar het beter kan. Organisaties veranderen nu eenmaal. En het is de kunst om in die veranderingen je kwaliteitsaanpak, en dus de wijze van documenteren, mee te laten bewegen. Zo vormen de kwaliteitsmaatregelen geen blokkade, maar eerder een ‘enabler’ om in één keer goed op te leveren.

Waar moet dat gesprek met de stakeholders dan over gaan? Vraag de beheerder of de compliance-afdeling waarom ze bepaalde documentatie nodig hebben, of waarom ze het per se in het voorgeschreven formaat willen hebben. Wat er fout gaat als ze het niet krijgen? Is het noodzakelijk om elke release (de uitgebreide versie van) het document te krijgen? Het antwoord zal je verbazen. Wanneer je kritisch doorvraagt en (vaak) ingesleten gewoonten ter discussie stelt, valt er veel winst te behalen in het reduceren van op te leveren documentatie.

Juist door vragen te stellen kom je achter de essentie van de eisen van stakeholders en kun je tot verrassende alternatieve oplossingen komen, die veel beter passen bij je (agile) werkwijze. GA IN GESPREK… Niet voor niets ook een van de principes van het Agile Manifesto!