De ervaring leert dat een Agile benadering bij veel projecten tot verbeteringen leidt. De flexibiliteit en snelheid van Agile projectmanagement levert vaak betere projecten op en is –niet onbelangrijk- ook een prettiger manier van werken voor projectteams. In het enthousiasme om het Agile projectmanagement in te voeren lopen organisaties toch soms vast. Was Agile of Scrum dan eigenlijk wel zo’n goed idee? Terug naar een watervalbenadering is geen optie, omdat daarmee de oude bekende watervalproblemen ook weer terugkeren. Wat dan wel? Bij drie organisaties bleek een andere projectmanagement methode dan Agile of Waterval beter te passen.
Staged Delivery
Een grote dienstverlenende organisatie uit de transportsector had besloten om “Agile” te gaan werken. De projectleiders en een deel van de projectleden waren opgeleid in de Scrum methode. Na ongeveer een jaar werd er geconcludeerd dat het niet werkte. Na een aantal gesprekken en een workshopdag bleek dat de deelnemers allemaal een eigen versie van Scrum toepasten. Dit kwam omdat de Scrum methode meestal niet goed paste bij de projecten. Het ging bijvoorbeeld om veel infrastructuurprojecten die weliswaar in fases opgeleverd konden worden, maar waarbij een gedegen ontwerp toch echt nodig was en waarvan tijdens de bouw niet veel afgeweken kon worden.
De oplossing was een bewuste keuze voor een projectmanagement aanpak voorafgaand aan een project. Voor een enkel project was dat Scrum, maar meestal toch ook een andere aanpak. Een projectmanagement methode die goed bij veel van de projecten van deze organisatie past bleek Staged Delivery te zijn.
Staged Delivery kent wel een aantal denkfases vooraf (conceptfase, definitiestudie en een architectuur ontwerpfase van je projectresultaat). Tijdens de oplevering wordt het werk –anders dan in een pure waterval - uitgevoerd in een korte iteraties, stages genaamd, waarin het een deel van het projectontwerp in detail wordt uitgewerkt, gebouwd, getest en opgeleverd. Dit lijkt een beetje op de sprints van de Scrum methode en biedt hier ook de voordelen van (kleine) timeboxen. Net als in Scrum zijn er per project meer of minder stages nodig om tot het resultaat te komen.
Omdat er een ontwerp van de architectuur aan de uitvoering en bouw ten grondslag ligt is Staged Delivery in theorie minder flexibel dan Scrum of een andere Agile methode waarbij er geen ontwerp vooraf gemaakt wordt. In de praktijk echter zijn er talloze scrum beoefenaars die een aantal “ontwerp-sprints” nodig achten vooraan het project om toch eerst een ontwerp te hebben voordat de bouw kan beginnen. Voor sommige projecten is het onmisbaar met een vooraf vastgesteld ontwerp te werken. Als er een of meerdere ‘ontwerpsprints’ zijn aan het begin van een Scrum project lijkt de aanpak in veel opzichten veel op Staged Delivery.
Een voordeel van de Agile projectfilosofie is dat je niet meer werk doet dan dat het team aankan. Het team kijkt namelijk per sprint wat er in past en alles wat niet in de sprint past moet óf in een volgende sprint gedaan worden óf gebeurt helemaal niet. Een variant op Staged Delivery kent dit principe ook en heet Design to Schedule.
Design to schedule
Bij Design to Schedule begin je ook met een paar ‘denkfases’ (concept, definitie en architectuur ontwerpfase) en voer je het werk daarna uit in iteraties. Bovendien wordt er hier – net als in Scrum – een prioriteit aangebracht in de werkzaamheden. Het belangrijkste eerst en dan het volgende in prioriteit en dan het volgende. Totdat de tijd of het geld op is. Als er veel tijd en geld is kunnen er meer iteraties gedaan worden maar als er beperkt geld of tijd is zoals bij de meeste projecten, dan zullen er minder iteraties plaatsvinden. Maar door de prioritering worden in ieder geval de essentiële elementen van het project opgeleverd.
Een overheidsorganisatie uit Vlaanderen moet software (laten) ontwikkelen voor het uitvoeren van hun overheidstakenpakket. De organisatie wil Agile verkennen omdat hun leveranciers dat ook doen. Lastig alleen is dat ze bij het beoordelen en uitkiezen van hun leveranciers uit moeten gaan van een fixed budget en fixed result. Zo zijn de regels voor het verkrijgen van financiering binnen de overheid. Hierdoor kunnen de projecten in de praktijk helemaal niet Agile zijn. De software moet gewoon voldoen aan de regels uit het bestek. Er wordt een pseudo Scrum methode ingevoerd, waarbij de fases nu “sprints” heten en alle sprints al vooraf zijn ingevuld en ingepland aan de hand van functiepunten inschattingen.
Projecten monden nog steeds uit in discussie met de leverancier over meer- en minder werk of wijzigingen in specificaties ten opzichte van het oorspronkelijke bestek. Agile kan hier nooit gaan werken tenzij de overheid kiest voor een ander soort contract met hun leveranciers en accepteert dat de uitkomst van een project (sterk) kan afwijken van de oorspronkelijke offertes en plannen waarop een leverancier is gekozen. Verbetering zou kunnen optreden door het project op te knippen in kleinere fases en die per fase te financieren. Afhankelijk van hoe strikt en specifiek de eisen uit het bestek zijn aan het resultaat kan er dan Agile (geen ontwerp of alleen globale eisen) gewerkt worden of met een methode als Design to Schedule (wel een ontwerp en strikte eisen maar beperkte tijd/middelen).
Omdat Agile en Scrum op veel verschillende en vaak ‘eigen’ manieren wordt toegepast is het soms moeilijk te zeggen waardoor de voordelen van de Agile werkwijze eigenlijk ontstaan. Is het doordat er meer gecommuniceerd wordt tussen klant en team of komt het doordat teams in een ruimte samenwerken? Is het verkorten van de opleveringen de sleutel, het inzetten van planning poker of gaat het om een combinatie van factoren?
Het punt is dat de principes die het succes van Agile bepalen ook in een andere projectstructuur kunnen worden toegepast en mogelijk tot betere resultaten leiden.
Agile of niet, een verstandige projectleider zorgt er voor dat er veel gecommuniceerd wordt tussen opdrachtgever en projectteam en dat er regelmatig tussenproducten geleverd worden . Een projectteam bij elkaar zetten in 1 werkruimte is vrijwel altijd een goed uitgangspunt. Samen een planning maken in plaats van een van bovenaf opgelegde planning is ook een good practice van elk project. Hetzelfde geldt voor het vroegtijdig betrekken van eindgebruikers in een project, dat is vrijwel altijd een goed principe ongeacht de projectmethode.
Evolutionary Prototyping
Een high tech bedrijf, dat zeer innovatieve producten ontwikkelt had Agile ingevoerd omdat projecten te lang duurden. Het plannen van het werk is erg lastig omdat het om uitvindingen ging. Soms werd er heel snel resultaat geboekt, soms waren ze maanden bezig om iets werkend te krijgen (en soms lukte het nooit). Agile leek een oplossing voor die onvoorspelbaarheid. Het hielp alleen niet, de projecten bleven chaotisch en doorlooptijden onvoorspelbaar. Toen we doorvroegen naar wat er veranderd was, bleek Agile vooral een excuussticker om niet echt een structuur aan te brengen in de projecten en de tijd te verdelen onder de engineers. Daarbij kwam dat de projectteams eigenlijk te klein waren om een Agile team te kunnen zijn. Meestal bestond een team uit niet meer dan 4 engineers, soms maar 1 of 2. Plichtmatige standup meetings met zijn tweeën of drieën hadden geen meerwaarde omdat er toch al veel contact was tussen de engineers. Eigenlijk was er met de invoering van Agile niets veranderd ten opzichte van de oude situatie, alleen heten werkpakketten nu “sprints” en taken nu “stories”.
De oplossing was het invoeren van portfoliomanagement. Hierdoor werd het zichtbaar dat de engineers structureel overvraagd werden waardoor er lange wachtrijen van taken waren. Met het invoeren van portfoliomanagement moest er ook een meer hiërarchische aansturing komen, waarbij iemand het besluit moest kunnen nemen om projecten of taken niet te doen of uit te stellen. Wel bleef het nuttig om in kleine iteraties te werken omdat het voornamelijk om ‘uitvindersprojecten’ ging, waarbij ze al proberend tot een resultaat konden komen.
Een passende projectaanpak voor deze organisatie bleek Evolutionary Prototyping te zijn.
Evolutionary Prototyping is een methode die bedacht is midden jaren ’70 en heeft als grote voordeel dat het snel projectrisico’s elimineert. De risicovolste elementen van een nieuw product moeten als eerst werkend gekregen worden. Details en uitwerking volgen later wel. Als het niet lukt een probleem of risico op te lossen stop je met het project. Zo verspil je niet veel tijd en geld aan details. Deze filosofie ten aanzien van risico’s is later overgenomen in Extreme Programming, een van de Agile methodes die vooral populair is bij softwareontwikkelaars.
Wat bepaalt de projectmethode?
Het is beter om helemaal niet te denken binnen de dogma's van een of andere methode maar bij de keuze voor een projectmethode na te denken over welke uitgangspunten en elementen van een methode je zelf nuttig acht voor een specifiek project.
De beantwoording van de volgende vier vragen vormt de kern van de keuze voor een projectmanagement opzet:
- In hoeverre is het mogelijk en gewenst om het projectresultaat in delen te ontwerpen, te bouwen en op te leveren?
- Hoe regelen we de aansturing van het project (hoe hiërarchisch)? Kan het team zelf in grote mate besluiten nemen over het ontwerp, de uitvoering en de timing van het werk of is enige hiërarchie nodig?
- Is het noodzakelijk of nuttig om vooraf een aantal zaken (welke?) uit te denken (te ontwerpen) en tot op welk detailniveau?
- Is het acceptabel als een deel van het werk niet gerealiseerd wordt (binnen de gestelde tijd of misschien helemaal niet wordt gerealiseerd)?
Op basis van deze overwegingen kan je zelf bepalen hoe ‘agile’ je kan en wilt zijn. Dan kan het best zo zijn dat Scrum niet de best passende keuze is voor een project noch een pure waterval aanpak, maar iets anders.
Wie gaat zoeken in de geschiedenis van projectmanagement kan prachtige pareltjes vinden van werkwijzen die nog steeds van toepassing zijn. Mogelijk zit er een methode bij die voor bepaalde projecten of organisaties nog beter werkt dan puur Agile of waterval.
Auteur: Wouter Baars, consultant bij www.pojectmanagement-training.nl
Noten
- Staged Delivery zie bijvoorbeeld:
- Design to Schedule (tevens bespreking van veel andere methoden): Steve McConnell, Rapid Development -Taming Wild Software Schedules, Redmond, Washington: Microsoft Press, (1996).
- Evolutionary prototyping
Waar vind ik toepasbare kennis en gedeelde ervaringen?
Probeer het Pro-abonnement een maand gratis
En krijg toegang tot de kennisbank. 110 onderwerpen, kritisch, wars van hypes, interactief en geselecteerd op wat wél werkt.
Word een PRO
In de afwegingen mis ik een aspect dat in alle drie de voorbeelden een meerwaarde heeft :
1) De rol van productowner wiens primaire rol is te waken over de business case
Het tweede punt betreft het begrip architectuurontwerp. Als de eerste stap een definitiestudie betreft ( In SE termen het best te vergelijken met een Operational Concept Description (OCD)) , dan zou het architectuurontwerp logischerwijs en - opnieuw afhankelijk van projectcontext tenminste een basisontwerp moeten zijn ( Systeemontwerp) en maximaal een definitief (Functioneel ontwerp). Klopt deze interpretatie ?
De Agile filosofie is veel beter en breder toepasbaar dan Scrum zelf. Een brede kijk op het project (van idee tot evaluatie) is noodzakelijk en Scrum dekt het complete traject niet af. Verstandig met die dingen omgaan en hybride modellen gebruiken (zoals de drie hierboven) is een must voor succes.
Het is waar dat het Agile Manifesto (http://agilemanifesto.org/) en de daaruit voortgekomen Agile beweging hun oorsprong vinden in de softwareontwikkeling. Echter, de kern van dit manifest is dat je accepteert en omarmt dat de werkelijkheid om je heen constant verandert en dat het eindproduct van je inspanning beter gediend is met het inspelen op die verandering, dan het (vaak krampachtig) vasthouden aan de status quo. Dat gaat zeker op in de snel veranderende wereld van de technologie, maar ook op andere vlakken kan een "Agile" aanpak van meerwaarde zijn. Er zijn Marketing teams die Agile Scrum gebruiken, evenals Sales-teams die Kanban toepassen op hun leads.
De vuistregel is dat daar waar het doel van een project nog onduidelijk en de weg ernaartoe complex is, je beter kunt kiezen voor een werkmethode die je in staat stelt met gewenste én onverwachte koersveranderingen om te gaan. Als het eindproduct specifiek is omschreven en er geen grote veranderingen zijn te verwachten, heeft de keuze voor bijvoorbeeld Waterval de voorkeur, omdat het vanuit een ander paradigma beter bestuurbaar is. En daartussenin zitten dan weer varianten, zoals de auteur beschrijft. Wat je doel dan is, software of anderszins, maakt daarbij feitelijk niet uit.
Er is dus inderdaad uiteindelijk niet één waarheid. De enige juiste methode of aanpak is degene die goed past bij het type project en het type werkzaamheden en waarover is nagedacht. Soms is dat Agile, soms Waterval, soms iets anders. "Be Agile in being Agile".
Dank voor je complimenten. Wat betreft je punten:
1: De product owner die de business case bewaakt heeft in casus 2 en 3 niet echt een meerwaarde omdat bij die organisaties (overheid/non profit en high tech) de business case niet te maken is. Dit geldt voor de not for profit overheidsprojecten en het geldt bijna altijd ook voor de high tech projecten waarbij het gaat om uitvindingen die (nog) ver van de markt staan en/of waarvan de geldstromen nauwelijks zijn te kwantificeren. Bovendien was er bij veel van de 'uitvindersprojecten' sprake van hele kleine teams of individuen. Een aparte product owner erbij zou te veel sturing betekenen op teams van 1 tot 4 personen, die prima in staat zijn om zelf te bepalen wat er moet gebeuren.
In het eerste casus (de infrastructuur projecten) zou een product owner wel een rol kunnen spelen bij het bepalen van de werkzaamheden in een stage. Maar -in de lijn van het artikel- zou ik misschien niet eens over een product owner willen spreken maar willen zeggen dat er bij iteratieve projecten elke iteratie (stage, sprint, timebox,...) bepaalt moet worden wat gedaan moet worden. Dan kan een product owner in sommige gevallen handig zijn, maar waarom niet aan het team zelf overlaten, of waarom niet aan een projectleider? We kunnen het hiërarchisch (1 persoon) aanpakken of democratisch (meerdere personen, het team of zelfs 'alle' stakeholders gezamenlijk). Als het maar gebeurt. Je mag dan zelf als organisatie bedenken of je liever democratisch wilt opereren of liever hiërarchisch . Bedenk tenslotte dat de product owners rol een SCRUM 'uitvinding' is, veel andere agile stromingen kennen die rol niet of hebben hem pas later geïntroduceerd (lees: afgekeken van SCRUM).
2. Als ik je vraag goed begrijp: het gaat erom hoe ver je moet gaan met het maken van een ontwerp bij de diverse modellen genoemd in het artikel. Is een concept genoeg of moet het helemaal een uitgewerkt functioneel ontwerp zijn? Of, zou ik er aan willen toevoegen: een helemaal uitgewerkt technisch ontwerp? Of een deelontwerp? Ik kan die vraag niet precies beantwoorden. Niet te veel vastleggen zou ik zeggen, alleen de architectuur kan voldoende zijn, maar soms is misschien meer nuttig. Is een kwestie van risico management en management van verwachtingen bij opdrachtgevers denk ik. Ik hoor graag van anderen met ervaring met deze en vergelijkbare projectmanagement methodes hoe zij dit gedaan hebben.