Waterval vs. Agile Scrum

Bij Tam Tam maken we een belangrijke transitie door op weg naar een – voor ons – nieuwe manier van werken; Agile Scrum. Over de schutting gooien deden we al jaren niet meer, maar de watervalmethodiek kende desalniettemin behoorlijke valkuilen. Na enkele projecten begin ik een gevoel te krijgen bij de voor- en nadelen, dus tijd voor een voorzichtige tussenstand.

Waterval

Er zijn een aantal belangrijke voordelen, met name voor de klant, bij het volgen van een watervalmethodiek. De klant heeft na iedere fase (FO, GO, FED en bouw) een beslissingsmoment, waarbij ook de mening van grotere groepen in overweging kan worden genomen. Met name voor grotere organisaties is hier soms niet aan te ontkomen. Bovendien wordt er meer documentatie opgeleverd, zodat er voor deze achtervang ook meer helderheid komt over wat de uiteindelijke oplevering inhoudt. Als projectmanager heb je dus altijd een stok achter de deur.

Er zijn echter ook behoorlijk wat cruciale nadelen:

  • Voortschrijdend inzicht: Gedurende een project kan het zijn dat de gekozen interactiemodellen, of de gebruikte ontwerpen op basis van een interactievorm in de praktijk anders blijken te werken. Dat kan ertoe leiden (of lijden?) dat je terug moet naar de tekentafel, maar dat kan conflicteren met het volgende probleem:
  • Planning: Je staat als functioneel ontwerper 32 uur ingepland voor het maken van een FO. Je levert het aan bij de grafisch ontwerper, doet een goede overdracht, en gaat door naar het volgende project. Twee weken later blijkt het FO toch problemen te kennen, of er ontbreken zelfs onderdelen. Jij bent echter al weer bezig aan het volgende project. Lastig, want nu gaat een andere FO’er het oppakken, maar die heeft misschien een andere visie. Jouw concept raakt stukje bij beetje verloren.
  • Eigenaarschap: Hoe kun je dat steengoede grafisch ontwerp blijven bewaken met meerdere projecten in het vooruitzicht. De interpretaties van de programmeurs of front-end developers – hoe goed je zo ook hebt gebriefd – leiden tot een andere uitwerking, en bij oplevering voel je je niet meer volledig verbonden met datgene dat live staat. De puntjes op de i missen, het volgende 95%-project is een feit.

Agile Scrum

Agile scrum voorkomt onaangename verrassingen voor de klant.

Agile Scrum is een methodiek die behoorlijk aan bekendheid en populariteit heeft gewonnen de afgelopen 2 á 3 jaar. Het bestaat al wel wat langer, flink wat langer zelfs. De methodiek is er kort gezegd op gericht om met een klein, multidisciplinair (met ook multidisciplinaire leden) team doelgericht, meetbaar efficient te werken, waarbij je het project indeelt in kleine behapbare deelprojecten. Door steeds deze korte ‘sprints’ te trekken, waarbinnen je een aantal van deze deelprojecten oplevert, heb je steeds opnieuw resultaten die je kunt delen met het team en natuurlijk de klant. Alles is gericht op produceren, en dat is ook direct waar je op wordt afgerekend. Deelprojecten krijgen een waarde gebaseerd op de complexiteit ervan. Deze complexiteit wordt benoemd met waardes van 1, 2, 3, 5, 8, 13 en 20 (bijna Fibonacci maar niet helemaal, dat stoort me dan weer mateloos als purist). Iedere sprint, die gemiddeld 2 tot 3 weken duurt, spreek je met elkaar een doel af; “30 punten binnen deze sprint”. Blijk je dat in de sprint makkelijk te halen, dan stel je dat doel bij de volgende sprint gewoon bij. Deze zogenaamde velocity een bijzonder goede graadmeter voor het meten van het succes van het team. Iedere sprint is gericht op het opleveren van een werkend product, wat kan betekenen dat in sprint 1 een kaal CMS wordt opgeleverd, met alleen een homepage en een contactpagina. Zolang het maar een werkend product is, de gebruiker er mee uit de voeten zou kunnen en de klant een meetbare stap in de goede richting heeft gezet.

Denken vanuit de gebruiker

De deelprojecten worden niet ingedeeld op basis van functionaliteiten (“We willen in deze sprint via Google Maps al onze vestigingen tonen!”) maar op basis van user-stories. “Wat wil de klant bereiken, en hoe gaan we dat serveren?” Het kan dus ook zijn dat een user-story in een latere sprint opnieuw terug komt met de toevoeging dat de klant op een kaart de vestigingen wil kunnen bekijken, terwijl in sprint 1 misschien een lijst van lokaties voldoende was. Deze user-stories worden vervolgens opgedeeld in taken voor de verschillende disciplines. Alle user stories komen samen op het product backlog, een grote lijst waaruit voor iedere sprint een selectie kan worden gemaakt van de zaken die in die sprint moeten worden uitgewerkt.

