Scrum Master / Agile Coach / Scrum Trainer

Waterval binnen Scrum

Er is al vaker over geschreven: waterval binnen Scrum (of een gelijksoortige benaming). Toch wil ik deze blog aan waterval binnen Scrum wijden, omdat ik denk dat er twee soorten van zijn en dat het diverse oorzaken heeft waar niet altijd op in wordt gegaan.

Niveaus van waterval binnen Scrum

Er zijn zeker twee niveaus van waterval binnen Scrum:

In de volgende alinea’s worden deze niveaus toegelicht inclusief de oorzaken die daarbij horen.

Grotere items die opgeknipt worden maar pas na meerdere iteraties een werkend product opleveren: de item waterval

Het gaat hierbij om een functionaliteit of behoefte die te groot is om in één iteratie op te leveren en daarom opgeknipt wordt in kleinere items zodat de items in één iteratie passen. Dat is een voortdurend proces binnen Agile werken. Soms zijn deze items ‘fasen’ van het ontwikkelproces die we kennen uit waterval, bijv. ‘analyse’, ‘design’, ‘ontwikkelen’ en ‘testen’, maar bijv. ook ‘aanpassing aan database’, ‘aanpassing aan applicatie X’ etc. Daarom wordt dit een waterval genoemd, en noem ik dit specifiek een item waterval.  Mike Cohn heeft hier ook een artikel over geschreven.

Oorzaken

In een transitie waar organisaties vooral gewend zijn om met waterval te werken, kunnen de eerste backlog refinements de functionaliteiten of deelproducten opknippen in de fasen die ze gewend zijn uit waterval. Dat wordt ook wel ‘horizontal slicing’ genoemd (lees bijv. hier meer daarover). In plaats van een stukje van het product dat in zijn geheel wordt gerealiseerd in een item, wordt bijvoorbeeld het inrichten van de database als item opgevoerd. Echter is er 0% van het product dat ter review kan worden aangeboden als de database is ingericht. In plaats daarvan kan beter één stuk functionaliteit als item worden opgevoerd, waarbij zowel het inrichten van de database als eventuele andere technologische componenten, als een uiteindelijk werkend iets voor een gebruiker of klant wordt opgeleverd. Dat mag ook alleen de inlogpagina met één eenvoudige functionaliteit zijn (zie bijv. het volgende filmpje van Eric Ries over het minimum viable product). Dan is er namelijk de mogelijkheid om feedback te geven en nieuwe wensen op basis van het opgeleverde op de Product Backlog te zetten. In Scrum wordt voor het opleveren ‘potential releasable increment’ gebruikt, het hoeft dan nog niet definitief aan een gebruiker of klant te worden aangeboden, dat is aan de Product Owner.

Product Backlog items worden opgevoerd/opgeknipt tot items die door één team in één iteratie te realiseren zijn. Als er Component teams zijn, dan worden items op de Product Backlog opgeknipt tot items die door een Component team opgeleverd kunnen worden binnen een iteratie. Een Component team is een team dat is georganiseerd naar een architecturele component (bijv. een database of een specifieke applicatie) of losse processtap, in tegenstelling tot een Feature team dat alle competenties aan boord heeft om één werkende feature op te leveren, vaak voor meerdere architecturele componenten of processtappen (een uitgebreidere eenvoudige uitleg is hier te vinden). Dat betekent dat door de aanwezigheid van Component teams item waterval vrijwel noodzakelijk wordt, omdat de items van elkaar afhankelijk zijn uit verschillende Component teams, omdat ze los van elkaar geen werkend product opleveren.

Ongetwijfeld zijn er meerdere oorzaken te bedenken, maar dit zijn twee van de meest evidente oorzaken in mijn beleving.

Een waterval die uitgevoerd wordt binnen een iteratie door het Ontwikkelteam: de sprint waterval

Als een team binnen een iteratie aan de slag gaat met een gevraagde functionaliteit, dan wordt het item binnen de iteratie meestal in kleinere stukken opgebroken (bijv. om de voortgang goed te kunnen monitoren of het werk goed te kunnen verdelen). Als teams het werk opbreken in onderwerpen als ‘analyse’, ‘ontwikkelen’ of ‘testen’ dan ontstaat er een waterval binnen een sprint, die ik de sprint waterval noem. Het team gaat dan eerst de analyse uitvoeren, vervolgens ontwikkelen en uiteindelijk testen in dit voorbeeld. Pas na het bijna afronden van het item wordt voor het eerst de functionaliteit in zijn geheel getoond. Echter is er daardoor tijdens de iteratie geen feedback mogelijk op een ‘tussen’ product van de functionaliteit en niet mogelijk om de functionaliteit verder te verbeteren of andere opties te proberen. Er is dan geen ruimte meer, omdat het item dan is afgerond en de iteratie ten einde is of andere items dienen te worden opgepakt binnen de iteratie.

