DSDM/Agile Project Framework DSDM is een van de oudste Agile methodieken. Dynamic systems development method (DSDM) is beschreven door het DSDM-consortium, wat mede aan de wieg heeft gestaan van het Agile Manifesto. DSDM is een Agile Methodiek die zich specifiek richt op het Agile uitvoeren van projecten. Deze methodiek is al midden jaren negentig vorige eeuw beschreven en is daarmee in leeftijd vergelijkbaar met Scrum.
Inmiddels zijn er vele Agile frameworks, ieder met specifieke sterkten en krachten. DSDM is geëvolueerd naar het Agile Project Framework (AgilePF). Daar waar andere frameworks zich meer richten op evolutionair ontwikkelen van producten legt het AgilePF een stevige nadruk op het uitvoeren van projecten en het leveren van oplossingen.
Een tweede verschil met veel andere frameworks is dat het AgilePF vrij uitgebreid beschreven is. Zo zijn er dertien rollen beschreven, wordt er een hoeveelheid van verschillende technieken aangereikt, is er sprake van een duidelijk proces model en zijn er duidelijke producten beschreven. En dit alles uiteraard in samenhang met elkaar, met veel aandacht voor het aspect schaalbaarheid en gekoppeld aan de rest van de organisatie. Natuurlijk wordt ook binnen AgilePF de nadruk gelegd op het beperken van de bureaucratie, documentatie alleen waar nodig en persoonlijk contact. Het Agile Manifesto wordt volledig onderschreven door AgilePF.
Meerwaarde?
De basis van AgilePF is het uitvoeren van projecten/programma’s en portfolio’s en het leveren van oplossingen binnen organisaties. AgilePF richt zich dus niet primair op de gehele organisatie. Daardoor is het voor veel organisaties gemakkelijker om de overstap naar Agile te maken omdat het simpelweg niet de gehele organisatie raakt. Het is prima mogelijk om een deel van de projecten op een Agile wijze uit te voeren, terwijl andere projecten nog op een andere, traditionele wijze worden uitgevoerd. Op deze wijze kan Agile langzaam worden ingevoerd. De informatiestromen naar het hoger management blijven op deze manier dan ook voor een groot deel gehandhaafd en de verandering ook op dat managementniveau gaat geleidelijker dan bij veel andere methodieken.
Al begin jaren negentig is vastgesteld dat er verschillende typen projecten bestaan die ieder een eigen aanpak vergen. Niet ieder project is geschikt om op een Agile wijze uitgevoerd te worden. Immers, een groot infrastructureel project of een groot bouwproject zal niet op een Agile wijze worden uitgevoerd. Het AgilePF erkent dit en laat daardoor ook ruimte voor meerdere typen projecten in één organisatie.
Een laatste voordeel is dat de besturing van de organisatie nog steeds project-georiënteerd is. Met name rolbeschrijvingen binnen het AgilePF is goed geborgd van en naar de rest van de organisatie gedefinieerd. De Agile Business Analist bijvoorbeeld is bij uitstek een persoon die de visie van de organisatie en de richting van het project continu met elkaar blijft toetsen en – indien nodig – bijstelt. Ook de rollen van de business sponsor (eigenaar van het project), business visionary (verantwoordelijk voor het verkrijgen van een product dat voldoet aan de business eisen), business advisor en business ambassador zijn duidelijke brugfuncties tussen project en organisatie.
Natuurijk is ook de rol van de project manager beschreven. De aandacht van de AgilePM is primair gericht op het opleveren van het projectresultaat. De project manager is met name ook verantwoordelijk voor het informeren van stakeholders en bovenliggend management.
Voor AgilePM zijn er al verschillende aanbieders van trainingen. Het AgilePF voorziet echter ook in trainingen voor de AgileBA (business analist) en de AgilePGM (program management). Sinds kort is het mogelijk in Nederland de training AgileBA te volgen. Op de planning staat voor volgend jaar ook AgilePGM.
Leuk commercieel stukje. Helaas mis ik even het volgende ….
IT programma/project management is een andere wereld als dynamisch project management en scrum en agile verhouden zich in de regel heel erg slecht met de statische wereld van digitaal automatiseren. Men is eindelijk steeds meer en vaker tot de conclusie gekomen dat de veelheid van latere methodieken zich kostbaar slecht verhouden met elkaar.
Just a thought …
Als je dit vergelijkt met bv Prince II wat zijn dan de verschillen?
Een apart verhaal.
Eerst wordt uitgebreid aangegeven dat er dertien rollen zijn beschreven, verschillende technieken worden aangereikt, een procesmodel aanwezig is en er producten zijn beschreven. Bij veel grote bedrijven zijn dit bij uitstek de geschreven stukken waar de bureaucratie uit bestaat. Vervolgens wordt opgemerkt dat de nadruk wordt gelegd op “het beperken van de bureaucratie”. Het lijkt er sterk op, dat met AgilePF de bureaucratie juist wordt geïntroduceerd, om dan daarna te beweren dat het eigenlijk niet de bedoeling is.
Bij Agile werken gaat het er juist om dat deze oude belast overboord wordt gezet. Er wordt hier gezocht naar een compromis tussen projectmatig werken en Agile werken. De vraag is of dit eigenlijk wel bestaat.
@Arend van Buren
Waar al die ‘latere’project methoden, scrum, agile, lean, ed geen rekening mee houden is het volgende; Project management generiek is dynamisch, Digitaal automatiseren/IT is statisch. Project managers maken telkens weer twee fouten.
1 Digitaal automatiseren/IT = Statisch
Statisch is recht to recht aan, schaalbaar en dat zul je als zodanig ook moeten behandelen. Je zult niet alleen lineair moeten kunnen kijken, denken en acteren, je zult ook de leden van de betreffende project keten, op dezelfde lijn moeten hebben. Niet iedereen binnen de IT is namelijk Lineair, oeps, hebben we nu een kleine professionele valkuil ontdekt? Dit kunnen de hier bedoelde PM methoden niet onderkennen.
2. Communicatie, informatie en medewerking
Een ieder maakt deel uit van de keten. IT professionals, management, gebruikers. Een ieder heeft een rol te vervullen en de meest verzaakte stap is … stakeholder allereerst uit te leggen wat diitaal automatiseren is, hoe dat in zijn werk gaat en wat de impact hiervan is op de betreffende organisatie.
Een PM die een IT project aannemt maar geen jota begrinpt van digitale automatisering, gaat al snel achter de feiten aanrennen omdat die dan dingen tegen zal komen die hij niet kan controleren, en dus weer te afhankelijk is van onderlinge schakels in de betreffende keten. Je kunt ze dan ook niet goed gelijk schakelen.
Bureacratie
Er is weinig zo leuk en voorspelbaar als een IT project en dus ook de documentatie en project inrichting. Net zo vaak overigens dat die dan ook een ondergeschoven kind in het hele traject blijkt te zijn.
Ik heb een vraag: hoe gaat men binnen scrum en Agile om met de verplichting per 25 mei 2018: Privacy by design & default? Dat lijkt mij best een “bureaucratiesche” opgave? Of ook maar Agile doen?? Met Agile vakmanschap? Net als de informatiebeveiliging?
@René Een PM die niets weet van automatisering lijkt me per definitie een foute start.
Maar dat geldt voor alles. Een PM die niets weet van de bouw laat je ook geen huis bouwen.
Of bedoel je een programma manager en geen project manager? Of bedoel je eigenlijk een projectleider?
Afkortingen zijn altijd leuk, vooral als de mensen in je team verschillende betekenissen aan de afkortingen geven.
@ Corne
In de praktijk blijk dit, getuige de mogelijkheden in de rest van Europa, helemaal niet zo vanzelfsprekend te zijn. Uiteraard geld dit ook voor een projectleider en de individuele IT professional.
Frameworks en methodieken ontlenen hun bestaansrecht aan een versimpeling van de werkelijkheid. Die versimpeling is doorgaans gekoppeld aan het concept “de mens”. Dat concept maakt dat het werkelijke eindresultaat moeilijk in te schatten is; iets wat de verschillende soorten managers/leiders maar een lastige vinden.
Om daar wat aan te doen wordt er een aanvullende methodiek toegepast die redelijk dicht in de buurt komt van iets dat heet “struisvogelpolitiek”: het concept “de mens” wordt weggestreept uit de vergelijking bij het toepassen van een bepaald framework of methodiek. En meer specifiek – wordt weggestreept uit de vergelijking bij het bepalen van de doorlooptijd, kosten en resultaat.
Daardoor is elk proces/programma/project op voorhand al een succes; ook al doordat kosten en opbrengsten mooi in één boekjaar vallen zodat ze tegen elkaar weggestreept kunnen worden. Zoiets doet het altijd goed op de eindbalans van dat jaar (en misschien nog veel belangrijker: de jaren erna…).
😉
@ Will Moonen
Ik ben het weer helemaal met je ens zij het even vanuit een andere invalshoek. De fout die nog steeds, het is een hardnekkige, wordt gemaakt is dat men de methodiek denkt te kunnen neerleggen als de overlappende trap tussen de wereld van It en Non IT. Toch is het ronduit stuitend en verbijsterend dat na 30 jaar KA het IT professionals nog steeds niet lukt niet IT professionals/klant/stakeholder gewoon uit te leggen a: wat digitale automatisering is, b: hoe het werkt en je ermee om moet gaan, en c: Wat nu uiteindelijk het oogmerk is van digitaal automatiseren.
Dat verschil tussen twee werelden is vrij eenvoudig… Mens Dynamisch – Digitaal automatiseren/IT Statisch.
Hier heb je meteen het verschil. Mens Dynamisch veranderlijk….. Digitaal automatiseren/IT Statisch, aan universele wetmatigheden gebonden. Je zal dus de brug moeten slaan tussen deze twee werelden door mens/klant/stakholder/gebruik(st)er zich te laten conformeren aan de regels van digitaal automatiseren. En laat nu juist dit gegeven zijn wat slechts 5% van alle professionals, die echt begrijpen wat digitaal automatiseren is, hoe daarmee om te gaan, weet uit te leggen aan de Non IT ecxecutive en professionals/stakeholders/gebruik(st)ers.
Vraag je je af waarom het telkens weer zo fout kan gaan…. heb je hier een van de vijf voedingsbodems. ;O) Google even op ‘Civile Matrix’… ideeel en gratis, nee niets nieuws. ;O)))
zoiets ?
Civile Matrix
_____________
|…………………..|
|..Echte wereld..|
|…………………..|
|…… _____…….|
|……| rene |…….|
|……_____……..|
_____________|