Voordeel hiervan is dat de progressie van het project goed meetbaar is, en de klant bij aanvang van iedere sprint weet wat 2 of 3 weken later wordt opgeleverd. Wanneer de oplevering dan niet volledig is, kan de klant ook in een vroeg stadium aan de bel trekken. Het voorkomt onaangename verrassingen voor de klant. De klant is zeer nauw betrokken bij het project.

Manier van (samen)werken

Het team zit altijd bij elkaar, permanent, in dezelfde ruimte. Er is namelijk altijd voor iedereen werk, want een functioneel ontwerper werkt nooit in week 1 het volledige functioneel ontwerp uit. Dat wordt steeds in iedere sprint uitgewerkt, bijgesteld, aangescherpt. En als jouw werk er in de sprint op zit kun je de implementatie van jouw werk door collega’s testen, of je zet je ontwerp-pet even op en duikt in Photoshop / Fireworks om je collega te helpen met het uitwerken van schermen. Ook de klant is onderdeel van dit team, zit het liefst ook in het scrumhok, wordt betrokken bij beslissingen en heeft continue eigenaarschap over het product in ontwikkeling.

Iedere dag begint de dag met de daily scrum. Deze dagelijkse meeting duurt zo kort mogelijk en heeft eigenlijk voor ieder teamlid drie belangrijke vragen:

  • Wat heb je gisteren gedaan?
  • Wat ga je vandaag doen?
  • Wat zijn eventuele problemen waar je tegenaan loopt?

Iedereen is zo goed op de hoogte van de voortgang, en de problemen die eventueel spelen. Problemen worden direct opgelost of in een lijst opgenomen waar de scrum master mee aan de slag gaat. De scrum master is verantwoordelijk voor het op snelheid houden van het team.

De voordelen op een rijtje

  • Delen van kennis – In mijn ervaringen met Scrum viel het me op hoeveel je ineens meekrijgt van de beslissingsmomenten van je collega’s. “Wat nou als we x op manier y oplossen?”, “Zullen we eens kijken hoe lijst a uitklapt met de animatie uit blokje b?”. Het is veel meer een avontuur dat je met je collega’s deelt, het is van jullie allebei, je leert in iedere discussie meer van elkaar dan je ooit in een 80 pagina-tellend FO had kunnen leren.
  • Klantbetrokkenheid – De klant maakt iedere dag de voortgang mee, en kan er direct op reageren. Dat kan lastig zijn voor teamleden, maar komt het project uiteindelijk ten goede. No regrets bij oplevering. In mijn ervaring kwam dat ook de band die je hebt met een klant bijzonder ten goede; je snapt steeds beter de visie, zijn of haar overwegingen en de interne politiek aan de klantzijde.
  • Voortschrijdend inzicht – Doordat iedere betrokkene iedere dag ziet waar het project toe gaat leiden is het veel makkelijker om bij te sturen wanneer zaken minder goed of effectief blijken te zijn. Het zou er zelfs toe kunnen leiden dat onderdelen niet nodig blijken en komen te vervallen. Er zijn zelfs projecten bekend die halverwege de doorlooptijd en dus ook het budget zijn gestopt. Ontevreden klant? Welnee, juist heel tevreden, het was klaar. De rest van de bij voorbaat beoogde elementen bleken simpelweg overbodig. Less is more, right?
  • Planning – Afgezien van het vorige voorbeeld; het is veel gemakkelijker om 5 mensen permanent op een project in te plannen dat steeds de poppetjes te verschuiven over diverse projecten. Iedereen in het scrum team kan elkaars taken overnemen, dus niemand zit ooit meer zonder werk. En als tijdens het project het einde in zicht komt kun je direct het volgende projecten aanpakken met je team; geen loze ruimtes meer in de planning.
  • Plezier – Het is echt waanzinnig leuk om op deze manier met je collega’s samen te werken. Je leert in hoog tempo van elkaar, en je leert de talenten en aandachtspunten van je collega’s en de klanten kennen. Dat maakt dat je veel beter op elkaar kunt inspelen en je na verloop van tijd aan een half woord voldoende hebt. Niet dat je elkaars beste vrienden hoeft te worden, maar elkaar goed begrijpen kan nooit kwaad.

Conclusie

Maar nooit meer een waterval project dan? Jawel, maar alleen als het project daarom vraagt. Niet iedere klant kan goed omgaan met deze methodiek; als het contactpersoon aan de klantzijde verantwoording moet afleggen aan een Raad van Bestuur of een stuurgroep heeft dat meer tijd nodig, en zal dat in een Agile Scrum-project alleen maar tot vertraging en irritatie leiden.

Ik denk dat Agile Scrum de nadelen van de waterval-methodiek goed oplost, maar dat maakt het niet per definitie de betere optie. Ik denk vooral dat de voordelen van Agile Scrum het verschil maken. Dat klinkt misschien een beetje stom, maar ik persoonlijk vind vooral de winst in kennisdeling en het stukje voortschrijdend inzicht een veel fijnere manier van werken. Het is het consequent opzuigen van kennis en informatie dat het werken zoveel leuker maakt. Het contact met de klant, het begrijpen van klantvragen en -wensen, het samen chicaneren over die paar pixels, het werken naar dat 100%-project is wat deze manier van werken zoveel zinvoller en leuker maakt. En dan is werk ineens geen werk meer.

