Is tussentijds een sprint stoppen gelijk aan een hartstilstand?

In Intermediate, Scrum by PeterLeave a Comment

Leestijd: 6 min.

Tussentijds stoppen met een sprint? De mogelijke oorzaken, wie er beslist, welke opties er zijn, waarom de Scrum Values er toe doen. Hoe je zou kunnen handelen? Hoe ga je als team om met deze ervaring?

Hartstilstand bij Scrum?

Laten we eerst nog even teruggrijpen wat een Sprint feitelijk is. Het is het kloppende hart van Scrum. Een periode van een maand of korter waarbinnen een ‘done’ bruikbaar en mogelijk op te leveren product increment wordt gecreëerd.

Elk Scrum Team behoort te weten dat er een kans is op een abnormale tussentijdse beëindiging van de sprint. Dat is echter niet een gemakkelijke beslissing, want wij worden zelf liever ook niet geconfronteerd met hartproblemen of met een hartstilstand. En dat is precies wat er gebeurt bij een vroegtijdige beëindiging van de sprint: het kloppende hart van Scrum wordt stil gelegd.

Wat behoor je te doen als besloten wordt om de sprint te stoppen? Je stopt een sprint en start direct een nieuwe sprint. Dat is en lijkt logisch, maar als het hart stopt met kloppen? Dan start je niet lekker enthousiast en gemakkelijk op in een nieuwe sprint. Dan kan je geconfronteerd worden met een (pijnlijk) herstelproces. Vaak zijn er voor en tijdens de komende sprints extra inspanningen noodzakelijk.

Wil je meer weten wat de mogelijke oorzaken zijn en wie de beslissing neemt? Lees dan verder.

Oorzaken

De meest voorkomende oorzaak van een sprint te stoppen is een grote wijziging in business prioriteiten.

Iets wat als belangrijk werd beschouwd is niet meer belangrijk, of iets anders is opeens veel belangrijker geworden. Een simpel voorbeeld hiervan is dat het team met een geweldig dataverrijking ontwerp al lekker onderweg is, maar nieuwe wetgeving dit ‘plotsklaps’ verbiedt.

Een andere mogelijke oorzaak is dat het team tijdens de sprint ontdekt dat het werk veel langer gaat duren dan van te voren in de sprint planning werd verwacht. Bijvoorbeeld de toepassing van een veelbelovende nieuwe technologie blijkt niet overeenkomstig de verwachtingen. Een ander voorbeeld is dat de bestaande code veel meer aangepast dient te worden dan verwacht. Of men constateert dat de inspanningen dermate kostbaar worden dat het de investering niet meer waard is.

Ruis in communicatie behoort ook vaak tot de veroorzaker van problemen. Onduidelijke of gebrekkige communicatie is bij groepsprocessen overigens vrij vaak een belangrijke oorzaak van (toekomstige) problemen.

Later in deze blog komen een aantal voorbeelden hoe dit geborgd had kunnen worden, maar eerst 4 meningen over wie de beslissing neemt.

Sprint stoppen? De 4 mogelijke beslissers!

Hoewel de Scrum Guide heel duidelijk is, kom ik regelmatig discussies over dit onderwerp tegen. Het is handig als je diverse standpunten kent en waarom dit wel of geen goede uitgangspunten zijn.

1: Product Owner

De Scrum Guide is daar heel duidelijk over: de Product Owner neemt de beslissing.

Weet ook dat in scrum examens dit het enige juiste antwoord is, want de Product Owner beslist. De regel is ‘stop if it makes no sense to continue”. Dat is duidelijk! Dit wordt zo gesteld, maar eigenlijk wordt niet zo vaak toegelicht waarom dit zo is en wat de mogelijke effecten zijn. Dat maak ik zo direct meer inzichtelijk. Ik durf te stellen dat de wijze waarop dit gebeurt meer doorslaggevend is voor samenwerking in de nabije toekomst, dan wie beslist. Waarover zo direct meer.

2: Scrum Master

