Follow Us on Twitter

"We hebben Scrum geprobeerd, maar het werkte niet"

Gepubliceerd in

Januari 2015 – In de tegenwoordige tijd komt hij ook voor, "We proberen Scrum, maar het werkt niet". Nu zijn er natuurlijk vele legitieme redenen waarom Scrum niet altijd de beste aanpak is, maar het gebeurt maar al te vaak dat belangrijke principes van Scrum over het hoofd gezien zijn of worden. Dat is zonde, want Scrum kan een heel effectieve aanpak zijn.

In dit Whitebook vind je een aantal vragen waarmee je kunt beoordelen of je de belangrijkste onderdelen van Scrum op een goede manier uitgewerkt hebt in je proces, of dat er nog punten zijn waar aan gewerkt moet worden.

Is er een Product Backlog?

Natuurlijk is er een Product Backlog. Dat zegt iedereen tenminste.

Maar is die Backlog ook gerangschikt op prioriteit? Alleen dan blijft de focus van het team bij de belangrijkste items.

Zijn de bovenste items wel klaar ("Ready") om in een Sprint opgenomen te worden? Als dat niet zo is (te groot, te weinig uitgewerkt, niet ingeschat) dan zal de verdere ontwikkeling stagneren. Als daarentegen teveel items Ready zijn, dan begint je proces onbedoeld meer op een waterval te lijken. Zoek de balans zodat er precies voldoende Ready is (meestal werkvoorraad voor enkele Sprints).

Ook kan het helpen om een "Definition of Ready" te maken, een gezamenlijke afspraak tussen Product Owner en het team waaraan items op de Backlog moeten voldoen alvorens ze in de Sprint opgenomen kunnen worden.

Regelmatig Backlog onderhoud ("Backlog refinement") zorgt ervoor dat je Backlog in vorm is en blijft. Alleen dan bewijst de Backlog zijn nut.

Is er een Product Owner?

Het lijkt zo logisch, bij elk team hoort een Product Owner (PO). Toch?

Heeft die PO wel het mandaat om te bepalen waar het team aan werkt? Korte lijnen en voldoende slagkracht zijn nodig om kortcyclisch te kunnen werken.

Is de PO in staat om de Backlog te prioriteren? Hij moet ten eerste weten wat elk item op de Backlog betekent om de juiste keuzes te kunnen maken en ten tweede moet hij het doen. Met name dat laatste wordt nog wel eens vergeten – het is erg verleidelijk om te denken "alles moet toch, dus waarom zou ik prioriteren".

Is de PO voldoende beschikbaar voor contacten met het team en zijn stakeholders? Een team met een PO die alles weet, maar er niet vaak genoeg is om de broodnodige sturing te geven binnen de Sprint, verliest kostbare tijd aan extra rework. Evenzo voor een PO die er genoeg is, maar onvoldoende op de hoogte is van de eisen en wensen van zijn stakeholders.

Mocht er sprake zijn van meerdere PO’s, hebben die dan wel een eenduidige stem? PO’s die onafhankelijk van elkaar verschillende prioriteiten stellen, komen zelden tot een coherent eindresultaat.

Wordt er voor elke Sprint een planningssessie gehouden?

Ja, elke Sprint begint met een planningssessie. Of niet?

Is bij die sessie het gehele team en de PO aanwezig? Het team kan nog vragen stellen, de PO kan Ready Backlog items toelichten, zodat het team de definitieve inschatting kan maken. Daarna kan de PO nog prioriteiten bijstellen. Dit samenspel is essentieel om de juiste balans tussen de business value van een Sprint af te wegen tegen de kosten van een Sprint.

Kan het team zich na de sessie committeren aan de inhoud van de Sprint? Zo niet, hoe komt dat dan? Zijn Backlog items nog niet ready? Of heeft 1 iemand (van binnen, of, nog erger, buiten het team) besloten dat "deze hoeveelheid werk wel gaat passen"? Een Sprint Backlog waar het team na de planning al niet achter staat, zal op zijn zachtst gezegd niet bepaald motiverend werken.

Hebben de Sprints een vaste lengte?

Duren Sprints altijd tussen de 1 en de 4 weken? Een Sprint is een timebox. Als de timebox op is, is de Sprint afgelopen. Dat zorgt voor een ijzeren discipline. Als Sprints verschillende lengtes hebben, worden er steeds verschillende hoeveelheden functionaliteit opgeleverd. Het wordt daardoor moeilijker om te voorspellen hoe lang het nog zal duren om de rest van de Backlog te realiseren. Door de verminderde voorspelbaarheid neemt het vertrouwen in de kundigheid van het team af.

Zijn er geen verstoringen van buitenaf? Het is voor de PO of iemand anders uit de business gemakkelijk om het team om een gunst te vragen en het is voor het team vaak moeilijk om dat te weigeren. Elke keer als dat gebeurt, is dat een risico voor de Sprint. Ook in dat geval fluctueert de hoeveelheid opgeleverde functionaliteit, waardoor de voorspelbaarheid vermindert.

Is er een Sprint Backlog?

Natuurlijk is er een Sprint Backlog. Maar is die zichtbaar? Een slecht zichtbare Sprint Backlog geeft geen transparantie. Teamleden weten minder van elkaar waar ze mee bezig zijn of wellicht hulp bij nodig hebben. De PO heeft geen inzicht in het verloop van de Sprint.

Is de Sprint Backlog bijgewerkt? Als extra taken niet in de Sprint Backlog opgenomen worden, dan geeft dit ten onrechte een positief beeld van het verloop van de Sprint. Aan de andere kant, als reeds uitgevoerde taken niet afgevoerd worden, is het onduidelijk dat veel functionaliteit reeds gereed is.

