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.

Advertisements

Nice Scrum talk in DotNet rocks!

Today i listened to episode 585 of .Net rocks.
And i must say, it turned out to be a very nice show about Scrum with Richard Hundhausen.
A lot of questions i had after reading a few books about scrum were answered here.
So if you have 45 spare minutes in the car and you’re interested, you can download the episode here:

http://www.dotnetrocks.com/default.aspx?showNum=585

And for the Dutch listeners: the soccer worldcup final is also mentioned.

Wanneer is het af?

Elke developer krijgt de vraag als je hebt aangegeven dat je weet wat er gebouwd gaat worden (of als je nog geen flauw idee hebt, als iemand je in 1 minuut een systeem heeft uitgelegd dat minimaal 5 manjaar kost om te bouwen, maar dat terzijde): wanneer is het af?

Ik ben een boek aan het lezen en daar is hun advies om als antwoord te geven: “I’ll get back to you”. (‘t is namelijk een Engels boek :-)). Dit omdat in hun ogen, en daar ben ik het wel mee eens, je een meer accuratere schatting krijgt als je er even over kunt nadenken.

Anyway, het punt dat ik interessant vond is het volgende. Als je denkt met iets een half jaar bezig te zijn, dan maakt het niet alleen uit hoe je het brengt, maar ook welke eenheid je gebruikt. Is een beetje uit de wiskunde; hoe kleiner je de eenheid kiest, hoe nauwkeuriger je aangeeft te zijn.
Gebruik je in dit voorbeeld bijvoorbeeld ‘een half jaar’, dan zal een goed verstaander al rekening houden met een maand of 8. Zeg je ‘6 maanden’, dan klinkt het al als tussen de 5 en 7 maanden. Zeg je echter ‘180 dagen’, dan klinkt het al alsof je verwacht er niet veel langer over te doen dan een dag of 180 à 190.

De auteurs van het Agile developer boek geven daarom aan in welke eenheid je moet schatten, afhankelijk van de tijd die je er voor nodig denkt te hebben. De laatste regel bevat een mooie tip: verwacht niet dat je meer dan een half jaar vooruit een accurate schatting kunt maken. Dat komt ook voor in Scrum: je kunt een sprint (van 30 dagen) accuraat plannen, de sprints van daarna al globaal, maar hoe verder vooruit, hoe minder accuraat het wordt.

Maar vooruit, dan eindelijk de tabel waar het allemaal om ging….

Als je denkt aan… Plan in
1 – 15 dagen dagen
3 – 8 weken weken
8 – 30 weken maanden
meer dan 30 weken Geef geen planning af