1. Waarom iteratief werken wint
Agile betekent letterlijk wendbaar. Het is geen gereedschapskist en geen methode, maar een manier van kijken naar werk waarvan je de uitkomst niet vooraf kent. Je zet niet eerst alles op papier om dat vervolgens twee jaar uit te voeren; je levert in korte stappen iets op dat werkt, kijkt wat het doet, en stuurt bij. Voordat je aan sprints en rollen begint, is het de moeite waard om te weten waar die overtuiging vandaan komt en wat hij met je planning doet.
Na dit hoofdstuk:
- Weet je waar het Agile Manifesto vandaan komt en wat erin staat.
- Ken je de vier waarden van het Manifesto en kun je ze in eigen woorden uitleggen.
- Begrijp je het verschil tussen iteratief en incrementeel werken.
- Kun je uitleggen waarom de projectdriehoek in agile omkeert.
- Herken je situaties waarin een klassieke aanpak de betere keus is.
Waar agile vandaan komt
In februari 2001 kwamen zeventien softwareontwikkelaars bij elkaar in een skiresort in Snowbird, Utah. Ze waren het zat. Softwareprojecten in de jaren tachtig en negentig liepen massaal uit de hand: budgetten verdrievoudigden, opleverdata schoven jaren op, en wat er uiteindelijk uitrolde was vaak niet wat de klant nodig had. In drie dagen tijd schreven ze het Agile Manifesto op: vier waarden en twaalf principes. Meer niet. Het woord agile kozen ze bewust, omdat het uitdrukt waar het om draait, namelijk snel kunnen reageren op verandering.
De oorzaak van al die mislukkingen was steeds dezelfde. Aan het begin van een project werd alles tot in detail vastgelegd. Daarna werkte een team maanden of jaren in afzondering. Pas bij de oplevering kwam de klant weer in beeld, en dan bleek dat de wereld intussen was doorgelopen. Agile is ontstaan in de softwarewereld, maar je vindt het inmiddels in marketing, HR, productontwikkeling en onderwijs. Overal waar je vooraf niet alles kunt overzien.
De vier waarden van het Agile Manifesto
Het Manifesto zet vier keer twee dingen tegenover elkaar. Niet om het rechterdeel waardeloos te verklaren, maar om te zeggen waar de meeste waarde zit.
Mensen en hun onderlinge interactie boven processen en tools. Een goed proces helpt, maar zonder goede samenwerking lost geen enkele tool je problemen op.
Werkende software boven uitgebreide documentatie. Werk je niet aan software, lees dan: een werkend product. Een dik handboek is geen bewijs van vooruitgang. Iets dat werkt en waarde levert, wel.
Samenwerking met de klant boven contractonderhandelingen. Een contract beschermt je, maar een goede relatie met je klant levert een beter eindresultaat.
Inspelen op verandering boven het volgen van een plan. Een plan geeft richting, maar als de werkelijkheid verandert, verander je mee.
Deze vier waarden zijn examenstof en het loont om ze letterlijk te kennen, inclusief het woordje "boven". Uit de vier waarden zijn twaalf principes afgeleid die het concreet maken; die komen in de volledige training aan bod.
Iteratief en incrementeel
Twee woorden duiken steeds op, en ze betekenen niet hetzelfde. Iteratief betekent dat je in herhalende cycli werkt. Je maakt een eerste versie, verbetert die, maakt een tweede versie, verbetert opnieuw. Iteratief werken gaat over verfijnen. Incrementeel betekent dat je in stukjes oplevert. Je bouwt niet eerst alles en lanceert dan, maar voegt steeds een nieuw, werkend onderdeel toe. Incrementeel werken gaat over uitbreiden.
De vuistregel is simpel: incrementeel is meer, iteratief is beter. In de praktijk doe je beide tegelijk. Je levert in kleine stappen een groeiend product op, en met elke stap verbeter je wat er al was op basis van feedback.
Een team van vijf mensen bij een reisorganisatie bouwt een nieuwe boekingsapp. In sprint 1 leveren ze een zoekscherm op waarmee je op bestemming kunt zoeken. Twaalf collega's testen het diezelfde week. In sprint 2 komt er een filter op prijsklasse bij: dat is incrementeel, want er is meer dat werkt. Tegelijk passen ze het zoekscherm aan, omdat uit de test bleek dat negen van de twaalf collega's de knop "zoeken" niet konden vinden op hun telefoon: dat is iteratief, want het bestaande werd beter. Na twee sprints van twee weken staat er iets dat je aan een echte klant kunt laten zien. Bij een klassieke aanpak had het ontwerp op dat moment nog in de goedkeuringsronde gezeten.
Waterval tegenover agile
De watervalmethode deelt een project op in fasen die elkaar opvolgen: analyse, ontwerp, bouw, test en oplevering. Elke fase moet af zijn voordat de volgende begint. De naam zegt het al: het water valt van trap naar trap en stroomt niet terug. Waarde ontstaat pas op het allerlaatste moment, bij de oplevering. Eén keer, aan het eind.
Bij een agile aanpak knip je diezelfde doorlooptijd in sprints, bijvoorbeeld vijf sprints van twee weken, en levert het team na elke sprint een werkend increment op. In plaats van één moment waarop waarde ontstaat, zijn er vijf. En daarmee ook vijf momenten waarop je merkt dat je ergens verkeerd zat.
Waterval is niet fout. Het werkt goed bij projecten met heldere, stabiele eisen: de bouw van een brug, de aanleg van een snelweg, een verhuizing. Daar weet je vooraf wat het moet worden en is teruggaan duur. Het knelt zodra de eisen onderweg verschuiven, want een wijziging in de testfase betekent terug naar het ontwerp.
De omgedraaide driehoek
Dit is het verschil dat je het vaakst in de praktijk zult voelen. In klassiek projectmanagement werk je met de projectdriehoek van scope, tijd en budget. De scope ligt vast: wat je oplevert is afgesproken. Tijd en budget zijn de knoppen waar je aan draait. Loopt het uit, dan duurt het langer of kost het meer, en de kwaliteit beweegt mee als sluitpost.
Agile draait die driehoek om. Tijd en budget liggen vast, want je werkt in vooraf afgesproken sprints met een vast team. De scope is juist de variabele. Je levert eerst de belangrijkste functionaliteit op en schuift minder belangrijke zaken door of laat ze vallen. Precies daarom is prioriteren in agile geen bijzaak maar de kern van het vak, en daarover gaat hoofdstuk 3.
Wil je weten of een organisatie echt agile werkt? Vraag wat er gebeurt als een sprint niet af komt. Klinkt het antwoord "dan lopen we een weekje uit", dan ligt de scope nog steeds vast en is er niets veranderd. Klinkt het antwoord "dan gaat het minst belangrijke werk terug naar de backlog", dan is de driehoek echt omgedraaid.
Wanneer agile niet de beste keus is
De winst van agile komt niet uit de methode maar uit het ritme: elke paar weken echte feedback in plaats van een handtekening onder een document. Een verkeerde aanname kost je daardoor weken en geen maanden. Maar er zijn situaties waarin die winst wegvalt.
Bij een scope die wettelijk is vastgelegd valt er weinig te prioriteren, en dan houd je alleen het extra overleg over. Opdrachtgevers die vooraf een totaalprijs voor een vaste scope willen, komen in de knel met een variabele scope. Een team dat niet wordt vrijgemaakt en tussen vijf projecten heen en weer springt, haalt geen enkele sprint. En in een keten waarin je afhankelijk bent van partijen die per kwartaal plannen, verliest je tweewekelijkse ritme zijn zin.
Of agile aanslaat, hangt vooral af van drie dingen. Er is een opdrachtgever die echt beslist en niet elke keuze doorschuift naar een stuurgroep. Het team werkt aan één ding tegelijk. En de leiding stuurt op opgeleverd resultaat in plaats van op bezetting en urenverantwoording.
Een gemeente met 90.000 inwoners laat een nieuw digitaal loket bouwen, begroot op 640.000 euro. Twee dingen lopen door elkaar. De wettelijke eisen rond digitale toegankelijkheid liggen vast: daar valt niets te prioriteren, die moeten er allemaal in. De gebruikerservaring ligt juist helemaal open, want niemand weet nog hoe een inwoner een verhuizing wil doorgeven. De projectleiding kiest daarom voor een hybride aanpak: PRINCE2 voor de besturing richting college en raad, met stages en go/no-go-momenten, en scrum voor de bouw van het loket zelf, in sprints van twee weken. De eerste drie sprints gaan alleen over verhuizen doorgeven; na sprint 3 blijkt uit een test met elf inwoners dat het formulier in twee schermen moet in plaats van vijf. Dat inzicht kostte zes weken. In het traject ervoor, dat volledig op waterval draaide, kwam hetzelfde soort inzicht pas na veertien maanden boven.
Pak een project uit je eigen werk dat is uitgelopen of anders liep dan verwacht.
- Lag de scope vast, of waren tijd en budget de harde grenzen? Wat bewoog er mee toen het knelde?
- Op welk moment was voor het eerst zichtbaar dat het mis zou gaan? En wanneer werd het besproken?
- Was er iets dat je na twee weken al had kunnen laten zien aan een gebruiker?
- Was er een opdrachtgever die zelf besliste, en werkte het team aan één ding tegelijk?
Schrijf je antwoorden in maximaal tien zinnen op. Je gebruikt ze in de volgende hoofdstukken.
Samenvatting
- Het Agile Manifesto werd in 2001 opgesteld door zeventien ontwikkelaars in Snowbird, Utah, en bestaat uit vier waarden en twaalf principes.
- De vier waarden: mensen en interactie boven processen en tools, werkend product boven documentatie, samenwerking met de klant boven contractonderhandelingen, en inspelen op verandering boven het volgen van een plan.
- Iteratief is beter maken via herhalende cycli; incrementeel is in stukjes opleveren. Agile doet beide tegelijk.
- Waterval levert waarde één keer, aan het eind. Agile levert na elke sprint een werkend increment op.
- De projectdriehoek keert om: bij traditioneel ligt de scope vast en bewegen tijd en budget mee, bij agile liggen tijd en budget vast en beweegt de scope mee.
- Agile past slecht bij een wettelijk vastgelegde scope, een vaste totaalprijs vooraf, versnipperde teams of ketens die per kwartaal plannen.
Een team levert in sprint 4 een nieuwe exportfunctie op en past tegelijk de zoekfunctie uit sprint 2 aan naar aanleiding van gebruikersfeedback. Hoe noem je die twee dingen?
Wat zegt de omgedraaide projectdriehoek over een agile project?
Welke van deze vier is een waarde uit het Agile Manifesto zoals hij er letterlijk staat?