Scrum en CMMI – Project Monitoring and Control

Scrum Master: Defending against interruption

Image by J'Roo via Flickr

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 Monitoring & Control. Is Scrum hiervan een goede implementatie?

Het doel van Project Monitoring & Control is om inzicht te krijgen in de projectvoortgang zodat er bijgestuurd kan worden.

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 Monitoring and Control (PMC) heeft 2 specifieke doelen. Doel 1 gaat over het monitoren van de voortgang. Hierin is een sterke link te zien naar Project Planning. Wat gepland wordt moet ook bewaakt worden. Bij doel 1 behoren 7 werkwijzen (specific practices).

SP1.1 Monitor de waarden van de planning parameters ten opzichte van de planning

Dit gebeurt in Scrum op 2 manieren. Aan het einde van elke sprint wordt in een demo getoond hoe de geplande user stories zijn gebouwd. Daarnaast wordt de voortgang grafisch zichtbaar gemaakt in de burndown charts. Hiermee wordt bewaakt of het geplande aantal story points wordt gebouwd in elke sprint. In traditionele CMMI projecten wordt vaak de earned value methode toegepast. Een burndown chart is niets anders dan earned value made simple.

SP1.2 Monitor de commitments ten opzichte van de planning

Ik interpreteer commitments hier altijd als beloften. CMMI spreekt hier over interne en externe commitments. Interne commitments zijn die van het ontwikkelteam zelf. Zij beloven bij de sprint planning meeting om in deze sprint de sprint backlog te implementeren. Dat commitment wordt dagelijks bewaakt in de daily scrums en tijdens de demo wordt zichtbaar of dat al of niet gelukt is. Externe commitments zijn beloften die mensen van buiten het team maken aan het team. Een DBA kan een database opzetten zodat getest kan worden, of netwerk management zorgt dat verbindingen met externe servers opgezet worden. Er is geen expliciet mechanisme in Scrum om dit te bewaken, maar het ligt erg voor de hand dat dit een taak is voor de Scrum Master.

SP1.3 Monitor de risico’s ten opzichte van de planning

Zoals al in de eerdere post over Project Planning aangegeven, heeft Scrum weinig expliciete aandacht voor risico management. Een heel nuttige suggestie vond ik in een blog van Mike Cohn waarin een risk burndown chart werd geïntroduceerd.

SP1.4 Monitor het management van project data ten opzichte van de planning

Er is in Scrum geen expliciete aandacht voor data management, niet voor de planning ervan en dus ook niet voor de monitoring.

SP1.5 Monitor het betrekken van belanghebbenden ten opzichte van de planning

Zoals ik al schreef bij Project Planning probeert Scrum alle belanghebbenden te verenigen in de rol van de product owner. Als hij zijn rol goed speelt hoeft alleen zijn betrokkenheid bewaakt te worden. Hopelijk is de PO regelmatig aanwezig als luisteraar bij de daily standups en een demo zonder PO is niet mogelijk. Als ik een CMMI appraisal zou uitvoeren op een Scrum project zou ik wel in het interview met de PO goed navragen hoe hij zijn rol oppakt naar de andere belanghebbenden toe. Een PO die zijn kantoor niet uitkomt is een groot gevaar voor het project!

SP1.6 Review de voortgang, prestatie en problemen van het project periodiek

Dat is in Scrum heel expliciet opgenomen. Daily scrums en demo’s zijn een kernelement in de aanpak.

SP1.7 Review de verwezenlijkingen (accomplishments) en resultaten van het project op regelmatige mijlpalen

Met name op het terrein van de “verwezenlijkingen” is Scrum veel sterker dan traditionele methoden. Er  ligt veel nadruk op werkende software (potentially shippable product) in plaats van op papieren resultaten (alle design documentatie is af).

Noot: ik vind “verwezenlijkingen” geen echt mooie vertaling van accomplishments, maar vond geen betere. De kleine CMMI vertaalt hier met “verrichtingen” maar dat mist net het punt. Het gaat niet om de activiteiten die we doen maar om werkende software die wordt opgeleverd.

Doel 2 van PMC pakt de resultaten van alle monitoring activiteiten uit doel 1 op en start de correctieve acties. Er zijn 3 werkwijzen. Dit zijn eigenlijk 3 kleine en sterk bij elkaar behorende taken. Ik bespreek ze dan ook als geheel.

SP2.1 Verzamel en analyseer de issues en bepaal welke correctieve acties nodig zijn

SP2.2 Voer de correctieve acties uit

SP2.3 Bewaak dat de acties volledig worden uitgevoerd (beetje vrije vertaling van manage corrective actions to closure)

Er zijn twee logische plaatsen om dit uit te voeren: daily scrum en sprint demo. Risico voor een CMMI appraisal kan zijn dat er onvoldoende bewijs is. Het lijkt (ook buiten de wat bureaucratische gedachte om papier achter te laten voor de appraisers) wel zinvol om grotere acties als een extra user story op de backlog te zetten.

Ook deze process area wordt dus grotendeels geïmplementeerd door Scrum. Scrum biedt dus een goede bijdrage aan een CMMI programma. Is het omgekeerde eigenlijk ook het geval? Heeft CMMI organisaties nog wat te bieden als ze Scrum al geïmplementeerd hebben of kunnen we CMMI inmiddels als achterhaald beschouwen? Lijkt me een aardig onderwerp voor een volgende blog.

Advertisements

About André Heijstek

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

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