Agile en Scrum zijn hot en trending. Iedereen moet tegenwoordig volgens Scrum of op een andere manier Agile werken. Als een methode populair genoeg is, komen er vanzelf steeds meer mensen die zich expert noemen. Maar is dit altijd wel terecht? Is het rigide toepassen van de Scrum regels voldoende om jezelf expert te noemen?
Het mantra van de evangelisten is het Agile Manifest:
- Mensen en hun onderlinge interactie boven processen en hulpmiddelen
- Werkende software boven allesomvattende documentatie
- Samenwerking met de klant boven contractonderhandelingen
- Inspelen op verandering boven het volgen van een plan
Als je kijkt naar de gedachten achter dit manifest, dan werkt het prima. Kijk je alleen naar deze regeltjes en pas je die blind en rigide toe, dan kun je in onderstaande situaties terecht komen.
Requirements zijn overbodig. We hebben een userstory en dat is voldoende.
“Als je aan Scrum doet, is het schrijven van requirements overbodig. Je stelt de userstory op en dat is genoeg om te beginnen met ontwikkelen.” Binnen Agile wordt gesproken over “just enough” beschrijven. Dit betekent echter niet dat je niets beschrijft. Een story is altijd het begin van een conversatie. Dat is het doel van de user story. Soms kan het voldoende zijn om op een hoog niveau de story op te stellen. Denk hierbij aan een eenvoudige aanpassing zoals het verplaatsen van een button in een scherm. De functionaliteit van de button blijft gelijk alleen de plaats wordt anders. Op zo’n moment is een printscreen met daarin aangegeven wat de nieuwe locatie van de button wordt voldoende.
Echter als een story onderdeel is van een epic, zal er een overall view moeten zijn wat het doel is van de epic. Het is wenselijk om te beschrijven welke afhankelijkheden er zijn. Denk hierbij aan noodzakelijke volgorde van ontwikkeling. Als er een story is voor het inlezen van data en een story voor het verwerken van deze data, is het handig om eerst in te lezen en daarna de verwerking te realiseren. Als het hier data van een externe partij betreft, wil je wel weten hoe die data eruit ziet die aangeleverd wordt. Als het een XML betreft kan dit met behulp van een schema of dtd, maar er is wel een beschrijving van nodig. Een beschrijving als:
“Als administratief medewerker wil ik de betaal gegevens die door Bank A als XML bestand aangeleverd worden in ons financiële pakket kunnen inlezen zodat deze gegevens niet handmatig ingevoerd dienen te worden.”
is niet voldoende om te kunnen starten met ontwikkelen. Ook omdat deze gegevens bij een latere story naar alle waarschijnlijkheid nog gebruikt worden is het verstandig om ze in dit stadium al te beschrijven. En zo zijn er meer zaken die handig zijn om nu al uitgezocht / bekend te hebben voordat er ontwikkeld gaat worden.
Let wel, niet het hele traject hoeft nog in detail bekend te zijn. Ook kan het zijn dat er nog zaken met stakeholders afgesproken moeten worden. Zolang de lege plekken maar gevuld zijn op het moment dat er met de ontwikkeling van dat stuk gestart wordt.
Een hulpmiddel om te zien of iets klaar is, is de Definition of Ready (D.O.R.). Hierin beschrijft het team wat zij aan gegevens nodig hebben om te kunnen starten met een story. In de D.O.R. staat beschreven tot welke niveau het “Waarom”, “Wat” en “Hoe” van de story beschreven dient te worden om het op te kunnen pakken. De SCRUM master helpt het team bij het proces van het opstellen van de D.O.R.. Dit ook om te voorkomen dat de D.O.R. beperkt blijft tot Just Enough en niet tot een volledig uitgewerkt ontwerp.
Het doel van een sprint is ook niet om meteen kant en klare software op te leveren. Het doel is werkbare software opleveren. Daarnaast zullen er altijd wensen blijven van gebruikers. Hoe uitgebreid je je ontwerp ook maakt.
Ook is het geen probleem dat er zaken nog besproken worden tijdens het traject als dingen niet volledig duidelijk zijn. Dit overleg kan met de Product Owner of met een Business Analist of Functioneel Ontwerper. Dat hangt er vanaf welke afspraken er gemaakt zijn binnen de organisatie. De Product Owner heeft altijd het laatste woord. De Business Analist of Funtioneel Ontwerper geven alleen invulling aan de visie van de Product Owner.
Als ik een auto ga bouwen, wil je weten wat voor auto je gaat bouwen. Als ik een eenvoudige handkar maak, kan ik met twee wielen en het nodige hout en wat vindingrijkheid toe om de kar te maken. Een auto daarentegen zal ik willen weten wat voor soort auto het wordt, hoe groot wordt de auto, wat voor motor komt erin, etc.. Als je een grote pick-up wilt maken, moet je niet beginnen met een bodemplaat van een kleine stadsauto. Als je met de carrosserie komt bij de kleine bodemplaat, zou je eigenlijk weer opnieuw moeten beginnen met een nieuwe bodemplaat.
De beste vergelijking is te leggen met de bouw wereld. Als ik een schuur bouw weet ik dat ik aan een fundering die sterk genoeg is voor 1 bouwlaag voldoende heb. Het is over het algemeen niet nodig om te heien. Echter als ik een flat ga bouwen, moet ik meer weten. Het is van belang dat ik weet hoeveel verdiepingen de flat wordt. Ik kan niet na het bouwen van de eerste verdieping er achter komen dat de boel gaat verzakken en dan alsnog de fundering aanbrengen. Het afbreken van de bouwlagen en dan opnieuw een fundering leggen en opnieuw opbouwen zou een te tijdrovend proces zijn. De kleur van de tegels in het trappenhuis hoeft nog niet bekend te zijn. Deze kan bepaald worden op het moment dat de tegelzetter de tegels gaat bestellen.
We schrijven geen documentatie. Zo gaat dat in scrum.
“Working software over comprehensive documentation” is een van de regels uit het Agile Manifest. Deze regel wordt vaak geïnterpreteerd als “Documentatie is niet nodig want we hebben werkende software”. Documentatie hoeft niet uitgebreid te zijn maar er dient wel documentatie opgesteld te worden. Er zijn verschillende vormen van documentatie die hieronder vallen. Het ontwerp (functioneel en technisch), software documentatie (wat is er gedaan en waarom) en gebruikers documentatie (hoe werkt de software). De reden waarom een ontwerp / visie van belang is, is hierboven beschreven.
De voorkeur gaat uit naar werkende software. Bij traditionele ontwikkelmethoden wordt de helft van de tijd besteed aan het schrijven van documentatie. Deze tijd kan niet gebruikt worden om te ontwikkelen. Hou bij het schrijven daarom in gedachten of het document bijdraagt aan de ontwikkeling van de software, nu of in de toekomst, of dat het document opgesteld wordt voor het (ronde) archief.
We werken goed samen met de klant en daarom is een contract overbodig.
In een ideale wereld zou dit werken. Echter de wereld is niet altijd ideaal. Daarom is het van belang dat je ook afspraken maakt over wat je oplevert of welke inzet je levert. Je kunt deze afspraken ook Agile insteken. Denk hierbij aan het opdelen van de opdrachten in stories. Aan het einde van iedere sprint is de review waarbij de klant aanwezig is. De Product Owner geeft aan welke stories nog in de backlog staan en welke stories, gezien de velocitiy, er ongeveer in de volgende sprint opgenomen worden. De klant ziet dan hoeveel inspanning er nog nodig is om iets te realiseren en hoeveel van het budget al gebruikt is. Op dat moment kan de klant een Go of No Go geven. Een Go betekent dat de volgende sprint opgepakt wordt, een No Go betekent dat het project gestopt wordt. Het restant van het budget kan dan bijvoorbeeld gedeeld worden en de klant behoudt 50% en de ontwikkelende partij behoudt 50% van het restbedrag. Een reden voor een No Go kan zijn dat er alleen nog functionaliteit ligt die niet, meer, belangrijk is of waarbij de ontwikkelkosten niet in verhouding staan tot hetgeen de functionaliteit toevoegt. De klant is op deze manier minder kwijt aan ontwikkelkosten. Dit zijn afspraken die je vooraf dient te maken.
Maar ook, hoe ga je om met wijzigingen in behoeften. Als een story niet meer hoeft maar daarvoor in de plaats komt een andere story. Of er komen aanvullende stories. Wanneer is een story Done. Er zijn genoeg gevallen bekend waar het goed was dat hierover vooraf afspraken gemaakt waren. Vertrouwen is heel belangrijk. Communicatie met je klant ook. Maar er kunnen altijd situaties zijn waar afspraken op papier prettig zijn.
We zijn Agile want we doen alles volgens het boekje.
Als bedrijf zijnde, zijn we Agile want we doen alles volgens de regeltjes. Je komt steeds meer bedrijven tegen die zeggen dat ze volgens Agile werken want ze volgen het boekje op de letter. Echter houden ze dusdanig krampachtig vast aan deze regeltjes dat ze hierdoor niet meer flexibel zijn. Een voorbeeld hiervan is: er wordt in de sprint aan 1 grote story gewerkt door het hele team. Echter op dag 3 van de sprint van 2 weken wordt duidelijk dat deze story door een plotselinge verandering in de markt eigenlijk overbodig is. Maar ja, de sprint staat vast en zo staat het in de regels dus we maken de sprint af. Terwijl je op zo’n moment ook door de Product Owner de sprint kan laten afbreken en het team gaat een nieuwe sprint backlog opstellen.
Ook is het wel gebeurt dat het team de sprint backlog had afgewerkt. Alle stories waren Done. Heel mooi natuurlijk. Er waren nog 3 dagen over tot het einde van de sprint. Ik zou best een Euro willen krijgen voor de teams die op dat moment rustig “met hun armen over elkaar” zitten te wachten totdat de sprint afgelopen is. Want volgens de regels zijn we klaar want we hebben alle punten verbrand. Terwijl ook de volgende sprint alvast voorbereid kan worden of er kan, in overleg met de Product Owner, een story van de backlog opgepakt worden.
Binnen een Agile omgeving moet iedereen met scrum werken.
Scrum is geen doel, het is een middel. Maar maak als bedrijf wel een keuze !! Wil je als bedrijf Agile werken? Werk dan ook Agile en zeg niet alleen dat je Agile werkt terwijl je eigenlijk “mini watervalt”. Als je als bedrijf Agile wilt werken, betekend dat niet dat je moet Scrummen. Er zijn nog meer Agile manieren van werken die wellicht beter binnen jullie organisatie passen. Ook kan er binnen het bedrijf op verschillende Agile manier gewerkt worden als daar aanleiding voor is. Belangrijk is dat de keuze bewust gemaakt wordt en dat je de regels op een gezonde manier met gezond verstand toepast. Daarom wil ik aan het Agile Manifest nog 1 regel toevoegen:
- Gezond verstand boven regeltjes.