The development process Part 1

Have you read the previous blog yet?: Creating ethical software, part 2?

Het Booking System team is blij dat Alex meer tijd aan hen en de applicatie zal besteden. Enkele weken geleden is er een product owner aan het team toegevoegd. Hoewel zij en het team goed met elkaar kunnen samenwerken, heeft haar komst geleid tot een toename in de druk vanuit het management om nieuwe functionaliteiten te leveren.

“De laatste tijd missen we veel deadlines voor nieuwe features,” zegt ze tegen Alex. “Ik heb urenlang plannen geschreven voor de applicatie. Elke keer heb ik met het team besproken of de geplande deadlines haalbaar waren, en telkens verzekerden ze me dat dat zo was. Ik begrijp niet wat we verkeerd doen.”

Alex knikt. “Dat klinkt frustrerend. Volgen jullie een specifieke softwareontwikkelmethode?”

De product owner lacht. “Ik denk dat we er op dit moment twee tegelijk volgen. Het team wil werken met scrum - of in elk geval met de meeste onderdelen ervan - maar mijn manager verwacht dat ik releases plan met specifieke features, zodat we onze andere ontwikkelteams kunnen informeren over aankomende wijzigingen.”

Alex denkt even na. “Laat me gewoon weer wat user stories oppakken en aan de slag gaan. Als ik iets merk aan ons proces dat relevant lijkt, stuur ik je daarover een e-mail. Klinkt dat goed?”

“Oh, het zou fantastisch zijn als je meteen kunt beginnen met coderen,” zegt de product owner met een glimlach. “Er is namelijk een aankomende deadline…”

Waarom hebben we een plan nodig?

“Wij gaan de deadline niet halen!” Die zin verdient een vaste plek op de bingokaart van elk softwareproject. Maar waarom doen we het eigenlijk? Waarom stellen we deadlines? Waarom proberen we het onplanbare te plannen?

Een softwareontwikkelplan vervult meerdere cruciale functies, ook al is de exacte ontwikkelduur lastig - of beter gezegd: onmogelijk - nauwkeurig in te schatten, zeker aan het begin van een project. Het plan geeft richting en houvast, helpt bij het toewijzen van middelen (zoals hoeveel ontwikkelaars er nodig zijn) en bij het beheersen van risico’s. Het communiceert de bedoeling van het team naar zowel interne als externe betrokkenen, stimuleert tijdsbeheer, moedigt het opdelen van taken aan en helpt bij het stellen van prioriteiten en doelen. Een goed plan bepaalt bovendien kwaliteitsverwachtingen en voorkomt dat de scope ongemerkt wordt uitgebreid. Ten slotte maakt een plan continue verbetering van schattingen en zelfs ontwikkelprocessen mogelijk.

Veel mensen denken dat het hoofddoel van een plan is om een tijdsbestek te geven: wanneer beginnen we en wanneer zijn we klaar? In mijn ogen is dat een compleet verkeerd uitgangspunt. Ik heb deze tekst geschreven om de waarheid te illustreren van een uitspraak die ik ooit online las: “Plans are worthless, but planning is everything.”

Hoewel een ontwikkelplan structuur en richting biedt, weet iedereen die in software werkt dat flexibiliteit essentieel is. Agile-methodologieën benadrukken bijvoorbeeld dat aanpassing aan verandering belangrijker is dan vasthouden aan een star plan. Plannen moeten worden gezien als levende documenten die zich ontwikkelen naarmate het project vordert en nieuwe informatie beschikbaar komt. Het doel is niet om het perfecte plan te hebben, maar een strategische leidraad die het team helpt de complexiteit van softwareontwikkeling te navigeren. Zelfs traditionele watervalmethoden zoals Prince2 kunnen nuttig zijn, zolang iedereen begrijpt dat het plannen zelf belangrijker is dan het vasthouden aan de geschatte deadline.

De scheuren in de waterval

Over de watervalmethode gesproken: er was een tijd in de geschiedenis van softwareontwikkeling waarin de traditionele watervalmethodiek de norm was. Stel je een productieassemblagelijn voor, zorgvuldig gepland van begin tot eind.