De tweede mening is dat de Scrum Master de beslissing neemt! Want hij is toch de proceseigenaar, de coach aan de zijlijn of volgens sommigen zelfs scheidsrechter. Laten we eens bekijken waarom dit niet voor de hand liggend is.

Stel de Scrum Master heeft de bevoegdheid om een sprint tussentijds te beëindigen. Stel dat de Scrum Master een sprint tussentijds stopt, maar de Product Owner is het daar niet mee eens of weet het nog niet zeker. Toch neemt de Scrum Master de beslissing: de sprint stopt! Het eerste wat het team behoort te doen is een nieuwe sprint starten. De sprint planning meeting start met de vraag. Product Owner wat moeten we doen? Antwoord van de Product Owner: ‘We gaan gewoon door met wat jullie deden! Ik heb niet gezegd om te stoppen’.

Een Scrum Team heeft een Product Owner, omdat deze prioriteert o.b.v. het totaaloverzicht en in overleg met stakeholders en team de prioriteiten bespreekt en bepaald, waarna het Development Team items van de Product Backlog in de sprint backlog plaatst.

Kortom, een Product Owner heeft de positie om de beslissing van de scrum master te herroepen. Dus de Scrum Master kan deze beslissing niet nemen.

3: Development Team

De derde mening is dat het Development Team de beslissing neemt.

Eerder gebruikte ik het voorbeeld van nieuwe veelbelovende technologieën die nog niet toepasbaar bleken. Dat kan zo zijn, maar als dit argument gebruikt mag worden om een sprint tussentijds te laten beëindigen door een autonome beslissing van het Development Team dan bewegen wij ons op glad ijs.

Nieuwe ontwikkelingen zijn nu eenmaal uitdagend, want we ontwikkelen nu eenmaal, omdat wij nieuwe waarde voor de klant willen creëren. Een goed functionerend team meldt de Scrum Master tijdens de Daily Scrum dat er een impediment naar boven is gekomen. De Scrum Master overlegd met de Product Owner en samen met het team start men een discussie op om te blijven werken aan het ‘shared goal’, wellicht met wijzigingen.

Door de bevoegdheid om te beëindigen neer te leggen bij het Development Team krijgen zij een vrijbrief om op toegezegde afspraken terug te komen, zonder verder overleg. Een ongewenste situatie.

4: het management

De vierde stelling is dat het management de beslissing (adhoc) neemt. Ja, dat kan altijd gebeuren. Want en maar….

Het kan zo zijn dat er sprake is van grote afhankelijkheden, waardoor de beslissing ook op een hoger niveau komt te liggen. Bijvoorbeeld dat de impact dermate groot is dat de organisatie geconfronteerd met andere (ernstige) effecten op de bedrijfsvoering. Ook kunnen er afhankelijkheden zijn met andere teams bij bijvoorbeeld large scaled scrum. Daar kom ik later op terug in een ander blog.

Vaak zal het (top)management geraadpleegd worden als de belangen zeer groot zijn. Als het management daarop autonoom een beslissing neemt, is het een manier om agile denken en werken op achterstand te zetten. Het is overigens niet aannemelijk dat het tussentijds afbreken van een sprint plaatsvindt zonder gefundeerde reden.

Als het management beslist en daarmee ingrijpt in het proces brengt zij de positie van de Product Owner schade toe. Hoe dat zich verder uitwerkt in het teamproces valt te voorspellen. Je hebt als management een Product Owner aangewezen die i.o.m. het management op voorhand business prioriteiten heeft bepaald. Kortom, een niet wenselijke situatie.

Welke opties zijn er nog meer?

Tussentijdse beëindiging van een sprint is zeldzaam en dat hoort zo te blijven. De consequenties zijn mogelijk groot! Het is echt de laatste optie, voordat er een definitieve STOP-beslissing wordt genomen bekijk je vanzelfsprekend eerst nog andere opties.

Daarvoor val ik nog even terug op de theorie. Gedurende de sprint:

  • geen veranderingen die de ‘sprint goal’ in gevaar brengen,
  • kwaliteitsdoelen worden niet verminderd,
  • de scope mag verder worden toegelicht en heronderhandelt tussen de Product Owner en Development Team als men onderweg meer leert.

