Iedereen die met Scrum begint, hoort van het event die in Scrum beschreven staan. Een daarvan is de Daily Standup. We beginnen er vol enthousiasme aan maar al snel is het lastig en voelt het als storende factor in onze dagplanning. Waarom is dit event in Scrum zo belangrijk dan? En hoe kunnen we er uithalen wat we nodig hebben om betere producten te leveren en er dus echt iets aan hebben?
Scrum probeert de problemen van traditionele, waterval-projecten te ondervangen door kortere iteraties te houden. In Sprints van 1-4 weken worden stukjes product afgemaakt zodat deze opgeleverd kunnen worden. Feedbackmomenten zijn een standaard en belangrijk onderdeel van Scrum om ervoor te zorgen dat iedereen de meest waardevolle bijdrage kan leveren en de onderlinge samenwerking te maximaliseren. De Daily Standup is een van die feedbackmomenten. Dagelijks, liefst in de ochtend voor ieder met zijn werk begint, bij elkaar te komen en te bespreken waar men mee bezig is geweest en vandaag aan zal gaan werken om dichterbij het sprintdoel te komen. Zo is ieder op de hoogte van voortgang en kan er afstemming plaatsvinden in planning voor die dag. Stel je hebt de expertise van een collega nodig om verder te kunnen, dan kun je dat in de DSU aangeven en plannen voor die dag. Daarnaast is het ook een goed moment om aan te geven waar je tegenaan gelopen bent of wat je denkt te gaan tegenkomen. Hierdoor kan snel en vroeg worden gekeken naar oplossingen en dat zorgt voor een doorlopende flow in productiviteit. Daarmee hebben we het doel van de DSU benoemd en is bekend waarom we dit Scrum event dagelijks willen doen.
Wie is erbij? Het ontwikkelteam is er in ieder geval. Daarnaast kunnen de Scrum Master en Product Owner aansluiten om mee te luisteren. Niet om een verantwoording van uren te krijgen maar om te helpen wanneer bijsturen of oplossen van problemen nodig is. Het team is dus ook niet gericht op het verantwoorden van wat ze hebben gedaan aan anderen. De focus is het afstemmen van planning en kijken hoe ze samen weer dichterbij het Sprintdoel kunnen komen en User Stories op hoge kwaliteit af kunnen maken. Als laatste zouden er ook stakeholders bij kunnen komen staan. Ook voor hen geldt dat het geen verantwoording naar hen is. Behalve de leden van het team, zijn de andere aanwezigen stil en luisteren alleen. Hebben ze vragen, dan kan dat na de DSU gedaan worden.
Wat is een goede tijd? Uiteraard is dat voor ieder team mogelijk anders. Over het algemeen is het direct als het team start met werken in de ochtend. Stel je begint om 8.30u. Even de tijd om rustig binnen te komen, wat te drinken te pakken en nog even door te nemen wat je gedaan hebt de dag ervoor. Daarnaast kun je dan even het Scrumbord bekijken wat er nog open staat en wat je vandaag gaat doen. Dan om 9.00u. de DSU en met het team afstemmen wat zij hebben gedaan, gaan doen en of ze iemand van het team nodig hebben. Niemand gaat te diep in op de (technische) details. En uiterlijk 15 minuten later, kan iedereen aan de slag en waar nodig verder in details gaan met de persoon die erbij betrokken moet worden.
Het is verstandig om een vaste tijd te nemen. Voor jezelf als team is dat prettig en kun je daar een regelmaat en gewoonte van maken. Daarbij is het goed aangezien anderen daar dan bij kunnen aansluiten. Die betrokkenheid is ook heel waardevol in het kader van transparantie en openheid. Het scheelt tijd voor de Product Owner als stakeholders op die manier betrokken en op de hoogte blijven.
Naast de drie vragen die besproken worden, zou de focus moeten liggen op het Scrumbord en dus de huidige Sprint backlog. Waarom? Die laat zien wat er nog open staat, wat je ook alweer samen afgesproken had en commitment op gegeven had om te kunnen maken deze Sprint. Het laat, samen met de BurnDown, zien of er impediments ontstaan zijn en of er dingen blokkerend zijn die aandacht vereisen. Het herinnert je eraan dat je gecommit hebt op die puntjes die daar staan. Het is zo gewoon en bijna automatisch om te denken in technische details en oplossingen. Het gaat vaak inderdaad vanzelf om te gaan discussiëren over implementatiedetails. Laat je niet verleiden daarin mee te gaan en help elkaar de focus op de juiste aspecten te houden. Die details zijn zeker belangrijk, maar voor na de DSU.
Meer weten over hoe jullie de DSU kunnen verbeteren of heb je andere vragen, neem dan gerust contact op via [email protected] of het contactformulier