Is er een Daily Scrum?

En zijn die dan ook met het hele team? Iedereen vertelt dan waar hij mee bezig is en anderen luisteren daar naar? Zo nee, dan kan het zomaar gebeuren dat een teamlid verzuipt in een bepaald Backlog item, maar dat de rest van het team daar weinig zicht op heeft. De Daily Scrum verwordt dan tot een ritueel om Post-its te verhangen.

Worden er problemen en obstakels onderkend? Springen teamleden in dat geval bij elkaar bij? Als dat nooit gebeurt, is het team dan wel een team? Of is het een groep individuen die allemaal hun eigen taken af proberen te ronden. Of, is elk teamlid zo gespecialiseerd dat het onmogelijk is om bij elkaar bij te springen? Problemen en obstakels tackelen wordt dan lastig, zo niet onmogelijk.

De essentie van Scrum is samenwerken om 1 functionaliteit binnen beperkte tijd productierijp te maken. De Daily Scrum helpt daarbij om het team "op dezelfde pagina" te houden.

Wordt er gewerkt met een Definition of Done?

Als de Definition of Done ontbreekt, dan is het onduidelijk wat de staat van je product is aan het einde van de Sprint. In hoeverre is het "shippable"? Hoeveel (test)werk hebben we nog te gaan? Het wordt makkelijk om een eigen, ad hoc, definitie van "Done" te hanteren, zeker als je nog een flink aantal Backlog items in deze Sprint weg moet werken. De kwaliteit holt achteruit en het vertrouwen in het team ook.

Is de Definition of Done haalbaar? Regels in de DoD opnemen die niet binnen de "span of control" van het team liggen, gaan tot frustratie leiden. De waarde van de DoD brokkelt af.

Neem zoveel mogelijk niet-functionele eisen op de DoD, zodat deze "Done" zijn bij het afronden van een individueel Backlog item en niet blijven tot het einde (of een volgende!) Sprint.

Wordt elke Sprint afgesloten met een demo?

Meestal wel. Maar voor wie is die demo? Een ontbrekende PO kan echt niet. Dan mis je waardevolle feedback en kansen om je Backlog bij te stellen. De boodschap is duidelijk: het is niet zo belangrijk om te zien wat het team gemaakt heeft. De moraal stort in, met alle negatieve consequenties van dien.

Is het werkende, geteste software? Het is verleidelijk om wat extra’s te demonstreren die "nog niet helemaal af zijn". De PO krijgt ten onrechte de indruk dat aan die features geen werk meer is, terwijl het werk in de achtergrond zich opstapelt (Technical Debt).

Komt er ook feedback na de demo? Niets zo vervelend als een demo waar niemand van de aanwezigen een constructieve opmerking maakt. Waardevolle feedback gaat verloren, en daarmee kansen om de Product Backlog verder te verbeteren.

Is er na elke Sprint een Retrospective?

De meeste teams zullen hier "ja" op antwoorden.

Maar worden er ook verbetervoorstellen gedaan in de Retrospective? Het is makkelijk om te blijven hangen in het opsommen van wat er goed ging en wat verbetering behoeft. Dat is niet verkeerd, maar het is slechts de eerste stap naar leren en verbeteren.

Worden verbeteringen ook doorgevoerd? Het zou zomaar kunnen dat hetzelfde verbetervoorstel in een volgende retrospective weer de revue passeert. Maak verbeteringen actionable, wijs ze aan iemand toe, maak daar ook tijd voor vrij en bespreek volgende keer of de verbetering gewerkt heeft.

Alleen dan zorg je dat een retrospective een zinvol moment is waar leren en verbeteren centraal staat.

Gebruik je ondersteunende tooling?

Documenteren, testen, deployen. Meer documenteren, testen, deployen. Nog meer documenteren, testen, deployen.

In een kortcyclisch ontwikkelproces zijn dat handelingen die zeer vaak uitgevoerd moeten worden. Als deze handelingen onvoldoende met tooling ondersteund worden, kosten ze relatief veel tijd. Daardoor komen deze activiteiten onder druk te staan, waardoor de discipline en de kwaliteit afneemt en het team niet meer in staat is om binnen de Sprint een goed product af te leveren.

Tot slot

Scrum kan heel effectief zijn, maar om daar te komen is niet gemakkelijk. Je hebt discipline nodig om je afspraken na te komen, en moed om transparant te zijn over zaken die je nog niet volledig onder de knie hebt. Daarnaast stelt je omgeving organisatorische en technologische randvoorwaarden die mogelijk ook veel impact op je effectiviteit hebben. Deze checklist geeft je snel inzicht in de belangrijkste zaken die je op orde moet hebben.

Als je een aantal vragen met "nee" beantwoord hebt, kijk dan nog eens welke voordelen van Scrum je daardoor mist. Gooi het eens op tafel bij je eerstvolgende retrospective. Misschien komt eruit dat je het op een andere manier tóch geregeld hebt. Of misschien komt er een verbetering uit voor de komende Sprint. Eén ding is zeker: je proces is er weer een stukje scherper door geworden.

Referenties

  • Scrum Checklist
  • An Example Checklist for ScrumMasters
  • The Definition of READY
  • Hoe verbeter je Scrum Backlog Grooming
  • Waardering:
     

    Reacties

    Nieuwe reactie inzenden

    De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

    Meer informatie over formaatmogelijkheden

    CAPTCHA
    Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
    Image CAPTCHA
    Enter the characters shown in the image.