Mooi om te zien dat er niet één waarheid is. .....Uit het hart gegrepen en het artikel beschrijft verschillende views, afhankelijk van projectcontext.

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 ?

Een probleem met Agile is dat het mordicus wordt toegepast, ook als je vooraf weet dat de kans op slagen beperkt is. Agile is enkel geschikt voor software projecten en dan nog enkel in de productiefase. Hierdoor werkt het vrij goed in softwarehuizen omdat die precies in die fase actief zijn . Als er hardware of iets anders aan te pas komt, werkt het niet meer. Hoe het eventuele lastenboek tot stand komt, zegt Agile niet.

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.

De stelling, dat Agile werkmethoden alleen geschikt zouden zijn voor software ontwikkeling, is naar mijn mening te kort door de bocht.

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".

@Nicholas Nass:

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.

Het probleem bij veel organisaties is dat men nog steeds de projectmanagement filosofie uit het "waterval"-tijdperk gebruikt. Sinds de jaren tachtig zijn modernere invullingen van projectmanagement gangbaar geworden. Het idee dat het een lineair proces is, wordt daarbij losgelaten, speciaal voor de "delivery"-fase, zoals je ook beschrijft met de "Staged Delivery" benadering. De essentie is het actief omgaan met complexiteit en onzekerheid. Elementen als waardecreatie voor de klant, cross-functionele samenwerking, zelforganisatie, iteratieve benadering met terugkoppel lussen, transparantie en eenvoud vormen belangrijke ingrediënten van deze nieuwe projectmanagement benadering. Niet geheel toevallig vind je deze elementen ook terug in de Agile filosofie. Ik denk dat het probleem met elke methode is dat je niet de uitvoeringsvorm moet kopiëren, maar iedere keer weer nadenken wat helpt vanuit het basisidee. Een goed boek over deze moderne vorm van projectmanagement is "Leading in Uncertain and Complex Projects" van Lars Marmgren en Mats Ragnarsson.

@ Martin: Ik ben het helemaal met je eens. Je zou bijna kunnen zeggen 'vorm volgt inhoud' geldt ook bij projectmanagement. Bedankt voor je boektip, ga ik zeker lezen.