Om maar meteen met de deur in huis te vallen: het deed me pijn! Veel pijn! Ik probeerde een team te helpen dat de helft van hun commitment voor de sprint nog niet had volbracht, en ze waren niet eens teleurgesteld!
Als Scrum Master voelt dit als een stomp in je maag. Hoe kunnen mensen iets beloven en niet van streek raken als ze die belofte niet kunnen nakomen?
Dit is het verhaal van een team dat hun sprint doel niet heeft bereikt. Uiteraard zal ik mijn gedachten delen over wat er is gebeurd en mijn mening geven over hoe het team met de uitdagingen omgaat. Maar laten we eerst beginnen met het verhaal zelf!
Toewijding aan de sprint
We gingen van start met een geweldig doel, selecteerden de juiste User Stories en waren klaar om de planningssessie af te ronden. Er ligt slechts één hindernis voor ons: commitment. Als Scrum Master van dit team zag ik geen enkel probleem waarom we ons niet konden committeren aan dit Sprint doel en User Stories.
En ik had gelijk! Het team gaat voluit voor de sprint! En ja, ik was een gelukkige Scrum Master. Het team maakte een plan voor de komende twee weken en was klaar om van start te gaan!
De eerste Daily Scrum na de planning verliep goed. Iedereen had er vertrouwen in dat ze het Sprint doel zouden halen en met alle geplande stories zouden slagen. Het voelt alsof we die Daily vlogen. Maar een paar Daily Scrums later raakten we achter op de planning. Onze Burndown was ver verwijderd van de ideale lijn die Jira suggereerde.
“Wat moeten we doen om weer op het goede spoor te komen?” Ik vroeg het aan het team. Ze hadden geen idee. Het team was betrokken, maar de teamleden verdeelden veel werk. Ieder teamlid had zijn werk zonder verbinding met de andere teamleden.
Zoals je al raadde, hebben we ons Sprint-doel niet bereikt en konden we slechts de helft van de geselecteerde User Stories verwerken.
SOPHIA Ontdek hoe je de aanpak van SOPHIA ook in jouw organisatie kunt doorvoeren om wendbaar en inclusief te organiseren. Download gratis de eerste 2 hoofdstukken van dit nieuwste boek.
Download de eerste 2 hoofdstukken
De wijsheid van wendbare organisaties
Tijdens de retrospective heb ik dit probleem ter tafel gebracht. Wat ging er mis tijdens deze sprint? Het team mompelde alleen maar, mijn vraag stoorde het team meer dan het feit dat ze sprint niet gehaald hadden. Waarom was dit team niet eens teleurgesteld dat ze hun eigen doelen niet bereikten?
Verantwoordelijkheid en aansprakelijkheid
De blije Scrum Master uit de Sprint planning was tijdens de Retrospective meer teleurgesteld. Hoe was het mogelijk dat een team van volwassenen niet eens teleurgesteld in zichzelf was? Waarom stelden ze hun manier van werken niet ter discussie? Waarom waren ze tevreden met deze slechte resultaten?
Gelukkig was dit ook een goed onderwerp voor een Retrospective, dus hebben we erover gesproken. Het blijkt dat het team zich helemaal niet heeft gecommitteerd aan het sprint doel. “Huh, ben ik zo’n slechte Scrum Master dat ik niet zag dat ze zich niet committeerde maar dacht dat ze dat wel gedaan hadden?” Het korte antwoord is gelukkig: “Nee!”.
Het langere antwoord gaat over wat ze in plaats daarvan wel gedaan hebben. Tijdens de planningssessie had het team de taken al verdeeld. Elk teamlid heeft zich dus wel gecommitteerd, maar alleen voor zijn of haar taken, niet voor de teamtaken. In werkelijkheid committeren ze zich dus nooit aan de sprint als geheel.
Tijdens de Sprint concentreerden ze zich alleen op de taken waaraan ze zich gecommitteerd hadden. De taken waarvoor zij zich verantwoordelijk voelden. Ze hadden de verantwoordelijkheid van hun team moeten overwegen om het vastgelegde Sprint doel te bereiken, maar hun focus lag op het werk dat ze zelf deden.
Geen gevolgen
Op dat moment wist ik dat er iets interessants aan de hand was: een of meer teamleden voltooiden hun taken niet. En bovendien vindt niemand het nodig om zich daar zorgen over te maken!
Waarom zou je niet ontevreden zijn als je niet afmaakt wat je beloofd hebt? Welnu, het werk dat ze niet hadden afgemaakt, zou toch niet live gaan, of ze hun taken nu hadden voltooid of niet.
Het bedrijf waar dit team voor werkt, had een vaste release-cyclus. Het werk dat het team deze sprint deed, was voor de release over 4 weken. Het maakte dus niet uit of ze afmaakten wat ze hadden beloofd of het werk naar de volgende sprint opschoven.
De teamleden werkten niet in het schema van sprints van 2 weken, maar in release-cycli van 6 weken. De Sprints waren slechts een kwestie van overhead waar ze moesten dealen omdat het bedrijf dit nodig vond.
Voordat je dit team verkeerd beoordeelt: ze hebben altijd elke release de afgelopen twee jaar gehaald!
Mijn overwegingen
Ik begrijp volledig de manier waarop dit team denkt. Hun release-cyclus is zes weken, dus ze plannen voor zes weken. En eerlijk is eerlijk: ze leveren uitstekend werk als het gaat om kwaliteit en levering binnen die release-cyclus.
Het is iets moeilijker te accepteren dat ze een toezegging doen en zich er niet druk over maken als ze deze niet nakomen. Ja, ze doen geweldig werk met betrekking tot de release-cycli, maar iemands woord is ook van waarde. Dus alsjeblieft, als ik je Scrum Master ben en je moet werken in sprints van twee weken binnen een release-cyclus van zes weken, wees dan eerlijk over wat je aan het doen bent!
Als je naar dit verhaal kijkt, zul je misschien een aantal problemen tegenkomen die dit team heeft:
Problemen met openheid: het team moet opener zijn over hun manier van werken. Ze doen alsof ze een uitstekende sprint planning hebben en dat alles in orde is. Ze hebben zich echter nooit gecommitteerd aan de planning, alleen voor het deel waar ze zelf aan gaan werken, zonder daar open over te zijn. Dit geeft valse verwachtingen.
Problemen met de bereidheid om te groeien: ze accepteren de status quo en zien hun manier van werken als het antwoord op het voltooien van taken. Ze hebben nooit nagedacht over andere manieren van organiseren en samenwerken. Ze moeten nog proberen oplossingen te vinden zodat ze hun Sprints goed kunnen plannen.
Problemen met specialisten: een groep ontwikkelaars die individueel aan hun specialiteit werken, is slechts een groep individuen in dezelfde ruimte. Ze zijn helemaal geen team. Als ik naar het team kijk, zie ik veel overeenkomsten om vanuit te werken, maar dat hebben ze nooit gedaan, want dat maakt ze bang!
Problemen met het verantwoordelijkheidsgevoel: het team voelde zich niet verdrietig of teleurgesteld als ze het sprint doel niet haalden. Zelfs het teamlid dat als enige zijn werk niet gedaan kreeg, had daar negatieve gevoelens over. Dit is slechts gedeeltelijk het resultaat van de release-cyclus van zes weken. Het andere, veel belangrijkere, deel is een gebrek aan verantwoordelijkheidsgevoel van dat teamlid.
Problemen met de omgeving: als je het verhaal van dit team leest, vraag je je misschien af waarom ze in sprints van twee weken werken. Wat is het voordeel voor dit team? En eigenlijk weet ik het ook niet. De organisatie waar dit team voor werkt had besloten om voor alle teams een sprint cadans van 2 weken te organiseren, zonder te vragen of dit voor de teams zelf zou werken.
Dus ben jij een Scrum Master of andere Agile specialist en zie je één of meerdere van de beschreven vraagstukken bij jou op de werkvloer, durf ze dan uit te challangen. Ze zijn geëvolueerd naar een systeem dat we cultuur noemen. Het meest opwindende deel van het leven in de Agile-wereld is het uitdagen van die systemen en hen leren Agile-culturen te worden.