Binnen veel (bedrijfs)organisaties heeft de verschuiving van planmatig naar incrementeel en iteratief werken geleid tot een groeiende behoefte aan expliciete kwaliteitsborgen binnen korte oplevercycli. Definition of Done (DoD) is binnen agile methodologieën, in het bijzonder Scrum, een essentieel artefact dat deze kwaliteitsborging systematiseert (Schwaber & Sutherland, 2020). Het primaire doel van een DoD is het eenduidig vaststellen van de randvoorwaarden waaraan een ‘werkproduct’ dient te voldoen alvorens het als voltooid en deployable kan worden beschouwd. Dit voorkomt misinterpretaties en faciliteert een transparant inspectieproces (Diebold, Münch, & Zehler, 2015).
Onderstaand wordt de theoretische grondslag weergegeven, een korte schetst van een gestructureerde praktische toepassing alsook belicht het de kanttekeningen die bij de DoD kunnen worden geplaatst.
Theoretische grondslag
De DoD wortelt in het empirisch procescontrolemodel dat ten grondslag ligt aan Scrum. Volgens Schwaber en Sutherland (2020) waarborgt een gedeeld begrip van ‘done’ dat alle stakeholders over dezelfde kwaliteitseisen beschikken. Dit bevordert niet alleen de interne consistentie van incrementele opleveringen, maar voorkomt ook de accumulatie van technische schuld, zoals aangetoond in empirisch onderzoek (Diebold et al., 2015). Voorts positioneert Heidenberg et al. (2019) de DoD als een dynamisch instrument dat met het volwassenheidsniveau van het ontwikkelteam moet meegroeien. Deze adaptieve eigenschap sluit naadloos aan bij de kernfilosofie van continue verbetering binnen agile omgevingen.
Hoofdfasen van een DoD
De effectieve operationalisering van een DoD bestaat uit de navolgende vier hoofdfasen:
1. Co-creatie en operationalisering
De initiële stap betreft het (samen) formuleren van de DoD. Hierbij is de betrokkenheid van het gehele development team cruciaal, aangevuld met de Product Owner en waar nodig stakeholders. Criteria moeten objectief verifieerbaar en eenduidig geformuleerd zijn (Diebold et al., 2015). Enkele voorbeelden:
- “Unit tests dekken minimaal 80% van de code”
- “Code is gereviewd door minimaal één ander teamlid”
- “Gebruikersdocumentatie is bijgewerkt”
2. Integratie in de workflow
Het DoD dient consistent toegepast te worden in alle Scrum-events:
- Sprint Planning: De haalbaarheid van backlog items wordt getoetst aan de DoD.
- Daily Scrum: Het team bespreekt de status ten opzichte van de DoD.
- Sprint Review: Alleen volledig afgerond werk wordt gepresenteerd.
- Sprint Retrospective: Het team reflecteert op de DoD en past deze aan indien nodig (Schwaber & Sutherland, 2020).
3. Validatie en kwaliteitsborging
Gedurende de sprint blijft het team verantwoordelijk voor toetsing. Dit wordt gerealiseerd via geautomatiseerde testen, peer reviews en visuele checklists binnen tools zoals Jira of Azure DevOps (Heidenberg et al., 2019).
4. Continue evaluatie en optimalisatie
De DoD mag geen statisch document zijn. Bij elke retrospective moet geëvalueerd worden of de huidige definitie nog toereikend is en waar bijstelling nodig is (Petersen & Wohlin, 2010).
Welke kanttekeningen kunnen bij een DoD worden geplaatst?
Empirische studies benoemen enkele systematische beperkingen:
- Ritualisering: Teams kunnen de DoD reduceren tot een bureaucratische checklist zonder inhoudelijke validatie, waardoor de werkelijke kwaliteitswinst vervliegt (Diebold et al., 2015).
- Weerstand: Strengere DoD-criteria kunnen resulteren in weerstand, vooral wanneer deadlines prevaleren boven kwaliteit (Heidenberg et al., 2019).
- Culturele mismatch: In omgevingen zonder agile cultuur blijkt de DoD vaak een papieren tijger (Petersen & Wohlin, 2010).
- Ambiguïteit: Een te generiek geformuleerde DoD ondergraaft het primaire doel: eliminatie van interpretatieverschillen (Schwaber & Sutherland, 2020).
Conclusie
De Definition of Done vormt een fundamenteel bouwblok voor kwaliteitsborging binnen agile ontwikkelprocessen. Een effectief DoD-model veronderstelt gedeeld eigenaarschap, eenduidige formulering en verankering in dagelijkse werkroutines. Echter, zonder een passende agile cultuur, duidelijke communicatie en structurele toetsing, kan de DoD haar waarde verliezen en slechts een ritueel karakter aannemen.
Het is derhalve van belang dat teams het DoD-model zien als een dynamisch, lerend artefact dat consistent afgestemd moet worden op veranderende technische en organisatorische contexten.
LITERATUUR
- Diebold, P., Münch, J., & Zehler, T. (2015). How Software Process Improvement Practitioners Use the Definition of Done: A Qualitative Study. Product-Focused Software Process Improvement. PROFES 2015. Lecture Notes in Computer Science, 9459, 209–224. Springer.
- Heidenberg, J., Mäkinen, S., Taipale, O., & Smolander, K. (2019). Evolving Definition of Done in Agile Software Development. Journal of Systems and Software, 152, 208–224.
- Petersen, K., & Wohlin, C. (2010). The Effect of Moving from a Plan-Driven to an Incremental Software Development Approach with Agile Practices: An Industrial Case Study. Empirical Software Engineering, 15(6), 654–693.
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide™ — The Definitive Guide to Scrum: The Rules of the Game. Scrum.org.
Winstgevendheid verhogen en uw bedrijf in waarde laten toenemen?
UBS Business Value Creation Services ondersteunt organisaties bij het verhogen van winst- en bedrijfswaarde. Ons team focust zich hierbij op domeinen die de grootste impact hebben op het bedrijfsresultaat. Lees meer →
Reageer op dit bericht