Incepta@IT Projectmanagement

Tag: projectmanagement

  • Van waterval naar agile, wat verandert er écht?

    Van waterval naar agile, wat verandert er écht?

    hero afbeelding met de keuze tussen Waterval of Agile

    Voor veel opdrachtgevers wordt agile werken gezien als een garantie voor snelheid. Het team begint in sprints te werken, er ontstaat een backlog en de overige zaken worden vanzelf geregeld. In de praktijk vindt echter een van de belangrijkste wijzigingen juist plaats bij de persoon die het project in opdracht geeft.

    Wie dat mist, krijgt een team dat agile werkt onder een opdrachtgever die nog in de watervalmethode denkt en stuurt. Je stapt dan beide in de waterscrum-val. 

    Hieronder lees je wat de overstap van waterval naar agile betekent voor sturing, planning en opdrachtgeverschap, welke misvattingen het project juist kunnen vertragen en in welke situaties waterval gewoon de betere keuze blijft.

    Drie misvattingen over agile werken

    De weerstand tegen agile komt zelden voort uit de methode zelf. Meestal zit er bij personen of organisaties een beeld of gedachte achter dat niet klopt. Hieronder enkele gedachten over agile werken die je soms hoort maar die niet kloppen met de praktijk.

    • “Agile is vrijheid zonder structuur.” Scrum werkt met vaste timeboxes, vaste overlegmomenten en een heldere verdeling van verantwoordelijkheden (Scrum Guide 2020). DSDM legt tijd en budget vast en laat alleen de scope meebewegen (DSDM Handbook). De structuur zit op een andere plek dan in een watervalplanning, maar hij is er wel.
    • “Wie met agile start, moet alles agile doen.” Je kunt de projectfasering en governance plangedreven inrichten en de uitvoering iteratief laten lopen. Het Agile Practice Guide van PMI en de Agile Alliance beschrijft een dergelijke hybride aanpak als een volwaardige keuze.
    • “In een vlakke agile organisatie kun je geen carrière maken.” Agile schrijft geen platte organisatie voor. De Scrum Guide beschrijft verantwoordelijkheden binnen een team, geen organigram. Groei zit dan minder in een hogere plek in de lijn en meer in vakmanschap, bredere verantwoordelijkheid en rollen als product owner of agile coach.

    De opdrachtgever verandert het meest

    In een watervalproject legt de opdrachtgever aan de voorkant de requirements vast, keurt hij een planning met mijlpalen goed en bewaakt hij daarna of het budget toereikend blijft. Zijn werk zit vooral aan het begin en bij de fase-overgangen. In een agile project verandert die rol op drie punten.

    De rol van de opdrachtgever in een watervalproject en in een agile project
    Vraag Waterval Agile
    Waar stuurt de opdrachtgever op? Mijlpalen en planning Opgeleverde waarde per iteratie
    Wat legt hij vooraf vast? Gedetailleerde requirements Visie, doel en prioriteiten
    Wat bewaakt hij? Het vastgestelde budget De investering en wat die oplevert
    Wanneer is hij nodig? Bij de start en bij fase-overgangen Doorlopend, bij elke review en prioritering

    • Van mijlpalen naar waarde

      Een groen vinkje bij een mijlpaal zegt weinig over wat de organisatie ermee wint. In een agile project beoordeelt de opdrachtgever na elke iteratie werkende resultaten en beslist hij of de volgende stap nog de moeite waard is. Het eerste principe van DSDM is niet voor niets focus on the business need (DSDM Handbook).

    • Van vaste requirements naar een visie

      De opdrachtgever hoeft niet meer elk detail vooraf te bedenken. Hij schetst waar het project naartoe moet en laat de invulling groeien met wat team en gebruikers onderweg leren. DSDM heeft daar een eigen rol voor, de Business Visionary, die de visie van het project bewaakt en uitdraagt (DSDM, Roles and Responsibilities).

    • Van budget bewaken naar investering bewaken

      In DSDM liggen tijd en budget vast en beweegt de scope mee. De vraag voor de opdrachtgever is dan niet meer “past dit nog binnen het budget?”, maar “levert dit budget zo veel mogelijk op?”. MoSCoW-prioritering houdt de Must Haves veilig. DSDM adviseert daar niet meer dan zo’n 60 procent van de inspanning aan te besteden, zodat er ruimte overblijft voor tegenvallers (DSDM Handbook, MoSCoW Prioritisation).

    Wanneer waterval de betere keuze blijft

    Waterval heeft nog altijd een duidelijke plek, namelijk overal waar het werk voorspelbaar is. Het Cynefin-model van Snowden en Boone maakt precies dat onderscheid. In overzichtelijke situaties werk je met beproefde werkwijzen, in complexe situaties leer je door te proberen en bij te sturen (Harvard Business Review, 2007). Voor de eerste soort blijft een plangedreven aanpak vaak de betere keuze.

    • Doelen en requirements liggen vanaf de start vast. Bij een groot bouwproject, zoals een ziekenhuis, staat het ontwerp vast voordat de eerste paal de grond in gaat. Tussentijds bijsturen is daar kostbaar en zelden gewenst.
    • Routinematig werk. Het bouwen van een standaard productielijn volgt een bekend patroon. Iteraties voegen daar weinig toe, een beproefd plan wel.
    • Strikte compliance-eisen. Vragen toezichthouders of klanten vooraf om uitgebreide documentatie, dan sluit een plangedreven aanpak beter aan bij die verantwoording.
    • Vaste poortwachtersmomenten. Moet elke stap formeel zijn goedgekeurd voordat de volgende mag starten, dan werkt die structuur korte iteraties tegen.

    Wat de overstap echt vraagt

    Of de overstap van waterval naar agile slaagt, hangt minder af van het team dan van de opdrachtgever. Die moet leren sturen op waarde in plaats van mijlpalen, een visie neerzetten in plaats van een dichtgetimmerd pakket van eisen, de investering bewaken en de geleverde waarde meten in plaats van alleen kijken naar hoe het budget is gebruikt.

    Maar minstens net zo belangrijk is het stellen van één eerlijke vraag vooraf: past agile eigenlijk wel bij dit project, of levert een plangedreven of hybride aanpak meer op? Hoe je die afweging maakt, lees je in Projectmanagement in een veranderende omgeving.

    Staat jouw organisatie voor die overstap, of loopt een agile project vast op de rol van de opdrachtgever? Bespreek welke aanpak past bij jouw project.

    Plan een vrijblijvend gesprek
  • Technical debt: wat je nu laat liggen, betaal je later!

    Technical debt: wat je nu laat liggen, betaal je later!

    Technical debt zorgt ervoor dat je altijd later de rekening betaald

    Technical debt: wat je nu laat liggen, betaal je later!

    Een snelle oplossing die vandaag tijd bespaart, betaalt zich later terug met rente. Dat is technical debt. Het is de technische schuld die je opbouwt zodra je kiest voor wat op dat moment uitkomt in plaats van voor wat het probleem echt oplost. De rekening komt later, en meestal hoger dan de besparing van toen.

    Voor een projectmanager die geen architect is, klinkt technical debt al gauw als een probleem voor de techneuten. Dat is het niet. Het raakt precies waar jij verantwoordelijk voor bent, namelijk tijd, budget en kwaliteit. Wat het is, hoe je het uitlegt aan een opdrachtgever en wanneer je die schuld beter wél of juist níet aangaat, lees je hieronder.

    Wat technical debt is

    Technical debt is het verschil tussen de snelle oplossing en de goede oplossing. Kies je voor de snelle, dan leen je in feite tijd van de toekomst. Zolang de schuld openstaat, betaal je rente: elke wijziging kost meer moeite, elke koppeling wordt lastiger, en op een gegeven moment durft niemand het systeem nog aan te raken.

    Net als een financiële lening is technical debt niet per definitie fout. Een lening kan een verstandige zet zijn, mits je weet dat je hem aangaat en een plan hebt om hem af te lossen. Het gevaar zit in de schuld die je opbouwt zonder het door te hebben, waar niemand meer zicht op heeft.

    Hoe je het uitlegt aan een niet-technische opdrachtgever

    Vergelijk het met onderhoud aan een auto. Je kunt de olie nu niet verversen en versleten banden laten zitten. Dat scheelt vandaag geld. Maar loopt de motor vast of krijg je een ongeluk door die banden, dan ben je veel meer kwijt dan de onderhoudsbeurt ooit had gekost.

    Uitgesteld onderhoud in IT werkt hetzelfde. De besparing van nu is zichtbaar en concreet, de rekening later is groter maar nog onzichtbaar. Jouw taak in dat gesprek is die latere rekening zichtbaar maken vóórdat de opdrachtgever alleen naar de besparing van vandaag kijkt.

    Een voorbeeld uit de praktijk

    In een project moesten op grote schaal accesspoints worden vervangen. Op bepaalde plekken werd niet het juiste type geïnstalleerd, omdat dat op dat moment sneller voor handen was en goedkoper leek. Het netwerk deed het, dus op papier was de klus klaar.

    Later bleek de dekking op die plekken niet te voldoen. De accesspoints moesten alsnog worden vervangen door het juiste type, met alle bijkomende werkzaamheden opnieuw. De besparing van de eerste ronde verdween volledig in de tweede. Dit is technical debt in het klein: een keuze die op het moment zelf logisch leek, maar dubbel werd betaald.

    Wanneer technical debt een verstandige keuze is

    Soms is een schuld aangaan de juiste beslissing. Wachten op de perfecte oplossing kan meer kosten dan een bewuste, tijdelijke keuze nu.

    • Een harde deadline of regelgeving. Moet je op een vaste datum voldoen aan een wettelijke eis, dan is een goede tijdelijke oplossing beter dan een perfecte die te laat komt.
    • Een bewuste, tijdelijke keuze. Je kent het volledige beeld, weet welke schuld je aangaat en legt vast wanneer en hoe je hem aflost.

    Wanneer het juist niet verstandig is

    De schuld wordt riskant zodra je hem aangaat zonder het overzicht, of op een plek waar de gevolgen niet te overzien zijn.

    • Een keuze uit onwetendheid. Je mist het volledige beeld, maar besluit toch. Dan neem je een schuld die je niet kunt inschatten en dus ook niet kunt beheersen.
    • Rond beveiliging. Bij securitymaatregelen zijn de gevolgen van een snelle keuze te groot. Hier hoort altijd een goed doordachte afweging, geen kortere weg.

    Grip houden op je technische schuld

    Het verschil tussen verstandige en onverstandige technical debt zit niet in de schuld zelf, maar in of je hem kent. Maak elke bewuste tijdelijke keuze zichtbaar, leg vast waarom je hem maakt en wanneer je hem aflost. Zo blijft het een instrument in plaats van een verrassing die halverwege het project de kop opsteekt.

    Speelt dit in een lopend of aankomend project? Bespreek waar jouw technische schuld zit en hoe je hem beheersbaar houdt.

    Plan een vrijblijvend gesprek

  • Wendbaar projectmanagement in een veranderende omgeving: kies een methode als middel, niet als doel

    Veel IT-projecten beginnen met een keuze voor de methode. Agile, Scrum of PRINCE2, er wordt een aanpak gekozen, en die aanpak wordt vervolgens gevolgd. Tot het project vastloopt, niet omdat de techniek tekortschoot, maar omdat de methode niet paste bij wat het project werkelijk nodig had.

    Dat is een patroon dat ik regelmatig terugzie bij projectmanagement. Een organisatie wil snel kunnen inspelen op verandering, maar kiest voor een zwaar governance-framework dat elke beslissing vertraagt. Of een team werkt in sprints, terwijl externe afhankelijkheden en vaste contractmomenten een iteratieve werkwijze feitelijk onmogelijk maken. De methode wordt leidend, het projectresultaat wordt bijzaak.

    Overzicht van projectmanagement methoden Agile, Scrum en PRINCE2 naast elkaar.
    Afbeelding gegenereerd met Nano Banana2

    Elke methode lost een ander probleem op

    Agile, Scrum en PRINCE2 zijn geen concurrerende aanpakken — ze zijn ontworpen voor verschillende situaties.

    PRINCE2 biedt structuur, heldere rollen en expliciete beslismomenten. Dat is waardevol bij projecten met veel bestuurlijke lagen, vaste budgetten en formele verantwoording. Denk aan infrastructuurmigraties of overheidsprojecten waarbij elke fase goedkeuring vereist van meerdere stakeholders.

    Agile is ontworpen voor situaties waarin eisen nog niet volledig bekend zijn en aanpassingen verwacht worden. Productontwikkeling waarbij de eindgebruiker gedurende het traject actief meedenkt, is daarvoor een voor de hand liggend voorbeeld.

    Scrum als specifieke invulling van Agile werkt het best in teams die zelforganiserend zijn en waarbij de doorlooptijd van feedbackloops kort is. Dat veronderstelt een bepaalde volwassenheid in het team en minimale externe afhankelijkheden.

    Het probleem ontstaat wanneer een aanpak wordt gekozen op basis van voorkeur of gewoonte, in plaats van op basis van de kenmerken van het project.

    Visuele tabel met Agile, Scrum en PRINCE2 op de assen: stabiliteit van eisen, beslissnelheid, type afhankelijkheden. Maakt de methodekeuze direct inzichtelijk.

    Wat de keuze voor een methode bepaalt

    Een aantal vragen helpt om de juiste aanpak te bepalen:

    Zijn de eisen stabiel of juist veranderlijk? Als de scope van een project bij de start grotendeels vaststaat, biedt een meer plangedreven aanpak houvast. Zijn de eisen nog onzeker of zullen ze gedurende het project verschuiven, dan vraagt dat om kortere cycli en frequentere afstemming.

    Wie heeft beslissingsbevoegdheid en hoe snel? Een organisatie met trage besluitvorming en meerdere bestuurlijke lagen werkt slecht met een aanpak die dagelijkse of wekelijkse sturing vereist. Scrum veronderstelt dat een product owner daadwerkelijk kan beslissen, dat is lang niet altijd het geval.

    Wat is de aard van de afhankelijkheden? Externe leveranciers, vaste contractmomenten en gekoppelde systemen beperken de speelruimte van een iteratieve aanpak. Een mixed-methods aanpak, waarbij de buitenste projectlaag plangedreven is en interne deeltrajecten iteratief, is in die gevallen vaak realistischer.

    Hoe volwassen is het team? Agile werken vraagt zelfsturing en intrinsieke verantwoordelijkheid. In teams waar dat nog niet aanwezig is, leidt een Agile aanpak niet tot snelheid maar tot onduidelijkheid.

    Methoden combineren in de praktijk

    In IT-projecten waarbij ik als consultant betrokken ben, is een hybride aanpak vaak de realiteit. De projectfasering en governance volgen een plangedreven structuur: heldere mijlpalen, vaste rapportages, expliciete go/no-go-momenten. Binnen die kaders werken de uitvoerende teams iteratief, met korte sprints en regelmatige afstemming met gebruikers.

    Dat vraagt om bewuste keuzes per projectlaag. Welk deel van het project heeft structuur en voorspelbaarheid nodig? Welk deel heeft juist ruimte voor aanpassing? Die vragen staan los van methodieken — ze gaan over de aard van het werk.

    De valkuil is dat hybride aanpakken vrijblijvend worden. “We doen iets van Agile en iets van PRINCE2” is geen keuze, het is het vermijden van een keuze. Een bewuste hybride aanpak vraagt om expliciete afspraken over welke principes gelden op welk niveau, wie welke beslissingen neemt en hoe de verbinding tussen de lagen wordt geborgd.

    Diagram met een buitenste plangedreven projectlaag en binnenste iteratieve uitvoeringslag. Visualiseert het hybride model concreet.

    De projectmanager als methode-onafhankelijke professional

    Een goede projectmanager is niet iemand die één methode uitstekend beheerst. Het is iemand die de kenmerken van een project kan lezen en op basis daarvan een aanpak kiest die past.

    Dat vraagt kennis van meerdere methoden, maar meer nog het vermogen om de organisatorische en menselijke context te beoordelen. Een project dat technisch gezien geschikt is voor Scrum, maar waarbij de opdrachtgever elke sprint goedkeuring wil verlenen op de backlog, werkt in de praktijk niet als Scrum. De formele aanpak aanpassen aan die realiteit is geen zwakte — het is professioneel oordeel.

    Wat dit betekent voor je aanpak

    Niet iedere situatie is gelijk, maar een aantal uitgangspunten helpt om methodekeuzes te verankeren in de praktijk.

    Beoordeel het project, niet de voorkeur. Kies de aanpak op basis van de stabiliteit van eisen, de beslisstructuur en de aard van de afhankelijkheden — niet op basis van wat je gewend bent of wat de organisatie eerder heeft gebruikt.

    Maak hybride afspraken expliciet. Als je methoden combineert, leg dan vast welke principes gelden op welk niveau. Onduidelijkheid hierover leidt tot conflicterende verwachtingen tussen teams en opdrachtgevers.

    Toets de aanpak regelmatig. Een methode die aan het begin van een project passend was, hoeft dat halverwege niet meer te zijn. Bouw evaluatiemomenten in om de aanpak zo nodig bij te stellen.

    Betrek stakeholders vroeg bij de methodekeuze. Een aanpak die intern logisch lijkt, maar niet aansluit bij de verwachtingen van de opdrachtgever of eindgebruikers, creëert frictie die het project vertraagt. Vroegtijdige afstemming voorkomt dat.

    Methode volgt project, niet andersom

    IT-projecten falen zelden door het kiezen van de verkeerde methode op papier. Ze falen doordat de methode niet is afgestemd op de werkelijkheid van het project: de organisatiestructuur, de beslissnelheid, de aard van de samenwerking en de mate van onzekerheid.

    Flexibiliteit in methodekeuze is geen gebrek aan discipline. Het is het gevolg van een heldere analyse van wat een project nodig heeft. Die analyse is de eerste verantwoordelijkheid van een projectmanager — voordat er ook maar één sprint gepland of één projectplan geschreven is.

    Wil je sparren over welke aanpak past bij jouw IT-project of organisatie? Neem contact op, ik denk graag met je mee.