Ervaringen met Scrum

Enige tijd geleden ben ik begonnen op een project waar Scrum wordt gebruikt.
Hier mijn eerste ervaringen met Scrum:

Wie let er op het tempo?
Aangezien het hele team de baas is, is er dus niemand echt de baas. Wie houdt er dan in de gaten of de velocity van 60 storypoints wel ambitieus is, of dat er eigenlijk wel 80 storypoints door het team gehaald kunnen worden?
De product owner kan het niet inschatten, en een langzaam team ziet wellicht niet hoe langzaam ze zijn.

Daily standup is nuttig.
Het is niet altijd even leuk voor elk teamlid om met de billen bloot te moeten elke dag, maar met deze meeting is het wel erg duidelijk of er voortgang wordt geboekt of dat mensen blijven hangen in bepaalde stories.

Retrospective rules.
Onze sprints duren 2 weken. Dat wil zeggen dat we elke 2 weken terugkijken over hoe het is gegaan; wat er goed is gegaan en wat er beter had gekund. En dat is gewoonweg awesome. Elke 2 weken een kans om bij te sturen, om echt na te denken of we op de goede weg zitten, en ook dus bij te kunnen sturen.
Dat vind ik echt veel beter dan aan het einde concluderen dat het allemaal anders had gemoeten.

Twee-wekelijks opleveren; directe feedback
Meer dan eens wordt er maanden achtereen code geschreven zonder dat een stakeholder er iets van ziet. Dikke kans dat het na al die maanden niet exact overeenkomt met wat die stakeholders in gedachten hadden. Dus het 2-wekelijks opleveren van software geeft niet alleen regelmatig aan hoe de voortgang is, maar geeft ook al snel inzage in wat er ontwikkeld wordt.

Schatten van de userstories
Het schatten van userstores, hier gedaan in storypoints maar het kan ook prima in uren, met meerdere mensen is een prima middel gebleken om al vroeg te discussieren over complexiteit van userstories en wat ze eigenlijk precies inhouden.
Ook geldt in dit geval: twee weten meer dan een dus de schatting is accurater dan wanneer één iemand zich hier mee bezighoudt.

Echte betrokkenheid met degene voor wie je het doet door de directe communicatie
Een productowner die in dezelfde ruimte zit als waar het development team zit en altijd aanspreekbaar is: wat een luxe!
Geen ‘het zal wel dit zijn’ meer maar direct vragen wat gewenst is. Een absolute kwaliteitverbeteraar.

Goede scrummaster onontbeerlijk
De titel zegt genoeg; een scrummaster kan met een neutrale blik (want niet in het team) bekijken of het proces goed loopt.

Userstories beter dan MS-Word proza.
We werken hier met userstories in een vast formaat: AS A — I WANT — SO THAT.
Bijvoorbeeld AS A user I WANT to be able to see the unread email indicated SO THAT i can easily see which email i have to process.
En dat is wellicht wat meer werk voor de product owner dan een standaard MS-Word document, maar als developer werkt het wel een stuk prettiger als de specificaties op deze manier zijn geschreven.
Vooral het laatste, SO THAT, ofwel het waarom, is vaak erg verduidelijkend.

Sterke productowner
Je moet wel een sterke product owner hebben. Hij of zijn bepaalt namens alle gebruikers en belanghebbenden. Voordeel is wel dat dat uitzoekwerk buiten de scope van de developer plaatsvindt maar je hoort alleen de conclusie, en niet de discussie vooraf. Degegen bij wie je later je info haalt moet dan ook wel goed op de hoogte zijn.

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