update: Ik kreeg naar aanleiding van dit blog relatief veel opmerkingen en vragen rondom: “Ja, leuk, klinkt gaaf, maar hoe verkoop je zoiets? En hoe doe je dat met budgetten?”. Laat me beginnen te zeggen dat ik geen projectleider/ scrum master ben en ook niet die ambitie heb. Dus echt waterdichte antwoorden kan ik niet bieden, maar wil wel een poging doen.

Bij de verkoop van een project spreek je samen met de klant een scope af. “We leveren een website met een nieuw ontwerp, inclusief de bestaande contentvormen en 2 killer applicaties. We werken in sprints van 2 weken met 5 teamleden, en zullen in totaal 3 sprints aan dit project werken.” Daaruit volgt natuurlijk een simpele rekensom ten opzichte van je tarieven.

Scrum werkt niet als je niet van tevoren de visie hebt een langdurige relatie aan te gaan met je klant. Je spreekt de scope voor fase 1 af en gaat daarna kijken welke stappen verder nog kunnen worden gezet, bijvoorbeeld wanneer niet alle user-stories aan bod zijn gekomen. Dit zal in de praktijk echter niet zoveel voorkomen, omdat je veel gemakkelijker de snelheid, scope en richting kunt bijstellen gedurende het project, en de aanpak sowieso leidt tot meer efficiëntie en dus een hogere velocity.

Ik kreeg ook de vraag of het voor kleinere projecten dan niet aantrekkelijk is. Ik denk dat het er vanaf hangt hoeveel user-stories je binnen een klein project probeert te beantwoorden. Als het om 1 user-story gaat zal het niet zoveel uitmaken welke aanpak je kiest, maar zodra je met meerdere teamleden in korte tijd een project wilt realiseren is het hoe dan ook rendabel.

7 gedachten over “Waterval vs. Agile Scrum”

  1. Leuk artikel, goed verwoord en geschreven.

    Heb je er mogelijk nog de bronnen welke je mogelijk hebt gebruikt hiervan? Misschien leuk voor mensen die jouw artikel willen refereren als een bronnenlijst bij aanwezig is namelijk.

    Gr,
    Robin

  2. Leuk artikel. Ik maak zelf mee dat wij als partner graag naar Agile Scrum zouden willen gaan. Alleen je merkt inderdaad dathet wel of niet mogelijk zijn hiervan ligt bij de klant (en ook hun omgeving). Sommige handvatten die Agile biedt zoals jij noemt (kennisdeling, klantbetrokkenheid, voortschrijdend inzicht, planning(en natuurlijk ook plezier ;-)) hebben wij hier op ons project ook wel hoor. Alleen werken we nog steeds volgens waterval. Wat inderdaad zoals jij het ook mooi verwoord niet meteen wil zeggen dat dat per definitie slecht is natuurlijk. Ik merk nu alleen wel soms dat het project er juist wel om vraagt… maar de klant er niet aanwil (of niet aan durft)… ik denk dat dat ook geworteld is in het karakter en geschiedenis van een bedrijf. Groetjes Chris.

    1. Het is een proces waar de klant zeker aan moet wennen. Het gaat vooral om een goede samenwerking en het feit dat je vaak en snel resultaat hebt om over te praten. Dat is voor een klant vaak de grote pré, en dat werpt ook snel vruchten af. De meeste grote bureaus zijn inmiddels lang en breed over, dus er moet voldoende over te vinden zijn. Lees vooral ook de artikelen van Pieter Jongerius op Frankwatching, hij heeft goede inzichten gedeeld aldaar!

      1. Hoi Jeroen. Bedankt voor de reactie. Ok Pieter Jongerius op Frankwatching… zal het bekijken! Zie dat hij ook een twitter-acc heeft. Gelijk maar even volgen ;-). Grt.

  3. Hoi Jeroen, Leuke blog! Als contractmanager kom ik vaak collega’s tegen die het eng vinden om scrum/agile projecten te contracteren. Ik ben zelf nog geen reden tegen gekomen waarom dat lastiger is dan een waterval traject te contracteren. Sterker nog, ik ben van mening dat juist een scrum/agile project veeeel makkelijker te contracteren en te managen is (vanuit contractmanagers oogpunt).

    Je blog is van een aantal jaren geleden. Hoe is nu je visie op Waterval vs Scrum?

    Met vriendelijke groet
    De Contractmanager

    1. Hallo Bob,

      Het is inderdaad al een wat ouder artikel, wel de best bezochte door de jaren heen overigens ;-) Tegenwoordig werk ik bijna alleen nog maar in scrumtrajecten. Wat je vaak ziet gebeuren is dat een klant een beeld heeft bij de scope van een project, en dan in de laatste sprint nog even ‘alles’ willen hebben wat niet in de overige sprints aan bod is gekomen. Dat heeft te maken met de verwachtingen van een klant die niet goed zijn gemanaged bij de start van het project natuurlijk.

      De rol van de klant is cruciaal, de commitment naar het team, en voldoende begrip van scrummethodieken. Daar valt of staat het project bij :)

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *