Recent kwam ik op scrum.org een interessante blog tegen. Deze blog deed mij denken aan veel dingen van Scrum die ik tijdens mijn training voor Scrum master heb geleerd. En vooral ook aan de dingen die vaak genoemd worden door de mensen die niet zo’n grote voorstander van Scrum zijn.

Wat is Scrum?

Volgens mij zien veel mensen Scrum als een werkwijze die veel dingen verplicht in het proces waarin een team werkt. Niets is echter minder waar! Scrum is bedoeld als een framework om teams een flexibele manier van werken te bieden. Natuurlijk zijn er wat vaste elementen, maar verder heeft een team alle ruimte om te groeien als een zelfsturend team. En dit is meteen ook de kern van Scrum, het team. Zij zijn samen verantwoordelijk voor hetgeen ze aan werken. Van het invullen van de gewenste functionaliteit tot en met het plannen en testen. Waaruit bestaat nu een scrum team?

De Product Owner maakt samen met de klant en andere stakeholders een backlog met daarop alle vereisten. Een zo’n vereiste wordt een ‘User Story’ genoemd. Hierbij is het belangrijk dat de belangrijkste features als eerste geïmplementeerd worden. Het team maakt van elke user story een inschatting van de benodigde ontwikkeltijd of complexiteit. Dit inschatting gebeurt in uren of story points.

Het team (en de organisatie!) worden begeleid door een Scrum Master. Deze zorgt ervoor dat elke dag een ‘Daily Standup’ gehouden wordt, welke maximaal 15 minuten duurt. Het doel hiervan is om elke dag een goede voortgang te houden en eventuele problemen snel te tackelen. Heel veel mensen zeggen dat bij zo’n standup de volgende drie vragen beantwoord moeten worden door ieder teamlid;

  1. Wat heb ik gisteren gedaan?
  2. Wat ga ik vandaag doen?
  3. Zijn er problemen?

Maar als ik zelf als Scrum Master een team coach zorg ik altijd dat er maar een vraag beantwoord wordt, namelijk ‘Zijn er nog problemen of bijzonderheden?’ Dat is namelijk het enige in mijn ogen wat er interessant is tijdens een standup. Mensen zijn heel snel geneigd zich te gaan verantwoorden en te vertellen wat ze gedaan hebben, maar dit zijn juist de eenvoudige dingen die elk teamlid op het scrum board kan volgen. Dus waarom het nogmaals vertellen?

Tot slot heb je natuurlijk het development team. Het development team bepaalt zelf hoe het werk georganiseerd wordt, wat zorgt voor een efficiëntie en effectieve samenwerking binnen het team. Uiteindelijk is het volledige scrum team samen verantwoordelijk voor opleveren van een werkend product aan het einde van een twee of vier wekelijkse sprint.

Een sprint is een twee- tot vier-wekelijkse iteratie waarin een team werkt. Met als doel om aan het einde van een sprint een werkend product op te leveren. In een sprint wordt alles gedaan, van refinement (bijv. nadenken over de layout) tot ontwikkelen en het testen. Doordat dit allemaal in een sprint gedaan wordt heb je niet alleen snel resultaat, maar ook heel snel feedback van de stakeholders.
Het presenteren van deze resultaten gebeurt in een sprintreview, voor het organiseren hiervan is de Scrum Master ook verantwoordelijk. Bij zo’n review is het volledige team aanwezig inclusief eventuele stakeholders voor het product of project waar het team aan werkt.
Na een sprintreview houdt het scrumteam een sprintretrospective. In deze retrospective evalueert het team de afgelopen sprint om te kijken waar ze zich kunnen verbeteren. Deze verbeterpunten worden bijgehouden en in een volgende sprint meegenomen. Door deze cyclus blijft het team zich continu verbeteren waardoor de agile maturity van het team toeneemt. Het organiseren van de retrospective is ook een verantwoordelijkheid van de scrum master.

Scrum in complexe omgevingen

Persoonlijk vindt ik het scrum framework echt fantastisch werken. Maar moet het nu overal en altijd toegepast worden? Dat zeer zeker niet. Voor hele kleine organisaties of hele simpele projecten zijn er ook andere methoden die misschien wel beter werken. Scrum werkt vooral goed in complexe omgevingen.

Om te bepalen of je in een complexe omgeving zit of niet kan er gebruik gemaakt worden van de stacey matrix;

Scrum werkt vooral goed in complexe omgevingen omdat er niet eerst een onderzoek en plan vooraf nodig is. Je kunt gewoon beginnen met een requirement die helder is en gaandeweg kom je vanzelf nieuwe requirements tegen of worden de wensen en eisen van de product owner en stakeholders bijgesteld. Snel, in korte iteraties en efficient. Vooral transparantie naar de product owner en het tussentijds bijsturen zijn hier van belang.