De Daily Scrum, in de volksmond de ‘stand up’ genoemd. Waarschijnlijk het meest bekende event als we het over Scrum hebben. Een event dat maximaal 15 minuten duurt en waarbij het Developers het plan van de sprint inspecteert en bekijkt of dit plan nog steeds valide is. Dat is het! Niets meer en niets minder. Desondanks gaat er in deze 15 minuten bij veel teams het nodige mis. Hieronder de meest voorkomende problemen tijdens een Daily Scrum en hoe dit op te lossen.
Het ‘status update’ overleg
Dit staat helaas met stip op nummer één bij de meeste teams! Vaak is het de (project) manager, Product Owner of de Scrum Master, de persoon waaraan het team verantwoording afgelegd wat er de afgelopen dat is gedaan en wat men de komende dag gaat doen. Vreemd! Want deze rollen hebben geen van allen een actieve rol tijdens een Daily Scrum.
Het doel van de Daily Scrum is voor Developers om gezamenlijk te inspecteren of het plan dat zij hebben gemaakt in de Sprint planning nog steeds valide is. Door het delen van relevante informatie die mogelijk van impact zijn om de planning bepaalt het team of er mogelijk moet worden bijgestuurd. Het is aan de Scrum Master om Developers te leren hoe dit te doen. Als er opnieuw gepland moet worden, pas dan is het nuttig om Product Owner te betrekken in de discussie (wanneer het om scope gaat). Vaak zie ik een aantal zaken mis gaan.
3 vragen
Om de informatie naar boven te halen gebruiken veel teams de volgende drie vragen:
- Wat heb ik gisteren gedaan dat ons heeft geholpen het Sprint Goal te bereiken?
- Wat ga ik vandaag doen om ons te helpen het Sprint Goal te bereiken?
- Zie ik enig obstakel die mij of andere Developers in de weg staat het Sprint Goal te bereiken?
Het doel van deze drie vragen is ook puur om de informatie te delen wat relevant is om de sprint backlog te inspecteren en te valideren of we als team nog op de goede weg liggen. Niets meer en niets minder. Deze drie vragen zijn niet verplicht en wat ik vaak zie is nadat iedereen deze drie vragen heeft beantwoord men stopt met de Daily Scrum. Maar dan ben je nog niet klaar! Sterker, dan begint het pas! Nu heb je de informatie gedeeld waarop je als team kunt zien of je moet bijsturen. Het gaat niet om het beantwoorden van de drie vragen. Het gaat om wat je met de gedeelde informatie doet! Is er niets bijzonders te melden en gaat het allemaal op rolletjes dan is een Daily Scrum in een paar minuten voorbij!
Te hard werkende Scrum Master
Als je als Scrum Master je werk goed doet heb je niet zoveel te doen. Echter blijken Scrum Master die onvoldoende zijn getraind dit niet door te hebben. Tijdens de Daily Scrum heb je als Scrum Master geen actieve rol. Dus als jij als Scrum Master optreed als gespreksleider, de wie-is-er-nu-aan-de-beurt-gever en kaartjes verhanger. Dan ben je niet goed bezig! Dat kunnen mensen prima zelf regelen.
Als Scrum Master moet jij het team leren het doel van de Daily Scrum te begrijpen (inspecteren of herplanning nodig is) en hoe zij dit in maximaal 15 minuten kunnen doen. Te hard werkende Scrum Masters veroorzaken hierdoor vaak meer problemen waarvan er een aantal in deze post voorbij komen. Pak als Scrum Master een kop koffie en laat het team zichzelf organiseren in deze 15 minuten. Zo heb je je handen vrij en kun je je bezig houden met die dingen die worden gezegd (of niet worden gezegd).
Onbeantwoorde hulpvragen
Wanneer een team last heeft van een overactieve of inhoudelijk te betrokken Scrum Master is de (onuitgesproken) hulpvraag het meest over het hoofd gezien door de Scrum Master en het Development Team. Een klein voorbeeld wat ik onlangs heb meegemaakt tijdens een Daily Scrum waarin een nieuw teamlid aan het woord was. Dit is wat er gebeurde:
Teamlid: “ Ik wil vandaag met deze taak (wijst de taak aan) aan de slag, maar ik weet niet zo goed hoe ik dat moet aanpakken.”
Rest van het team, inclusief de Scrum Master: “…”
Teamlid: “Ik heb me verdiept in het onderwerp maar ik twijfel erover of dit de juiste aanpak is.”
Rest van het team, inclusief de Scrum Master: “…………….”
Teamlid: “Het zou fijn zijn als iemand even mee kan kijken zometeen.”
Rest van het team, inclusief de Scrum Master: “…………………….”
Vervolgens de Scrum Master: “Dat was het? Ok, volgende, eh Piet jij?”
Op dat moment greep ik in en heb het team geconfronteerd met wat hierboven gebeurd. Iemand stelt tot drie keer toe een hulpvraag. Niet met een vraagteken maar het is wel degelijk een hulpvraag en niemand reageert. Dit was een harde les voor het team dat elkaar niet helpt en de Scrum Master die veel te druk bezig was om de 15 minuten te managen, briefjes te verhangen ipv te luisteren wat hier gebeurd. Dit is waar een Scrum Master scherp op moet zijn en wat een Scrum Master het team moet leren om dit zelf te herkennen.
Gebrek aan transparantie
Veel teams gebruiken nog een fysiek bord maar wat vaak ontbreekt is het inspecteren van de burn down chart. Een practice die het team helpt om te monitoren hoeveel werk er nog resteert en hoe men bezig is, over de tijd heen, zaken af te maken. Teams die gebruik maken van een tool zoals JIRA of Azure Devops hebben deze functionaliteit wel tot hun beschikking maar deze wordt weinig geïnspecteerd. Wat deze teams vaak doen, naast het behandelen van enkel de 3 vragen t.b.v. de status update. Is individueel werk inspecteren in plaats van de feature die men probeert te realiseren. Zowel JIRA als Azure hebben filters die een Sprint Backlog kunnen sorteren per teamlid en de taken waar deze persoon mee bezig is.
Zo verliest het team focus op het afmaken van features en is men vooral bezig met optimale inzet van de beschikbare capaciteit.
Dit laatste zorgt ook voor minder interessante discussies tijdens een Daily Scrum. Omdat men bezig is met individuele focus is het gemakkelijker om als teamlid niet transparant te zijn over het werk dat je bijdraagt aan het Sprint Goal. Ook hier is het aan de Scrum Master om het team met dit gedrag te confronteren. Door simpelweg de wijze van het presenteren van informatie dusdanig aan te passen waardoor er andere discussies ontstaan.
Vrije dag/thuiswerken
Tot slot, de situatie dat een collega een vrije dag heeft of een thuiswerkdag heeft. Dit zorgt vaak voor onnodige problemen in een team. Laat ik eerst stellen. Part-time of thuiswerken kan prima in een Scrum Team. Echter moet een team hier wel afspraken over maken hoe hiermee om te gaan. Regelmatig zie ik teams die tijdens een Daily Scrum er achter komen dat de collega een vrije dag heeft. Of hij/zij thuis werkt zonder enige informatie achter te laten. Vervolgens probeert men te achterhalen hoe ver de collega is gevorderd en hebben twee collega’s nu net juist dit werk nodig om verder te kunnen. Onbegrijpelijk dat een team dit niet weet te ondervangen terwijl de oplossing kinderlijk eenvoudig is.
Situatie 1: Collega heeft een thuiswerkdag. prima, dan belt deze in via Skype of gewoon de telefoon. Zo kan er nog steeds informatie worden gedeeld en voor het verhangen van taken is vast wel iemand anders uit het team beschikbaar.
Situatie 2: Collega heeft vrije dag. Het team maakt met elkaar de werkafspraak dat in zo’n geval de collega die een vrije dag heeft niet een cruciale taak oppakt zonder dat je zeker weet dat deze is af te ronden. Of de collega zorgt aan het einde van de dag dan in ieder geval 1 persoon in het team weet hoever je bent. Op deze manier is de informatie altijd geborgd en hoeft de collega niet te worden gestoord tijdens de vrije dag.
Dit heeft niets te maken met de rol van de Scrum Master of het goed toepassen van Scrum. Dit is gewoon puur professioneel samenwerken!
Een lange blog over een ogenschijnlijk simpel en kort overleg als je met Scrum werkt. Worstel jij hiermee? Of wil je dergelijke situaties voorkomen wanneer je met Scrum gaat starten? Dan is de Professional Scrum Master training een must!
