princeII en dergelijke zijn prima, maar passen beter in het andere hokje
belangrijkste verschil met prince2: management by exception.
in known past management by exception, omdat de rest voorspelbaar is.
| unordered | ordered |
| complex | knowable |
| chaos | known |
De meeste agile benaderingen leveren geen templates (bij voorbeeld voor project management) mee. Als je templates maakt loop je het risico (dat gebeurt veel bij toepassing van Prince2, rUP en DSDM) dat mensen hun gezond verstand uitschakelen en alle templates gebruiken, in plaats van situationeel te bepalen welke waarden, principes en werkwijzen van toepassing zijn in hun context.
Daarnaast wordt er (binnen teams in ieder geval, en zo veel mogelijk) uitgegaan van mondelinge kennis-overdracht in plaats van schriftelijke (een mondelinge versus een geschreven cultuur). Templates passen alleen in een geschreven cultuur. XpProjectTemplate
PrinceII? wordt vaak toegepast in known, maar daar is het niet voor bedoeld, eerder voor knowable. PrinceII? is een project management methode, als alles bekend is, is er geen project nodig. routine-...-improvisatie
DSDM lijkt op de rand van known en knowable te zitten. Je kunt sturen, maar langzaam, want iteraties zijn over het algemeen lang (een kwartaal tot een half jaar). Je moet een groot deel van je schermen (wat DSDM specifiek maakt voor GUI applicaties) van te voren kunnen definieren. DSDM lijkt op twee gedachten te hinken - software ontwikkeling zit in known en het zit in knowable. PrinceII? is bedoeld voor knowable, maar bij verkeerd gebruik lijkt het geschikt voor known.
Scrum richt zich op complex 'control chaos'. Maar omdat het plannings proces erg weinig overhead heeft, met name dagelijkse standups kan het ook knowable en known worden gebruikt - de standups leveren in known input op voor MangementByException? . XP bevindt zich deels in knowable, met name de programmeer practices en SimpleDesign?.
Wat betreft programmeren zelf kun je in knowable zitten, terwijl wensen van de klant en marktontwikkelingen in complex zitten.
SystemBoundaries? : team dynamiek / business context / programmeren
Project / Product ontwikkeling als geheel is unordered. De systeem ontwikkeling zelf kan deels ordered zijn. In het eerste deel van xp explained gaat het over de gewijzigde cost of change curve. In de afgelopen dertig jaar hebben we veel geleerd over hoe we kunnen testen, releasen en dergelijke, en daarmee kunnen we qua ontwikkelwerk grotendeels aan de ordered kant uitgekomen. Integratie/Acceptatietesten lijkt wat dat betreft nog aan de unordered kant te zitten.
Veel organisaties bevinden zich qua technische systeem-ontwikkeling onnodig aan de unordered kant. Dit kan relatief eenvoudig opgevangen worden door training en mentoring in unit-testen, herstructureren en reviewen.
Teamdynamiek bevindt zich ook aan de unordered kant. Voorbeelden hiervan zijn interactie tussen teamleden, rolverdeling en het creeren van flow.
xp en scrum kunnen, als je echt in known zit gezien worden als overhead. Een reden om zoiets te doen, is als je verwacht dat je daar misschien niet lang meer zit, helpen scrum en xp je om bewust te blijven van in welk domein je bent, en is het team klaar voor het geval dat er iets gebeurt.
| unordered | ordered |
| scrum | xp, princeII, AgileUP? |
| chaos | DSDM, UP, VModel, princeII verkeerd, FormalMethods? |
n.a.v teamdynamiek coaching is niet mensen naar een vooropgesteld doel leiden. In situationeel leiderschap kunnen we zien, dat dit soms wel nodig is, afhankelijk van deskundigheid en motivatie
| minder deskundig | zeer deskundig | |
| sterk gemotiveerd | begeleiden | delegeren |
| zwak gemotiveerd | leiding geven | aansporen |
aansporen -> Appreciations / AppreciativeInquiry?
| anticipating | |
| variable | steering |
| oblivious | routine |
Projecten die zich in Knowable/Complex bevinden: first-time projecten; hoeft voor klant niet first-time te zijn; bijv. klant laat 10 soortgelijke projecten door 10 verschillende leveranciers doen - dus elke keer weer opnieuw nieuw team, project chartering, opnieuw softwareontwikkelproces in known brengen, etc. (bijna alles is onbekend, zit in chaos). Voor leverancier is het first-time, alles nieuw. Alternatief is: goede relatie opbouwen tussen klant en leverancier.
Om fixed price projecten verantwoord te kunnen doen is het nodig dat alledrie gebieden (team, programmeren, business) in ordered space zitten. Voor bijv. exchange request moet je stories kunnen inschatten, dat verondersteld op zijn minst dat team en programmeren in ordered zitten. Of je moet enorme buffers inbouwen in je projecten (misschien willen sommige klanten daar wel voor betalen).
Hoe weet je van een systeem in welk van de 4 domeinen (Chaos, Complex, Knowable, Known) het zit? Dat heb je nl. wel nodig om op effectief te kunnen handelen (en de juiste processen etc. toe te passen).
Statements