Scrum en CMMI – Project Planning

The Scrum project management method. Part of t...

Image via Wikipedia

In een vorige post heb ik in het algemeen gekeken naar de combinatie van Scrum en CMMI. In deze post kijk ik dieper naar de process area Project Planning. Is Scrum hiervan een goede implementatie?

Het doel van Project Planning is om plannen voor de projectuitvoering te maken.

Notitie: ik heb de engelse CMMI tekst hier zelf naar het nederlands vertaald. Bij de vertaling heb ik duidelijkheid en leesbaarheid verkozen boven een zo correct mogelijke vertaling.

Project Planning heeft 3 specifieke doelen. Doel 1 gaat over het maken van schattingen. Hierbij behoren 4 werkwijzen (specific practices).

SP1.1 Zet een work breakdown structure op om de scope van het project te bepalen

Dit gebeurt in Scrum op een aantal niveau’s. Ten eerste wordt het project opgebroken in een serie van sprints. Vervolgens wordt elke sprint opgebouwd uit user stories (requirements) die geïmplementeerd moeten worden. Lijkt me een prima implementatie.

SP1.2 Maak schattingen van de attributen van werkproducten en taken

Schattingen worden in Scrum gedaan op basis van story points. Hiertoe wordt in de regel een aantal user stories als referentie genomen: “dit soort stories krijgt 1 story point en dit soort 3 punten”. Alle andere stories worden dan relatief aan deze referentie stories geschat. Deze story points zijn Scrum’s implementatie van het CMMI begrip “attributen van werkproducten en taken”. Ze vormen vervolgens de basis voor inschatting van inspanning en kosten (maar dat komt pas bij werkwijze 1.4). In orde dus!

SP1.3 Definieer een levenscyclus als basis voor het plannen van het project

Scrum projecten volgen een incrementele levenscyclus. Een groot project wordt opgebroken in Sprints van 2-4 weken. Het in te plannen werk wordt passend gemaakt voor deze time boxes.

SP1.4 Schat de inspanning en kosten voor het project op basis van een rationale

Inspanning (en daarvan afgeleid kosten) worden in Scrum ingeschat op basis van 2 parameters. De story points voor iedere user story en de velocity van het team. De velocity is de snelheid waarmee het team story points weet te implementeren. Voor een eerste Sprint moet dit grof geschat worden (op basis van andere projecten, de ervaring van het team, etc.). Voor alle volgende sprints kan dit gebeuren op basis van de realisatie in vorige sprints. Prachtige implementatie van CMMI!

Doel 2 gaat over het opzetten van een project plan

SP2.1 Bepaal het budget en schedule voor het project

Dit gebeurt in Scrum (en Agile) projecten principieel anders dan in traditionele (waterval) projecten. In watervalprojecten wordt geprobeerd vooraf de scope (de requirements) vast te leggen en van daaruit wordt berekend / geschat hoeveel tijd en geld benodigd is voor dit project. In Scrum werkt men andersom. Men gaat ervan uit dat er een vast team is om het project uit te voeren, en men legt de duur van het project vast (bijvoorbeeld 6 sprints van 4 weken). Vervolgens wordt bepaald hoeveel requirements (user stories) hiermee geïmplementeerd kunnen worden. De belangrijkste requirements worden (zo mogelijk) in de eerste sprints gebouwd. Verder wordt er ingespeeld op veranderingen in wensen van gebruikers (die toch wel zullen komen).

SP2.2 Identificeer de risico’s voor het project

Deze werkwijze is wat moeilijker te beoordelen. Enerzijds geldt dat de hele Scrum methode één grote aanpak in risico management is. De korte sprints leiden tot frequente feedback en maken daardoor risico’s van foutieve interpretaties van requirements, problemen met de testaanpak, etc. snel zichtbaar zodat erop gereageerd kan worden. Fail fast. Ook de werkwijze in de daily scrums is een vorm van risico management. Ieder teamlid benoemt elke dag wat hem tegenhoudt om zijn doelen te bereiken. Kleine probleempjes snel benoemen voorkomt dat er grote problemen ontstaan. Prima risico management. Aandacht voor risico’s is een duidelijke taak voor de Scrum Master. Anderzijds is dit allemaal wel erg binnen het projectteam gesitueerd. Een kritische kijk naar het grotere geheel ontbreekt expliciet in de methode, maar lijkt in de praktijk eenvoudig in te voegen. Omdat risico management zo impliciet zit ingebakken in de methode kan het ook moeilijk zijn voor CMMI assessors om duidelijk bewijs te vinden.

