Snel beginnen is iets anders dan snel eindigen in de IT
Wanneer gaan we nou eens beginnen? Opdrachtgevers zijn aanvankelijk wel eens nerveus als ze met ons samenwerken. Dat nemen we ze ook niet kwalijk, want in de loop van de jaren is de gekke, hardnekkige perceptie ontstaan, dat het werk pas is begonnen als de eerste code is geschreven. De race naar een Minimum Viable Product start direct, zonder dat iemand aan de IT-kant de tijd en ruimte neemt of krijgt om even afstand te nemen en goed na te denken over het te bouwen systeem. Agile-consultant Maarten Dalmijn omschrijft het treffend: “Delivering features doesn’t mean you are delivering value. Just like telling a joke doesn’t mean people will laugh. It’s all about how customers receive your feature and if it helps them to meet their goals.”[1]
Iets te weten komen over dat doel en nadenken over een passende oplossing vergt voorbereiding, maar veel Scrum-teams zijn Agile gaan gebruiken als excuus om zorgvuldige planning en voorbereiding volledig over te slaan. Ze zeggen: “Je kunt niet alles vooraf weten” en daar hebben ze gelijk in. Je kunt niet álles vooraf weten, maar er zijn heel veel dingen die je wel vooraf kunt weten. Of die je op een goedkopere manier kunt ontdekken dan experimenteren en bijsturen met je voltallige dure development team. Als je op vakantie gaat naar een dorp waar je nog nooit bent geweest, stap je ook niet in een willekeurige trein op goed vertrouwen dat je door onderweg bij te leren er uiteindelijk wel zal komen. Dat kost veel te veel tijd en is veel te duur. Voor software is dat niet anders. Je kunt wel snel beginnen door direct in de development trein te stappen, maar daardoor kom je echt niet sneller aan op je eindbestemming.
Juist door de tijd te nemen om precies te onderzoeken wat je doel is, ontdek je ook hoe je er op de beste en snelste manier kunt komen. En natuurlijk verandert er onderweg nog veel. Dat is als je op vakantie gaat niet anders. Je krijgt een klapband, de kinderen willen drie keer naar McDonalds en er is een ongeluk gebeurd waardoor je kilometers om moet rijden. Dan denk je ook niet: had ik maar nooit van tevoren uitgezocht waar we naartoe gingen. Dat geldt voor software-ontwikkeling ook. Alleen met een gedegen voorbereiding kun je flexibel en gecontroleerd bijsturen.
Daar komt nog bij: hoef jij maar één keer op de kaart te kijken en kun je dan (zonder navigatie) naar Zuid-Frankrijk rijden? Waarschijnlijk niet, dus waarom zou dat met complexe IT-projecten wel zo werken? Voorbereiden heeft alleen maar zin als je die voorbereiding op een toegankelijke, ondubbelzinnige manier vastlegt, zodat je er op een later moment nog iets aan hebt. Natuurlijk veranderen er gaandeweg dingen, maar je moet eerst scherpstellen om te kunnen schieten op een bewegend doel. Dankzij de voorbereiding heb je juist grip op de verandering, want je weet precies wat plan A was en precies wat plan B is en wat de verschillen tussen de twee zijn. Zonder grip en overzicht lijken veranderingen vaak gigantisch, terwijl het meestal best meevalt als je er even induikt en het uitwerkt. En als het niet meevalt, dan ben je op tijd om te beslissen om de verandering toch maar niet door te voeren. Dankzij voorbereiding bied je een opdrachtgever veel meer regie en keuzemogelijkheden. Kortom: door iets minder “Agile” overal halsoverkop in te duiken, wordt het totale project juist méér “Agile”.
Ben je nieuwsgierig naar hoe je op een gecontroleerde en gestructureerde manier om kan gaan met veranderingen in je IT-project? Lees dan “De Happy Sprint Machine”. Het beschrijft een methode voor software-ontwikkeling die zo logisch is dat je straks niet meer snapt waarom het ooit anders is gedaan.
[1] Dalmijn, M. (2021, 5 april). Why roadmaps reflect the level of agile inadequacy. Maarten’s Newsletter. https://mdalmijn.com/p/why-roadmaps-reflect-the-level-of-agile-inadequacy