De sprint waterval zou ook uitgevoerd kunnen worden voor een item waterval, binnen een sprint. Maar komt minder vaak voor, omdat voor een item waterval meestal maar één of enkele specifieke competenties nodig zijn. Voor een ‘analyse’ item in een iteratie, hoeft binnen de iteratie niet nog eens een analyse uitgevoerd te worden bijvoorbeeld.

Oorzaken

Feature teams zijn teams die een werkend feature van begin tot eind kunnen opleveren. Echter zijn er teams waarbij de rolverdeling in het team ervoor zorgt dat een teamlid bepaalde specifieke werkzaamheden uitvoert en deze werkzaamheden blijft uitvoeren, en dat een ander teamlid dat doet voor andere specifieke werkzaamheden. Dat zorgt ervoor dat binnen een iteratie het werk verdeeld wordt over de teamleden, maar dat ze dat niet van elkaar kunnen overnemen of samen kunnen doen. De werkzaamheden die als eerste plaats moeten vinden worden door teamlid A uitgevoerd, waarna teamlid B de vervolg werkzaamheden uitvoert. Dat zorgt voor een waterval door de afhankelijkheden, waardoor een feature pas aan het einde van een iteratie kan worden opgeleverd in plaats van al gedurende de iteratie. Een bijkomend nadeel is dat teamleden niet samen kunnen nadenken over een oplossingsrichting en niet hun volledige denkkracht benutten. Een mogelijkheid om dit op te lossen is door competenties van elkaar te laten leren – dat kan bijv. door ‘pair programming’ samen werken aan werkzaamheden – en zodoende in staat zijn om steeds meer van elkaar over te nemen. In dit artikel wordt er verder op ingegaan waarom Scrum Teams moeten (blijven) leren.

Er zijn teams waarbij de werkzaamheden overwegend verdeeld worden onder de teamleden gedurende een iteratie. Uiteraard is het voor kleine werkzaamheden of sommige situaties niet erg dat dit gebeurt, maar als dat overwegend gebeurt worden binnen een iteratie vaak de werkzaamheden op elkaar ‘afgestemd’ zodat teamleden verder kunnen gaan met vervolg werkzaamheden als het eerste teamlid het werk heeft afgerond. De achterliggende gedachte is dat parallel werken zorgt voor meer efficiëntie, maar het zorgt voor toenemende afhankelijkheden binnen het team. Als het zorgt voor het opknippen van het werk in gefaseerde werkzaamheden of werkzaamheden voor specifieke architecturele componenten is er sprake van een waterval sprint.

Als er in het team leden zitten die als rol ‘tester’ hebben, dan zorgt dit voor een waterval sprint. De rest van het team levert haar werkzaamheden op (eerste fase), waarna de tester zijn/haar werkzaamheden kan oppakken: testen. Als dit vervolgens leidt tot additionele werkzaamheden/bugfixing, dan gaat de rest van het team er weer mee aan de slag. Dit zorgt voor afhankelijkheden binnen het team, extra planning en minder verantwoordelijkheid voor het testen bij de overige teamleden (‘het komt wel naar voren tijdens het testen’). Testen zou integraal onderdeel moeten zijn van de ontwikkeling van een feature en niet bij één (of enkele) persoon moeten liggen. Dit geldt uiteraard ook voor andere specifieke rollen in het team, bijvoorbeeld als er aparte front-end developers of designers in het team zitten die uitsluitend die werkzaamheden oppakken. Maar voor testen komt dit - in mijn ervaring - vaak voor, waardoor ik specifiek dit voorbeeld gebruik.

Waarom hoeft het niet erg te zijn om waterval binnen Scrum te doen?

In een transitie naar agile denken en werken kan dit de eerste stap zijn. Er wordt geleerd hoe met een Product Backlog omgegaan moet worden, hoe items opgeknipt moeten worden en hoe binnen een Scrum Team het werk tijdens een iteratie uitgevoerd wordt. Vanuit de praktijk zal er ervaren worden (empirisch) dat deze manier van werken wellicht niet handig is. Daarom is continue verbeteren ook belangrijk, zodat een nieuwe manier geprobeerd kan worden die effectiever zal zijn (en anders weer aangepast wordt).

Een belangrijke laatste noot gaat over samenwerking in het team. Als een (feature) team zijn ideale situatie zou bereiken waarbij ieder teamlid alle werkzaamheden kan uitvoeren, dan nog is het belangrijk dat teamleden met elkaar samenwerken. Dan wordt de denkkracht optimaal benut en persisteert de kennis van een opgeleverde feature bij alle teamleden.

Eerdere blogs

Mark Uijen de Kleijn

E: info@remarkablethinking.nl

L: linkedin.com/in/mark-uijen-de-kleijn