Een goed voorbeeld van een watervalaanpak is Prince2 (PRojects IN Controlled Environments). Het is te vergelijken met het nauwkeurige labjournaal van een wetenschapper. Het is een uitgebreid raamwerk met duidelijke projectmanagementprincipes en -processen, dat ervoor zorgt dat geen enkel belangrijk element over het hoofd wordt gezien tijdens de levenscyclus van een project.

Softwareprojecten, vooral complexe, kunnen snel onoverzichtelijk worden. Belangrijke stappen worden gemakkelijk gemist, wat leidt tot vertragingen, scope creep of tegenvallende resultaten. Zelfs in complexe omgevingen kan Prince2 dienen als een nuttige checklist om een project van begin tot eind te begeleiden. Het biedt een gestructureerde aanpak met duidelijke rollen, fasen en processen, zodat niets tussen wal en schip valt.

Neem bijvoorbeeld een softwareteam dat een e-commercewebsite moet bouwen. Ze besluiten Prince2 te gebruiken om het project op koers te houden. Aan het einde van elke sprint evalueren ze hun voortgang aan de hand van de Prince2-checklist:

Initiatie: controleren of doelen, scope, belanghebbenden en risico’s goed zijn gedefinieerd.
Planning: nagaan of het sprintplan aansluit bij het overkoepelende projectplan en of middelen goed zijn verdeeld.
Uitvoering: verifiëren dat de taken uit de sprint zijn voltooid, de code getest is en de features zijn geïntegreerd.
Monitoring en controle: zorgen dat voortgang wordt gevolgd, risico’s worden beheerd en waar nodig wordt bijgestuurd.
Afronding: controleren of de oplevering aan de gestelde criteria voldoet en of de documentatie up-to-date is.

Door Prince2 consequent te gebruiken, verzekert het team zich ervan dat geen enkel belangrijk aspect wordt vergeten. Het is alsof je je onderzoeksapparatuur zorgvuldig controleert voor elke proef om betrouwbare resultaten te garanderen.

Toch zal het werken met Prince2 als enige methode onvermijdelijk leiden tot frustratie. Naarmate softwarecomplexiteit toeneemt en technologie zich sneller ontwikkelt, is gebleken dat de watervalaanpak niet goed past bij moderne softwareontwikkeling. Agile-methodologie is de nieuwe standaard geworden, met verschillende varianten die teams helpen transparanter en efficiënter te werken.

Wanneer zelfs Agile begint te barsten

Agile ontstond uit noodzaak, als reactie op de zwaarte van de watervalaanpak. Net als een wetenschapper die experimenten aanpast aan veranderende omstandigheden, draait Agile om flexibiliteit, iteratie en samenwerking. In plaats van een volledig project van tevoren tot in detail uit te tekenen, moedigt Agile aan om het op te delen in kleine, beheersbare stukken - mini-experimenten. Elke iteratie levert een tastbaar resultaat op, wat een cultuur van reflectie, aanpassing en continue verbetering bevordert. Zo biedt Agile veel van de voordelen van plannen, maar vervangt het ene grote plan simpelweg door vele kleine plannen. En elk van die plannen heeft zijn eigen uitdagingen, afhankelijk van de gekozen Agile-variant.

Hoewel Agile een broodnodige verandering bracht, is ook deze aanpak niet immuun voor overdaad. Soms wordt het proces zelf te complex, met te veel variabelen die om aandacht strijden. De kunst ligt in het vinden van balans, net als een wetenschapper die zijn meetinstrumenten zorgvuldig afstelt.

Scrum-rituelen zoals de Daily Standup, Sprint Planning en Retrospectives bieden waardevolle structuur. Maar zodra deze bijeenkomsten ook maar iets verkeerd worden uitgevoerd (of simpelweg niet goed passen bij het team en de context), leiden ze snel tot tijdverspilling en informatie-overload, waardoor de productiviteit stagneert. De Scrum Guide benadrukt terecht dat het niet gaat om rituelen volgen om het volgen, maar om een dynamische omgeving te creëren waarin processen de creativiteit versterken in plaats van belemmeren. Die balans vinden blijft echter lastig.

Vergaderingen stroomlijnen: kwaliteit boven kwantiteit

Hier schuilt een veelvoorkomend probleem in vrijwel alle methodieken: vergaderingen. Te lange, overbodige of stille vergaderingen zijn een plaag binnen softwareontwikkeling. Ze slokken tijd op die beter besteed kan worden aan coderen, testen of samenwerken.