In de heronderhandeling ligt wellicht een oplossing en daar zijn een aantal mogelijkheden voor:

replannen

Men kan een sprint replannen, door issues te verwijderen en nieuwe opties op te nemen. Wellicht neem je er voortaan tijd voor op in volgende sprints. Laten we stellen dat een goed functionerend team behoort te komen met replanning, het creëren van mogelijkheden in een nieuw plan, waardoor een tussentijdse beëindiging alsnog kan worden voorkomen.

Faciliteren

De Product Owner en Scrum Master moeten alle faciliterende vaardigheden inzetten om samen met het team verder te gaan, voordat er tot tussentijdse beëindiging wordt besloten. Want het team verliest mogelijk het vertrouwen in de Product Owner als er op haar/zijn autonoom genomen ‘bevel’ gestopt wordt. Is hij of zij wel in staat om goed te prioriteren? Inspanningen gaan namelijk verloren en nieuwe inspanningen zijn nodig, zoals opnieuw plannen etc.

Sprint Stories nalopen

Wanneer het komt doordat het Development Team teveel onzekerheden heeft opgenomen in de sprint planning , kunnen teamleden bijvoorbeeld de Sprint Stories nog eens doorlopen om te bepalen waar aannames hebben plaatsgevonden die hebben geleid tot het probleem. Dit helpt om vertrouwen te herwinnen bij de Product Owner, waardoor gezamenlijk aan een oplossing wordt gewerkt.

Communicatie

Veel onduidelijkheden zijn terug te herleiden naar communicatie issues, vaak zijn het niet eens de harde technische aspecten, maar is er ruis in het communicatie proces geslopen. Is dit het geval? Wat kan er hieraan verbetert worden? Welke lessen kunnen we meenemen?

Er zijn vanzelfsprekend nog meer mogelijkheden. De juiste vraag die je dus moet stellen is:

Hebben wij echt alles gedaan om deze abnormale sprint beëindiging te voorkomen?

De oplossing is een goed gesprek!

Als wij als team een hartstilstand hebben gehad, wat gaan wij dan doen? Kies maar: Graven we een kuil? Gaan we oneindig reanimeren? Blijft het team voor altijd kwakkelen of gaan we verder? Vanzelfsprekend ga je door! Mijn advies is dat je voor versneld herstel terugvalt op de kernwaarden!

Want juist als het fout gaat blijken de Scrum Values extra waardevol: commitment, courage, focus, openness en respect. Blijf flexibiliteit, creativiteit en productiviteit koesteren. Focus je op de voordelen van zelforganisatie.

Vanzelfsprekend is het nodig om een inhoudelijke discussie op te starten, om elkaars argumenten te horen met als doelstelling om tot een consensus te komen. Het biedt namelijk ook nieuwe inzichten en kansen om meerwaarde te creëren. Fouten worden nu eenmaal gemaakt. Het is een kans om hiervan te leren en voor het team een extra uitdaging om met innovatieve oplossingen te komen bij forse tegenwind. Wellicht een pijnlijk proces, maar het maakt een team tegelijkertijd ook sterker als deze discussie in een open constructieve sfeer plaatsvindt.

Take away

Wie er beslist? Dat is eigenlijk een theoretische discussie. In vrijwel alle gevallen zullen Product Owner, Scrum Master en Development Team het met elkaar eens zijn dat in een specifieke en uitzonderlijke situatie deze beslissing genomen moet worden.

Als het team niet tot een consensus komt en niet met goede oplossingen komt, dan zal er een keuze moeten worden gemaakt door een beslisser met aangewezen autoriteit. En dat is formeel de Product Owner, maar als die gebruik moet maken van zijn/haar positie om deze beslissing (zonder draagkracht) door te voeren, dan is er helaas een grote kans dat het team verder gaat met een blijvende beschadiging.

 

 

 

Leave a Comment