Wat doet de Scrum Master precies?
Zoals je eerder in een blog hebt kunnen lezen, werkt Cherry met ontwikkelingsmethode Scrum. Binnen het Scrum team zijn er verschillende rollen. Zo heb je de Product Owner, de Scrum Master en de developers. De Scrum Master is degene die ervoor zorgt dat het hele Scrumproces in goede banen wordt geleid. Binnen Cherry is dit Ernst Erik. Naast dat hij ervoor zorgt dat het Scrumproces precies loopt zoals het hoort, is hij ook vormgever en webdesigner. Hoog tijd voor een gesprek.
“Scrum is een methode die bedacht is om beter samen te kunnen werken als team en sneller resultaten te behalen”, vertelt Ernst Erik. “In ons geval gaat het om websites bouwen. Vroeger bouwden we eerst de site en kreeg de klant pas aan het eind het resultaat te zien. Nu is het proces ‘opgeknipt’ in verschillende stapjes, waardoor er meerdere feedbackrondes zijn. Op die manier worden problemen en verkeerde communicatie voorkomen. Bovendien zijn klanten vaak meer tevreden met het uiteindelijke product.”
Jij bent Scrum Master, wat is dat precies?
“Heel simpel eigenlijk; ik zorg ervoor dat de methode goed gevolgd wordt. Vanuit Scrum zijn er bepaalde guidelines om het scrumproces in goede banen te kunnen leiden. Ik heb daarvoor ook een opleiding gevolgd. In twee dagen leer je door praktijkgerichte opdrachten en theorie wat de verantwoordelijkheden van de Scrum Master zijn en hoe je dit het beste kunt uitvoeren.”
Wat zijn de belangrijkste taken van jou als Scrum Master?
“Mijn belangrijkste taken zijn:
- Ten eerste de Dailyscrum. Dit doen we iedere ochtend en mag maximaal een kwartier duren. Ik zorg ervoor dat het nooit langer dan een kwartier duurt en dat er wordt gepraat over wat er op dat moment belangrijk is. Problemen bij een bepaalde taak kunnen we na de Dailyscrum bespreken.
- Ten tweede zorg ik er gedurende de week voor dat de volgorde van de backlog wordt aangehouden. De volgorde wordt gemaakt door de product owner, maar ik zorg dat ook hierbij de regels vanuit Scrum worden aangehouden.
- Als laatste de retrospective. Dit is een stukje teambuilding wat plaatsvindt na de Sprint Review op vrijdagmiddag. Deze bereid ik voor, ik bedenk opdrachten en tijdens de retrospective doen we dit.”
Die backlog, hoe werkt dat dan?
“Aan het begin van de week bepalen we de backlog. Ieder item op de backlog noemen we een ‘story’ en aan een story hangen ‘tasks’. Die taken kunnen verdeeld worden. Iedere story krijgt een aantal punten. Een punt wordt altijd gegeven op basis van hoelang er geschat wordt ergens mee bezig te zijn, maar ook van de moeilijkheidsgraad. Iets kan veel tijd kosten, maar relatief simpel zijn, daar wordt dan balans in gezocht. Dit maakt dat we elkaar beter kunnen helpen, want je hebt sneller in de gaten of iemand vastloopt. Als we ergens vijf punten aangeven en iemand is er twee dagen mee bezig, dan weet je dat er iets mis is. Daarnaast kom je dankzij deze manier van werken ook aan taken toe die je misschien zelf niet zou kiezen. Omdat je altijd van boven naar beneden werkt, krijgt iedereen stories toegewezen. Zo is een van onze webdevelopers tegenwoordig ook wel eens aan het ontwerpen en ik ben ook aan het programmeren. De specialiteiten worden meer verspreid.”
Hoe geef je die punten aan een story?
“Zoals ik zei, een punt is altijd een combinatie van tijd maar vooral van moeilijkheid. Je geeft punten via de rij van Fibonacci. 0 is bijna niet de moeite waard om te noemen. Daarna heb je 1, 2, 3, 5, 8, 13, 20 en hoger. Wij gaan eigenlijk nooit hoger dan 13, omdat we in Sprints van een week werken. Sommige bedrijven werken met sprints van een maand. Wij splitten projecten vaak op, dus hoger dan 13 punten zie je bij ons niet.”
Is de Scrummethode eigenlijk alleen voor webdesigners?
“Dat denken veel mensen, maar dat is niet zo. Er zijn hele grote bedrijven die ermee werken, denk aan een Bol.com of Coolblue. De gedachtegang komt uit het programmeren. De methode is ontstaan omdat men zag dat klanten ontevreden waren na oplevering van een product. Het voldeed vaak niet aan de verwachting en wensen van een klant. Daarom knippen we de opdracht in stukjes en vragen we per deel feedback. Op die manier is de communicatie beter en zorgen we voor een goed eindproduct tegen – uiteindelijk – lagere kosten. Het voorkomt irritaties vanuit zowel de klant als de programmeurs.”