Communicatie en overleg zijn belangrijk, dat blijkt ook uit Alex’ verhaal, maar ze moeten kort en doelgericht zijn, met zo min mogelijk deelnemers.

Zorg ervoor dat elke vergadering een duidelijk doel, relevante deelnemers en een afgebakende agenda heeft. Kwaliteit boven kwantiteit.

En bovenal: behandel iedereen in de vergadering als gelijkwaardig. Mensen met een hogere positie zouden de vergadering mogen voorzitten, maar niet hoeven deelnemen aan de discussie, of zelfs helemaal niet aanwezig hoeven zijn. Anders veranderen vergaderingen al snel in gesproken e-mails.

De Daily Standup binnen Scrum is een goed voorbeeld van een efficiënte vergadering. Mits goed uitgevoerd is het een kort en gestructureerd overleg tussen gelijken waarin iedereen in enkele minuten deelt wat ze hebben gedaan, welke obstakels er zijn en wat ze die dag gaan doen. Zo blijft het team op één lijn zonder tijd te verspillen. Dat verklaart waarom veel bedrijven die niet volledig volgens Scrum werken (of slechts “Scrum in naam”) de Daily Standup toch behouden: het is een toonbeeld van een goed uitgevoerde vergadering.

Scope versus kosten versus tijd

Met efficiëntere planning en vergaderingen kunnen we transparantie en effectiviteit vergroten, maar die transparantie reikt niet ver genoeg om maanden- of jarenlange deadlines te waarborgen. Betekent dat dat deadlines onvermijdelijk gemist worden? Softwareontwikkeling verzet zich tegen starre, universele plannen. Het vraagt van ontwikkelaars en managers om continu te balanceren met onzekerheid. Een eindeloze dans. Of toch niet?

Voordat we verdergaan: wat bedoel ik met een deadline? Kijk eens naar de afbeelding hieronder. Misschien ken je die al, maar zo niet, laat me het dan even uitleggen.

Het projectmanagementdriehoek, ook wel de “ijzeren driehoek” of de “triple constraint” genoemd, toont de onderlinge relatie tussen drie kernfactoren van elk project: tijd, kosten en scope.

Tijd verwijst naar de looptijd van het project - de duur die nodig is om het te voltooien. In softwareontwikkeling omvat dit mijlpalen, ontwikkelfases, testen en implementatie. Teams die een deadline missen, denken vaak dat ze te weinig tijd hadden.

Kosten hebben betrekking op de financiële middelen van het project: personeel, apparatuur, softwaretools, infrastructuur en andere uitgaven. Wanneer een bedrijf een deadline wil halen, kan het, als het dat de moeite waard vindt, vaak extra middelen inzetten.

Scope verwijst naar het werk dat moet worden gedaan om het eindproduct te leveren, inclusief functies, eisen en gebruikersinteracties. De omvang bepaalt wat er precies gebouwd wordt. Een team kan de scope vergroten of verkleinen, wat directe gevolgen heeft voor tijd en kosten.

In het midden van de driehoek staat kwaliteit. Dat verwijst naar de mate waarin het product voldoet aan zijn doel en verwachtingen. Als de gewenste kwaliteit omhoog moet, moeten tijd, kosten of scope worden aangepast. Een team mag nooit de kwaliteit onder het minimale niveau laten zakken om een deadline te halen.

De driehoek toont hoe elke verandering in één factor invloed heeft op de andere twee. Meer functionaliteit betekent vaak meer tijd of geld, terwijl minder tijd kan betekenen dat er minder features of lagere kwaliteit wordt geleverd.

De uitdaging is om balans te vinden tussen deze factoren en een product te leveren met acceptabele kwaliteit. Als een project een strakke deadline heeft, moet de scope wellicht kleiner worden of moeten extra middelen worden ingezet. Een deadline is dus geen simpele datum; het is de uitkomst van een evenwicht tussen tijd, kosten en scope.

Onvermijdelijke deadlines

Zijn deadlines, gezien de definitie hierboven, dan zinloos? Aan het begin van een project: ja. Ze zijn niet meer dan giswerk, als het dat al is. Maar let op wat er gebeurt naarmate een project vordert, vooral wanneer het team en de requirements zich beginnen te stabiliseren.

