Inception

In de blog ‘Systeemontwikkeling als proces’ is onderscheid gemaakt tussen de verschillende aanpakken voor systeemontwikkeling: waterval, iteratief incrementeel en agile. Welke aanpak je ook kiest, altijd willen opdrachtgevers in een vroeg stadium een antwoord op de volgende vragen:

Wat krijg ik?
Wanneer is het af?
Wat gaat het (ongeveer) kosten?

En dat terwijl ‘het’ nog gedefinieerd moet worden. Het zijn vaak uitermate lastig te beantwoorden vragen in het begin van een project. Je weet in veel gevallen immers nog niet eens wie je stakeholders zijn, laat staan wat ze willen! Deze blog besteedt aandacht aan de eerste fase van een systeemontwikkelingsproject: de Inception-fase. Inception betekent ‘begin’ en is een belangrijke ‘best practice’ (zie blog 'Best agile practices') voor analisten en product owners.

Meestal is er bij de start van een project alleen nog maar een idee (project brief). Dit idee moet eerst worden omgezet in een meer concrete visie waarin de scope en de eigenschappen van het nieuwe product worden vastgelegd. Op basis hiervan kunnen de globale kostprijs en de verwachte baten van het project worden geschat. Tevens dienen de belangrijkste risico's geïdentificeerd en ingeschat te worden. Het uiteindelijke doel hiervan is om te bepalen of het oorspronkelijke idee wenselijk en haalbaar is. Met andere woorden, er wordt bepaald of er sprake is van een positieve danwel negatieve business case. Dit betekent dat een project (c.q. product) voldoende moet opbrengen in financiële dan wel strategische zin, anders kun je de inspanning net zo goed laten. Voordat een bouwteam aan de slag gaat is het dus verstandig om eerst een grondige analyse te doen naar de haalbaarheid en wenselijkheid van het betreffende product. Blijkt uit de analyse dat de business case positief is dan volgt er meestal een ‘Go’-beslissing: het project gaat door. Is deze negatief dan wordt er over het algemeen een ‘No Go’-beslissing gegeven door de opdrachtgever: het project wordt beëindigd (of tijdelijk stopgezet).

Inception-fase

De bovengenoemde analyse vindt idealiter plaats in de eerste fase van een project, de Inception-fase. Deze valt samen met de initiatiefase van PRINCE2®. De oorsprong van de Inception-fase stamt uit het RUP-framework (zie blog: ‘Systeemontwikkeling als proces’). RUP propageert om tijdens de eerste fase nader onderzoek te doen naar:

het business probleem of doelstelling dat de basis vormt van het project (de rationale)
het deel van de (klant)organisatie dat beïnvloed wordt door het nieuwe product
de doelgroep van het product. Wie zijn de stakeholders en wat is hun belang is bij het product en/of hun invloed op het project?
de behoeften van die stakeholders (needs)
de (architecturele) randvoorwaarden (constraints) en risico’s (risks) van het project
de begrenzing van het product (product scope)
de functionele en niet-functionele eigenschappen (features) van het product

Als er meer duidelijkheid is ontstaan over de bovenstaande punten dan is het zaak om een gezamenlijke visie te creëren tussen de stakeholders m.b.t. het nieuwe product. De visie wordt vastgelegd in een Vision-document waarin een heldere beschrijving staat van het product en waarin de scope en eigenschappen (product features) worden vastgelegd.

Het doel van het Vision-document is te komen tot stakeholder consensus met betrekking tot het nieuwe product. Doordat stakeholders een gedeelte visie hebben van het toekomstige product kan het ontwikkelteam effectiever te werk gaan (zie ook de eerdere blog ‘Perceptie’).

Het Vision-document is een belangrijk artefact binnen het RUP-framework. Je zou het kunnen beschouwen als een soort ‘contract’ waar alle stakeholders hun ‘handtekening’ onder zetten. Daarnaast wordt het document gebruikt om te bepalen of het zin heeft om door te gaan met de volgende fase van het project.

Hoe lang duurt de Inception?

Meestal neemt de Inception-fase een maand tijd in beslag, maar deze kan ook veel korter zijn. Het maximum is twee maanden. Ik heb ooit eens een cursist gehad die het over een Inception-fase had van een jaar! Dat is natuurlijk veel te lang. Als een Inception langer duurt dan 2 maanden kan worden geconstateerd dat er teveel onduidelijkheid heerst over de rationale (het waarom) van het project. Het starten van een systeemontwikkelingsproject heeft dan nog niet zoveel zin, omdat in die gevallen eerst een grondig vooronderzoek nodig is. Dit vooronderzoek vindt meestal in een pre-project fase plaats.

Agile

In veel agile projecten is het ‘not done’ om over projectfasering te praten; het is een beetje als vloeken in de kerk. In Scrum bestaat derhalve geen aparte Inception-fase. Er wordt in de Scrum Guide niets geschreven over de wijze waarop de Product Owner tot een initiële lijst met Epics en User stories komt. Het lijkt alsof de Product Backlog uit de lucht komt vallen (zie rode kader in onderstaande figuur). Het ontbreekt veel product owners aan handvatten waarmee ze tot een goed onderbouwde Product Backlog kunnen komen.

