Het ‘agile’ proces en Scrum kennen grote voordelen, zowel voor de stakeholders als voor het ontwikkelteam. In betrekkelijk korte tijd wordt de belangrijkste functionaliteit geproduceerd waarbij de focus enerzijds ligt op de ‘backlog’ en anderzijds op de (geteste en becommentarieerde) code. De ‘brug’ tussen deze twee is de architectuur.

Door op belangrijke momenten code te ‘refactoren’, wordt de structuur van de code verbeterd. Daarbij kan het voorkomen dat de bij refactoring toegepaste ontwerpkennis impliciet blijft, doordat niet expliciet gebruik wordt gemaakt van kennis zoals ‘design principles’ en ‘design patterns’. In dat geval verbetert de structuur weliswaar vanuit een bepaald impliciet perspectief, maar wordt de code niet toegankelijk gemaakt via een hoger abstractieniveau.

Een tweede Scrum proces

Het voorstel is nu om, naar behoefte en parallel aan het ‘normale’ Scrum proces, een tweede Scrum proces te definiëren. Dit tweede proces richt zich op de totstandkoming van een expliciet design, met als doel om knelpunten in de structuur van de code uit het eerste proces op te lossen. Vanwege de hiermee beoogde kwaliteitsverbetering introduceer ik het proces hier onder de naam ‘Quality-Driven Scrum’. De output van Quality-Driven Scrum is design-informatie in plaats van code. Deze design informatie betreft hetzelfde product op een hoger abstractieniveau en doet uitspraken over de structuur van de code in het normale proces.

Voor het normale Scrum proces geldt:

  • backlog: geprioriteerde user stories;
  • output: executeerbare code;
  • ‘brug’: architectuur.

Voor het Quality-Driven Scrum proces geldt (*):

  • backlog: geprioriteerde knelpunten in de structuur van de code;
  • output: design specificatie;
  • ‘brug’: design patterns, design principles.

Quality-Driven Scrum toepassen

Scrum en Quality-Driven Scrum zijn gekoppeld omdat (a) de backlog voor Quality-Driven Scrum zich richt op knelpunten in de structuur van bestaande code, en (b) de ontwerpresultaten van Quality-Driven Scrum uiteindelijk dienen te worden vertaald naar een herstructurering van de code in het ‘normale’ Scrum proces. In koppeling (a) worden ‘as-built’ UML modellen gebouwd van de knelpunten in de code. Tijdens Quality-Driven Scrum worden op deze modellen ‘design principles’ en ‘design patterns’ toegepast om te komen tot UML specificaties. Tenslotte wordt in koppeling (b), op een geschikt tijdstip, de code in het normale Scrum proces in lijn gebracht met de ontwerpspecificaties.

De voordelen van Quality-Driven Scrum:

  • Er ontstaat (voor kritieke delen in de code) een ontwerp-specificatie;
  • Omdat het expliciete ontwerp de nadruk legt op hoger liggende principes en patronen, wordt de code toegankelijker via een hoger abstractieniveau (ook na lange tijd of voor andere developers);
  • Een verdere kwaliteitstoename resulteert naar verwachting in een productiviteitstoename van developers tijdens een vervolgontwikkeling;
  • Door een tweede Scrum proces op te richten voor design, blijven de voordelen van een ‘agile’ ontwikkeling voor het ‘normale’ proces behouden;
  • Omdat het expliciete design het resultaat is van een Scrum proces, gelden hiervoor de voordelen van een ‘agile’ proces; in betrekkelijk korte tijd wordt het belangrijkste deel van het design gerealiseerd.

Natuurlijk vereist bovenstaand voorstel een investering. Echter, de toegevoegde waarde van het toepassen van Quality-Driven Scrum zal meegroeien met de omvang van de codebase en de levensduur en wijzigingsgevoeligheid van de code. Vanaf een bepaald punt betaalt het zich terug in de kwaliteit van het eindproduct en de productiviteit van de betrokken ontwikkelaars.

(*): Het proces van Quality-Driven Scrum zoals hier beschreven kan naar behoefte worden uitgebreid naar andere aspecten van het product zoals UX, in combinatie met bijvoorbeeld style guides.