In de beginfase van een softwareproject begint het team aan een ontdekkingsreis. Die eerste fase is vaak onstuimig. Nieuwe teamleden leren elkaar kennen, persoonlijkheden botsen, functies zijn nog vaag of onbekend, en ideeën knallen tegen elkaar in een storm van creativiteit en conflict. Wanneer een team de kans krijgt om die uitdagingen rechtstreeks aan te gaan, ontstaan sterke banden, wordt het projectdoel duidelijker en groeit een gedeeld gevoel van richting.

Als het stof is neergedaald, vindt er een opmerkelijke verandering plaats. Het team beweegt naar de ‘norming’- en ‘performing’-fase. Communicatie verloopt vloeiender, conflicten worden constructief opgelost en rollen worden duidelijk gedefinieerd. In deze harmonieuze fase wordt het team een goed geoliede machine die samenwerkt aan gedeelde doelen.

Gaandeweg verandert planning in een plan. Enerzijds neemt de hoeveelheid werk geleidelijk af, en daarmee vaak ook de complexiteit. Althans, als je kwaliteitssoftware bouwt. Anderzijds zorgt de toegenomen stabiliteit voor meer transparantie, waardoor het mogelijk wordt om een realistische deadline te bepalen. Niet eenvoudig, maar mogelijk. Voor deze “magie” is het echter cruciaal dat het project niet terugvalt in de chaotische beginfase. Zulke terugvallen kunnen allerlei oorzaken hebben, waar we in deel 9 verder op ingaan. Als dat gebeurt, verliest de geplande deadline onmiddellijk haar waarde, en moet het team weer terug naar het plannen van plannen om een nieuwe realistische datum te bepalen.

Van processen naar samenwerking

Een paar weken later had Alex al meerdere e-mails gestuurd naar de Product Owner. Daarin stelde Alex voor om niet alleen naar tijd te kijken, maar ook naar budget en scope, en om te onderzoeken waarom het team niet zo snel ontwikkelde als verwacht. Al snel merkte Alex dat de mails waren doorgestuurd naar andere product owners en projectmanagers. De inhoud had een reeks gesprekken in gang gezet binnen E-train. De verschillende product owners en projectmanagers realiseerden zich dat ze allemaal met vergelijkbare problemen kampten en waren geïntrigeerd door Alex’ oproep om hun aanpak te herzien.

Alex’ idee om de onderliggende oorzaken van gemiste deadlines aan te pakken sloeg aan. De product owners herkenden dat voortdurende veranderingen in teamsamenstelling, prioriteiten en focus ervoor zorgden dat hun teams geen stabiele, transparante eenheden konden vormen. Dit gebrek aan stabiliteit leidde tot verwarring, inefficiëntie en uiteindelijk gemiste doelen.

Vandaag hebben de product owners besloten om samen te komen voor een gezamenlijk overleg. “Hopelijk niet te lang,” grapt Alex bij het ontvangen van de uitnodiging. De product owners en projectmanagers verzamelen zich in een vergaderruimte, klaar om hun problemen te bespreken en samen een strategie te bedenken.

“Ik wil Alex bedanken voor het aankaarten van dit belangrijke punt,” begint een van de product owners. “Het is duidelijk dat onze projecten en teams last hebben van instabiliteit, en dat dit onze capaciteit om op tijd te leveren aantast.”

Een projectmanager vult aan: “Ik merk dat elke keer wanneer er mensen in mijn team wisselen of de prioriteiten veranderen, dat direct ten koste gaat van de productiviteit en de prestaties.”

Alex neemt het woord om het doel van de meeting scherp te stellen. “Ik denk dat we veel betere resultaten kunnen behalen als we prioriteit geven aan stabiele en transparante projecten en teams.”

“Het is een sterke analyse,” zegt een andere projectmanager, voordat hij met een cynische ondertoon toevoegt: “Maar wat kunnen we dan echt anders doen? Het is niet alsof ik blij ben dat het management constant mijn prioriteiten en teamleden door elkaar gooit.”

Even blijft het stil. Daarna beginnen de mensen in de ruimte te overleggen over hun opties.