Uit onderzoek (2013 Agile Project Initiation Survey Results) is gebleken dat, hoewel er geen aparte startfase wordt onderscheiden, de meeste agile projecten in het begin aandacht besteden aan de bovenstaande vraagstukken. Zij noemen het alleen anders, vaak wordt hiervoor de term ‘Sprint 0’ of ‘Iteratie 0’ gebruikt. In projecten waarin dit niet plaatsvindt kost het meestal heel veel moeite en tijd om de goede dingen op te pakken en alle stakeholders mee te krijgen.

Scrum framework

Andere agile frameworks

RUP is niet het enige framework waarin sprake is van een Inception-fase. Er zijn zelfs agile frameworks die met fasering werken en een aparte Inception-fase onderscheiden, waaronder de hybride frameworks Disciplined Agile Delivery (DAD) en ScrumUP. ScrumUP is, zoals de naam al suggereert, een hybride van de frameworks Scrum en UP (UP is de universele naam voor ‘Unified Process’, RUP is hiervan een instantiatie). ScrumUP onderscheidt diverse workflow-modellen waaronder een objectives workflow, een architecture workflow, een preparation workflow en een Sprint workflow.

Objectives workflow ScrumUP

De bovenstaande figuur illustreert dat de analist in de Inception-fase een belangrijke rol speelt in de uitvoering van de objectives-workflow. Net als in Scrum is de product owner ook in ScrumUP verantwoordelijk voor de totstandkoming van de (initiële) product backlog. Deze wordt opgesteld op basis van input van de analist. De analist stelt eerst een Vision-document op en vervolgens een gezamenlijke begrippenlijst (glossary) plus een business object model. Tot slot stelt de analist in de Inception-fase een use case model op. De epics en use cases vormen de basis voor een verzameling user stories die op de initiële product backlog worden gezet. Zie onderstaande figuur.

Storymap

Door middel van planning poker sessies kan daarna een inschatting worden gedaan van de hoeveelheid tijd en geld die het gaat kosten om het software product te kopen, te bouwen of een combinatie daarvan.

Disciplined Agile Delivery (DAD)

Zoals eerder vermeld onderscheidt ook DAD een aparte Inception-fase. Aan het einde van de eerste fae in een DAD-project zijn de volgende doelen bereikt:

Ontwikkelteam is gevormd
Visie m.b.t het product is opgesteld
Stakeholders zijn het eens over de visie
Project levert een bijdrage aan de strategie van de organisatie
Initiële requirements zijn bekend en vastgelegd
Werkomgeving is gereed
Financiering is gereed
Risico’s zijn bekend

Requirements en taken worden op de Work Items List (een soort product backlog) gezet en geprioriteerd. Zoals is te zien in de onderstaande figuur komt de volgende fase van DAD (Construction) overeen met het Scrum-framework. Tot slot onderscheidt DAD nog een aparte fase (Transition) voor de overdracht van de software naar de productie-omgeving.

DAD framework

Dit is geen blog over RUP, Scrum, DAD of ScrumUP. Wel heb ik gekeken naar de grootst gemene delers van diverse veel gebruikte methodieken en frameworks en de daarin gebruikte best practices. Hieruit heb ik geconcludeerd dat productanalyse in de Inception-fase grotendeels kan worden uitgevoerd door de beantwoording van 12 vragen:

Waarom wordt het IT-project gestart? Wat is het probleem? Wat zijn de bedrijfsdoelstellingen? Business requirements
Waarop heeft het project betrekking? (Scope of Work)
Wie zijn de Stakeholders en wat zijn hun behoeften? (Needs)
Wat is de Productscope en waaraan dient het systeem op hoofdlijnen te voldoen? (Features)
Welke randvoorwaarden, risico’s en acceptatiecriteria zijn er?
Welke begrippen hanteren de stakeholders? (Glossary, Domain model)
Wat zijn passende oplossingen voor de problemen/ behoeften? (Make/Buy)
Wie zijn de actoren van het systeem en welke functionaliteit biedt het systeem hen? (Use Case Model);
Waaruit bestaat de Product Backlog en wat is de prioritering?
Wat zijn de high-level inschattingen voor de items op de Product Backlog? (Planning Poker)
Hoeveel iteraties (Sprints) zijn er? Wat zijn de Release data en mijlpaaldata?
Wegen de baten van de oplossing(en) op tegen de kosten? (verificatie Business Case).

De analist kan als (rechterhand van de) product owner tijdens de Inception-fase een cruciale rol spelen in het beantwoorden van deze vragen zodat het team in de Construction-fase een start kan maken met de juiste product backlog items en in de juiste volgorde. Hierdoor wordt de effectiviteit van het team sterk vergroot (zie blog 'Effectiviteit en efficiëntie').

In de volgende blogs zal ik verder inzoomen op de bovenstaande vragen.

vorige pagina