Christiaan Verwijs
Christiaan Verwijs Agile Coach / Scrum Master
| 0 reactie(s)

Zombie Scrum

Zombie-Scrum

De opkomst van Zombie Scrum

Je kent ze wel; zombies. Ze spelen een hoofdrol in menig serie of film zoals ‘The Walking Dead’ en ‘World War Z’. Om dat soort zombies kunnen we vaak nog wel een beetje lachen. Ze zijn ver weg, en bovendien fictief. Maar als je met Scrum werkt hoef je vaak niet ver te zoeken om zombies tegen te komen. We hebben het over hordes ontwikkelaars, testers en designers die kreunend en steunend door eindeloze kantoorgangen stommelen op weg naar de volgende hersenloze Scrum-activiteit. Zombie Scrum!

In deze post lees je meer over Zombie Scrum, hoe je het kunt herkennen en wat je er aan kunt doen. Laten we eens beginnen met de symptomen. Deze post is eerst in het engels verschenen, geschreven door mijzelf en Johannes Schartau [link: https://twitter.com/integralagile].

Symptomen van Zombie Scrum

Symptoom #1: Geen kloppend hart

Het probleem met zombies is dat ze er van een afstand – bijvoorbeeld in die donkere steeg – menselijk uit zien. Maar als je dichterbij komt merk je dat ze niet werkelijk leven. Bij Zombie Scrum geldt hetzelfde; van een afstand lijkt het op Scrum. Maar als je dichterbij komt merk je dat er geen kloppend hart is.

Het kloppend hart van Scrum produceert werkende, waardevolle en voltooide functionaliteit in het ritme van de sprints. De resultaten worden na elke sprint geïnspecteerd door het team en alle relevante stakeholders. Gezonde Scrum Teams begrijpen dat deze regelmatige oplevering van werkende software essentieel is, omdat het de beste manier is om aannames te toetsen over tijd, technologie, gebruikerservaringen en wat überhaupt nodig is. Zombie Scrum Teams pakken dit anders aan. Zij doorlopen weliswaar alle Scrum rituelen, en hebben sprints, maar leveren zelden werkende software op. Voltooide software is voor hen een ‘nice-to-have’, maar iets wat ook best een volgende sprint kan.

Het ontbreken van een kloppend hart is het meest zichtbaar tijdens de sprint review. Teamleden pakken zelden het toetsenbord en de muis om door een werkende applicatie te klikken, en te laten zien wat ze hebben gebouwd. In plaats daarvan laten teams PowerPoints, screenshots of release notes zien. Of ze pakken simpelweg de Sprint Backlog en bespreken wat er gedaan is. Als functionaliteit al gedemonstreerd wordt, dan is dat erg technisch (‘we hebben class X ge-refactored zodat we dependency injection kunnen doen’) of onder voorbehoud (‘we moeten dit nog afmaken’ of ‘oops, dit werkt toch nog niet’). Een meer subtiele indicator is een gebrek aan discussie tijdens de Sprint Review. Er worden geen meningen uitgewisseld, geen kritiek of feedback gegeven of ideeën geopperd. Stakeholders – zoals key users of andere belanghebbenden – zijn zelden of nooit aanwezig. En de Product Owner vindt eigenlijk alles wel best. In plaats van het kritisch inspecteren van werkende software, bestaat de Sprint Review vooral uit het afvinken van wat gedaan is. Saai, hersenloos en zonder een kloppend hart. En niemand lijkt er mee te zitten.

Het ontbreken van een kloppend hart is ook zichtbaar in een vage en onambitieuze ‘definition of done’. Gezonde Scrum Teams begrijpen dat hoe meer ‘klaar’ functionaliteit is – hoe meer het door echte mensen wordt gebruikt, met echte data werkt en op een productie-omgeving draait – hoe beter de feedback is. Deze teams begrijpen dat een constante stroom van voltooide software geen nice-to-have is, maar de essentie van Scrum.

In Zombie Scrum gaat dit anders. De ‘definition of done’ van deze teams beschrijft niet zozeer wanneer functionaliteit werkelijk klaar is, maar wanneer het ‘technisch klaar’ is (o.a. ‘Gecommit naar versiebeheer’ of ‘developer heeft er 1 keer doorheen geklikt’). De reden waarom we met Scrum werken komt hier dus niet tot uitdrukking. En waarom zou je de teams hier de schuld van geven? Deze technische focus is vaak het gevolg van de functionele silo’s die in de organisatie bestaan. Het testen wordt gedaan door een Q&A-team, deployments worden gedaan door Operations en het afhandelen van feedback van gebruikers en het schrijven van documentatie is een taak van Support. Door deze traditionele silo’s intact te laten, verstrijkt er veel tijd, en zitten er veel schakels tussen hetgeen een Scrum Team oplevert en wanneer het werkelijk in gebruik genomen wordt. Daardoor leert het team heel weinig, en heel laat, over wat de gevolgen zijn van wat zij hebben gemaakt. En niemand lijkt hier mee te zitten.

Symptoom #2: Geen behoefte aan contact met de buitenwereld

In tegenstelling tot de zombies uit films, die mensen aanvallen en opeten, hebben Scrum Zombies weinig op met buitenstaanders. Ze blijven liever in hun vertrouwde omgeving, en hebben geen interesse in wat er voorafgaat aan wat ze ontwikkelen, en welke gevolgen het heeft. Voldoet het product niet aan de wensen van de klant? Ik ben hier alleen maar om te programmeren! Hebben gebruikers last van ‘memory leaks’ waardoor de app vastloopt? Dan had Q&A meer en beter moeten testen. Wil een stakeholder zo’n lelijke ‘flash intro’ en knipperende rode tekst op de homepage? Geen probleem; ik ben immers geen ontwerper. Zombie Scrum Teams zien zichzelf enkel als een klein radertje in het systeem. Niet in staat, en niet van wil, om hier iets aan te veranderen.

Uiteindelijk is dit ouderwets silo-denken, en gaat het lijnrecht in tegen het idee van cross-functionele teams die over alle benodigde competenties beschikken om werkende software op te leveren. Zombie Scrum Teams willen echter afhankelijk zijn van derden, zodat ze geen verantwoordelijkheid hoeven te nemen. De gedachte om betrokken te worden bij het ontwerp en de validatie van de software is een schrikbeeld.

Symptoom #3: Geen emotionele reactie op succes of mislukking

Net als het levenloze lichaam van een zombie, vertonen Zombie Scrum Teams geen reactie op mislukking of succes. Waar gezonde Scrum Teams successen vieren en flink balen van mislukte sprints, blijven Zombie Scrum Teams emotieloos in de verte staren. Het moraal van het team is laag. En items van de Sprint Backlog worden zeer regelmatig meegenomen naar de volgende sprint. Want waarom ook niet? Er is ‘immers altijd een volgende sprint’, en ‘de sprints zijn toch kunstmatig’. En omdat items van de Sprint Backlog niet gekoppeld zijn een duidelijk sprintdoel, kunnen items van de Sprint Backlog op elk moment opgepakt en losgelaten worden. En zo stommelt en rommelt het Zombie Scrum op slakkentempo door. Zonder richting, zonder afstemming en zonder richtingaanwijzers.

Symptoom #4: Geen wens om te verbeteren

In ‘The Walking Dead’ zijn zombies het toppunt van zielloosheid. Voortschuifelend omdat ze dat altijd al deden. Deze levenloze processie wordt vergezeld door geklapper van tanden en gezucht en gesteun. Alhoewel het bij Zombie Scrum wat minder dramatisch is, blijven ook deze teams in beweging terwijl er geen kloppend hart is. Want er zijn sprints (alhoewel de resultaten beperkt zijn), en de Scrum ceremonies vinden plaats. Maar er is geen plezier, geen levendige discussie, en zeker geen wens om dit te verbeteren. En niemand lijkt er mee te zitten.

En kun je het team dit kwalijk nemen? De Product Owner is zelden aanwezig bij de Sprint Review of bij de Sprint Planning (want te druk!). Teams zijn niet stabiel omdat teamleden steeds worden uitgeleend aan andere teams, die hun gespecialiseerde competenties nodig hebben. En van een Scrum Master is geen sprake. Sommige bottlenecks kunnen echt zijn, terwijl anderen meer tussen de oren zitten. Maar de kern is dat het team geen controle ervaart over het eigen succes. En dit resulteert in saaie retrospectives, waarbij elke keer dezelfde oppervlakkige problemen naar voren komen, en vooral een hoop geklaag. Maar niemand lijkt van wil om daar wat aan te veranderen.

Oorzaken

Scrum is populair, dat is wel duidelijk. Maar het groeiende aantal Scrum Teams zorgt ook voor een toename van het aantal Zombie Scrum Teams. En alhoewel ze niet meteen een hap uit je arm nemen, de tanden zetten in de stagiair of kauwen op de Scrum Master, willen wij niks liever dan je helpen om deze teams te laten ervaren hoe Scrum werkelijk werkt. Maar voordat we naar een behandelplan kunnen, moeten we eerst meer weten over de oorzaken.

Oorzaak #1:

Teams en organisaties starten regelmatig met Scrum zonder hulp van externe trainers of coaches (‘Homegrown Scrum’). Daar is niks mis mee. Sterker nog; veel van de beste Scrum Teams zijn op deze manier gestart.

Maar dit pakt niet altijd goed uit. Zoals dat team dat besloot dat ze met Scrum werkten omdat ze een twee-wekelijkse Daily Scrum hadden, of dat team dat de lengte van de sprint varieerde om het werk af te krijgen. En wat denk je van de organisatie die Scrum implementeerde door functietitels te hernoemen – van projectmanagers naar ‘Scrum Masters’ en van product managers naar ‘Product Owners’ – maar daarbij de essentie miste dat ‘Product Owners’ klanten en eindgebruikers moeten vertegenwoordigen, en dat Scrum Masters geen teams moeten managen.

Dergelijke halfbakken implementaties van Scrum zijn vaak niet met opzet. Wellicht heeft iemand wat gelezen over Scrum, en alleen geïmplementeerd wat hij of zij begreep. Of misschien zijn alleen die delen overgenomen die weinig verandering vereisen in de organisatie (zoals een Daily Scrum). Maar door slechts delen van Scrum te implementeren, verlies je de voordelen, en zullen teams blijven worstelen. Het is alsof je wil afvallen voor het bikiniseizoen door al je eetgewoonten te laten voor wat ze zijn, maar een salade per week toe te voegen aan je dieet.

Kortom; Scrum vereist verregaande veranderingen in een organisatie. Niet allemaal tegelijk, maar het besef moet er wel vanaf het begin zijn. Doe je dit niet, en blijft het bij oppervlakkige veranderingen, dan is de kans op Zombie Scrum enorm.

Oorzaak #2: Geen urgentie

Zombie Scrum Teams ervaren vaak geen urgentie, meestal omdat ook de organisatie als geheel geen urgentie kent. Op haar beurt komt dit vaak weer door een gebrekkig begrip van ‘waarde’, en wat ‘waardevolle software’ is. Als werkende software het kloppende hart is van Scrum, dan is waarde het levensbloed.

‘Waarde’ gaat niet over een CEO die op een kruk gaat staan en even lekker gaat spuien. ‘Waarde’ gaat over transparantie over wat belangrijk is, en waarom. Maar hoe weten we wat belangrijk is? En hoe verspreiden we die kennis? Gebruiken we abstracte meetinstrumenten, zoals ‘value points’, of meer specifieke hulpmiddelen, zoals ‘Cost of Delay’? Gezonde Scrum Teams weten dat het loont om tijd te investeren in het ordenen en slim prioriteren van de Product Backlog. Minder goede Scrum Teams doen dit zelden, en hebben (daarom) vaak moeite om duidelijke sprintdoelen te formuleren. Er is immers geen goed begrip van wat waardevol is. De sprintdoelen die er zijn hangen zelden samen met een overkoepelende roadmap of productstrategie, en er is geen duidelijke samenhang met wat belangrijk is voor de organisatie. Zonder duidelijke doelen, is er ook geen reden voor urgentie. En hier liggen de wortels van Zombie Scrum; gedeelde doelen vormen immers de lijm die een team bij elkaar houdt, en hen bestaansrecht geeft.

Het gebrek aan urgentie is ook zichtbaar in een onbereidheid om te veranderen hoe ‘we de dingen hier doen’. Bij Zombie Scrum wordt Scrum gezien als een proces voor ‘software development’, waardoor het alleen de ‘IT afdeling’ raakt. Maar gezonde Scrum stelt zijn doelen veel hoger, en probeert klanten en eindgebruikers diep het ontwikkelproces in te trekken. Dit raakt noodzakelijkerwijs alle delen van de organisatie, van verkoop tot ‘Operations’, en van marketing tot support. Dit is immers de beste manier om waardevolle software te maken voor eindgebruikers en klanten.

Oorzaak #3: Botsende waarden

Tussen de regels door heb je de derde oorzaak wellicht al kunnen ontdekken. Want Zombie Scrum is uiteindelijk het resultaat van een diepe systemische mismatch met de waarden van ‘Agile software development’ en Scrum. Het is moeilijk om Scrum op een goede manier toe te passen in een organisatie waar mensen overtuigingen hebben die haaks staan op wat we met Scrum willen bereiken. Je kunt het de teams zelf vaak niet kwalijk nemen. Want deze overtuigingen zitten vaak diep, zijn meestal onbewust en onderdeel van de cultuur van een organisatie. Je vindt hier een tabel met concrete voorbeelden van dergelijke botsingen.

Behandeling

Stel je hebt te maken met een besmetting van Zombie Scrum. Wat doe je daartegen? Hieronder volgen een aantal mogelijkheden:

Behandeling #1: Praten met Zombies

Je verwacht het niet, maar een goed gesprek met Scrum Zombies doet wonderen. Zombie Scrum Teams zijn zelden blij met hoe de vlag er bij hangt. Een goed begin is dus om de situatie bespreekbaar te maken en mogelijke oorzaken en oplossingen te identificeren. Een leuke manier om dit te doen is om het om te draaien; ‘Wat kunnen we doen om nog meer als zombies te werken?’. Het is ook een goed idee om waardes en overtuigingen boven tafel te krijgen, en (wanneer nodig) mensen uit te leggen waarom we met Scrum werken. Een game als ‘Circles & Soup’ komt hier van pas omdat het de focus legt op zaken die het team kan veranderen (in plaats van wat ze niet kunnen veranderen), en zo een team helpt om weer grip te krijgen op de situatie.

We benadrukken hier nogmaals dat Zombie Scrum geen probleem van het team is. Zombie Scrum is een manifestatie van een diepe mismatch tussen de waarden van Scrum aan de ene kant, en die van de organisatie aan de andere kant. Alhoewel het belangrijk is om met de teams in gesprek te gaan over oplossingen, zullen zij waarschijnlijk niet op eigen kracht genezen van Zombie Scrum. Bredere, team-overstijgende interventies zullen nodig zijn. Het helpt vaak om vertegenwoordigers van alle teams en het management regelmatig bij elkaar te laten komen om te zoeken naar oplossingen van problemen die de teams zelf niet kunnen oplossen. De rol van het management kan hierbij niet genoeg worden benadrukt; zij moeten het proces steunen en de kernwaarden van Scrum uitdragen in wat ze doen.

Behandeling #2: Introduceer gezonde Scrum in de populatie

Een andere manier om Zombie Scrum te bestrijden, is door mensen in te schakelen die laten zien hoe gezonde Scrum werkt. Organisaties die met Zombie Scrum kampen, merken vaak zelf ook wel dat het niet lekker loopt, maar weten vaak niet wat de oorzaak is. Een frisse blik helpt dan. Je kunt teams bijvoorbeeld meenemen naar organisaties waar effectief met Scrum gewerkt wordt (een Scrum Safari), of je kunt mensen aannemen die veel ervaring hebben met Scrum. Je kunt ook een Agile coach inschakelen die teams en het management helpt om Scrum beter te begrijpen en toe te passen, zolang het doel blijft om de organisatie zo snel mogelijk weer op eigen benen te laten staan.

Behandeling #3: Schud de zaken op

We hebben bij Zombie Scrum te maken met een hardnekkig virus. Zombie Scrum Teams zijn vaak vastgelopen, en hebben iemand nodig die ze de richting wijst. Het heeft dus niet zoveel zin om in dit soort gevallen alleen te coachen; pak de leiding een tijdje op, en help de teams meer gericht door de sprints heen. Maar geef de controle zo snel mogelijk weer terug aan het team, als de symptomen verdwijnen.

Veel interventies zullen gericht zijn op het doorbreken van de monotonie die kenmerkend is voor Zombie Scrum. Je kunt een hoop opschudden door te veranderen hoe een team met Scrum werkt:

  • Zombie Scrum Teams profiteren vaak van een kortere sprint. Geen drie of vier weken, maar twee;
  • Gebruik de Sprint Planning om het team te laten formuleren welke impact ze de komende sprint willen maken; wat willen ze bereiken?
  • Begin elke Daily Scrum door het sprintdoel te herhalen, en laat elk teamlid vertellen wat ze gedaan hebben om dat doel te bereiken;
  • Gebruik de roadmap om context te geven aan de Sprint Review. En nodig alsjeblieft echte klanten en eindgebruikers uit!
  • Gebruik de Retrospective niet om steeds dezelfde problemen te bespreken. Help het team eerst om groot te denken, even los van de huidige problemen. Hoe zouden ze werken als ze een geweldig Scrum Team zijn? En wat is daarvoor nodig?

Behandeling #4: Betrek de bredere Scrum gemeenschap

Je bent gelukkig niet alleen in je strijd tegen Zombie Scrum! Maak gebruik van de groeiende gemeenschap. Bezoek lokale Agile of Scrum meetups, maak gebruik van forums (zoals die van Scrum.org) of Facebook en vraag om hulp en advies. Of stuur een mailtje naar iemand die bezig is als Agile Coach of Scrum Master. Mensen helpen je graag.

Maar dit werkt beide kanten op. Wij zijn er namelijk van overtuigd dat de verantwoordelijkheid voor het groeiend aantal Zombie Scrum Teams ook bij de gemeenschap zelf ligt. Door de recente focus op het schalen van Scrum, het toepassen van Scrum in enterprise omgevingen, gecombineerd met een groeiend aantal partijen met commerciele belangen in de verkoop van trainingen, frameworks en certificeringen, ligt naar ons gevoel steeds minder nadruk op het kloppende hart van Scrum en Agile. De kernvraag moet niet zijn ‘Hoe schalen we Scrum naar 20 teams?’ of ‘Hoe kunnen we in onze organisatie zo snel mogelijk Scrum implementeren?’. In plaats daarvan zou de focus moeten liggen op ‘Hoe kunnen we elke sprint meer werkende software opleveren?’. Als het hart van Scrum niet gaat kloppen op het niveau van individuele teams, dan blijft al het andere een levenloze schil. Zombie Scrum in optima forma.

Zombie-Scrum---Johannes-en-Christiaan

 

Meer weten over hoe je een geweldig Scrum Team opbouwt, loop je vast, of heb je hulp nodig? Voor meer informatie kun je terecht op http://www.agilistic.nl

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Meer weten over onze werkwijze en dienstverlening? Neem gerust contact met ons op!