SP2.3 Plan het management van project data

Dit is één van de CMMI werkwijzen waarover veel onduidelijkheid bestaat, er zijn diverse interpretaties mogelijk. Op dit moment lijkt de consensus te zijn dat dit voornamelijk gaat over informatie beveiliging. Wie heeft recht om wat te zien en te veranderen. Daarover zegt Scrum helemaal niets. Dit is iets wat een Scrum team zelf zal moeten bepalen, mogelijk gestuurd door een policy op organisatieniveau.

SP2.4 Plan de resources om het project uit te voeren

Het woord resources wordt hier breed bedoeld. Mensen en andere hulpmiddelen. Het blijft een vreselijke term die de verwording van het angelsaksische managementdenken scherp zichtbaar maakt. Maar dat terzijde. Implementatie in een Scrum omgeving lijkt me triviaal. Een scrum team bestaat uit personen die aan het team worden toegewezen en die zoveel mogelijk full-time aan het team meewerken. Daarnaast heeft het team diverse hulpmiddelen nodig.

SP2.5 Plan de benodigde kennis van het projectteam

Doordat Agile methoden veel meer waarde hechten aan het vakmanschap dan traditionele methoden is dit in een Agile omgeving meestal prima geregeld. Bij de team samenstelling moet goed gekeken worden naar de kennis en vaardigheden van het team. Tijdens de retrospectives kan dit geëvalueerd worden en gaten kunnen door het team zelf opgepakt worden door het werk dynamisch anders te verdelen of door de teamsamenstelling te veranderen.

SP2.6 Plan het betrekken van belanghebbenden

Voor een Scrum team is er eigenlijk maar 1 echte externe belanghebbende: de product owner. Uiteraard zijn er vele anderen, eindgebruikers, beheerders, etc. Maar als het goed is houdt de product owner (met eventueel wat hulp van de scrum master) dat in de gaten.

SP2.7 Zet een project plan op

Scrum en Agile teams mikken op minimaal benodigde documentatie. Dat geldt voor technische documentatie maar ook voor het projectmanagement. En daar is in principe niets mis mee. Niemand zit te wachten op projectplannen van 40 pagina’s die toch niet gelezen worden door het team en externe belanghebbenden. Zolang er een goede documentatie is van de release planning, de product backlog, etc. is het project in goede handen. En die documentatie kan prima in de vorm van post-its op een Kanban board zijn (als de post-its er niet te gemakkelijk vanaf vallen 😉

Goal 3 gaat over het vastleggen en vasthouden van commitments

SP3.1 Review de plannen die het project beïnvloeden om commitments helder te krijgen

Dit is één van de CMMI werkwijzen waarmee ik altijd wat moeite heb. Als je alle info in het CMMI boek leest dan blijkt het te gaan over allerlei andere ‘subplannen’ van dit project. Het SQA Plan, het Testplan, etc. Nu is het natuurlijk nuttig om dat soort zaken consistent te krijgen, maar volgens mij is het veel belangrijker om ‘dit project’ met ‘naburige projecten’ af te stemmen. Afgaande op een letterlijke en beperkte interpretatie van de CMMI tekst hebben de meeste Scrum projecten het hier gemakkelijk. Er zijn vaak geen andere subplannen van het project en dus is alles per default consistent. Uitgaande van een zinvollere interpretatie van CMMI (IMHO) gaat het hier om een afstemming waarvoor Product Owner en Scrum Master verantwoordelijk zijn. Doordat deze verantwoordelijkheid duidelijk belegd is, heb ik er over het algemeen wel vertrouwen in dat dit wordt opgepakt.

SP3.2 Balanceer benodigde en beschikbare resources

Door per sprint de velocity opnieuw te meten wordt heel snel duidelijk of dit team in staat is de doelen van het project te behalen. Op basis van die informatie (die prachtig zichtbaar wordt in sprint en release burndown charts) kan bijgestuurd worden. Groter team, meer teams, minder user stories, etc.

SP3.3 Verkrijg commitment van relevante belanghebbenden in de uitvoering van het project

Hiervoor is de sprint planning meeting bedoeld. De user stories worden besproken, ingeschat (gepokerd) en het team commit zich aan de sprint backlog.

Samenvattend: door Scrum toe te passen wordt het overgrote deel van (de geest van) CMMI Project Planning geïmplementeerd.

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in CMMI, Scrum, software engineering and tagged , , . Bookmark the permalink.

One Response to Scrum en CMMI – Project Planning

  1. Pingback: Scrum en CMMI – Project Monitoring and Control « Andre Heijstek's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s