Scrum is niet meer weg te denken uit de softwareontwikkeling. Het is niet de enige, maar wel de bekendste agile ontwikkelmethode. Een ander voorbeeld is DevOps. Hoewel de basis voor agile ouder is, wordt de term Scrum al ongeveer sinds 1995 gebruikt. Sindsdien zijn veel softwareprojecten overgestapt naar een agile ontwikkelmethode. Voor infrastructuurprojecten blijven echter watervalmethoden als Prince-II dominant. Hoe komt dat?
De basis van agile ontwikkeling is het continu blijven aanpassen van doelen en planning door verandering in vraag en voortschrijdend inzicht. In plaats van een aan het begin van het project vastgesteld plan, wordt er gebruikgemaakt van iteratieve ontwikkeling. Bij een op een watervalmethode gebaseerd project staat het doel vast en wordt er geschoven met tijd, kosten, en - helaas maar al te vaak - kwaliteit om dat doel te bereiken. Bij een agile methode staan kwaliteit, tijd en kosten vast, maar het doel is variabel.
Succesvoller met agile
Voor een doorgewinterde Prince-II projectleider klinkt dat als een recipe for disaster: hoe kun je een project succesvol afronden als je niet weet wat je doel is? Toch geven veel organisaties die zijn overgestapt op bijvoorbeeld Scrum aan dat hun projecten succesvoller zijn en de kwaliteit van hun producten hoger. Hoe komt dat? Bij een watervalgebaseerd project is het doel in feite óók een moving target. De methode is er echter op gebaseerd om dit te negeren. Natuurlijk zijn change requests mogelijk, maar dit is vaak voor zowel klant als project niet wenselijk. Aanpassing van de deliverables van het project betekenen immers aanpassingen in planning en budget.
Tijdens een project leren wat nodig is
Het is vaak een onmogelijke opgave om aan het begin van een project al precies te weten wat er aan het einde van het project gewenst is. Hoe langer het project duurt, hoe lastiger het wordt en hoe groter de kans dat eisen en wensen – als ze aan het begin al correct waren geïdentificeerd – veranderen. Vaak zelfs onder invloed van het project. Tijdens de ontwikkeling of het testen - of erger: na implementatie - komen er zaken naar boven waar eigenlijk nooit goed over is nagedacht.
In een agile ontwikkeltraject is het dan ook van belang om niet teveel van te voren te plannen en alles duidelijk te willen hebben, maar juist tijdens het project te leren wat nodig is.
Focus op kwaliteit en niet op tijd
Omdat niet aan het begin van het project geprobeerd wordt álles duidelijk te krijgen is rework soms onvermijdelijk. Werk dat al eens gedaan is, wordt opnieuw gedaan omdat het eerste resultaat niet (meer) voldoet. Dat klinkt onwenselijk: waarom zou je opnieuw doen wat je al gedaan hebt? Agile methoden bekijken dit van de andere kant: waarom zou je iets niet opnieuw doen, terwijl je weet dat het niet voldoet? Opnieuw dus de focus op kwaliteit en niet op tijd.
Natuurlijk zit hier een risico aan vast: het kan altijd beter. Gelukkig is hier in de ontwikkelmethode rekening mee gehouden. In Scrum werken de ontwikkelaars in principe altijd aan datgene wat het meeste oplevert voor de klant. Het voor de derde keer herschrijven van een stuk code om het nog nét iets beter te doen leidt zelden tot veel toegevoegde waarde. Het staat dan ook niet hoog op de prioriteitenlijst (backlog in Scrum).
Agile in infrastructuurontwikkeling
In infrastructuurprojecten zien we Scrum vooralsnog minder dan in softwareontwikkelingstrajecten. Een belangrijke mijlpaal in een infrastructuurproject is vaak de hardwareselectie. Daar gaat een traject aan vooraf waarin eisen en wensen worden geïnventariseerd en vastgelegd. Dat moet ook wel, want de hardware is vaak een flink deel van het budget van een infrastructuurproject. Een corerouter of -switch kan met gemak enkele tonnen kosten. Een accesswitch van 500 euro kost ook een half miljoen als je er 1000 van nodig hebt.
Kortom: een verkeerde hardwareselectie kan een gigantische strop voor een project tot gevolg hebben.