In het boek Extreme Ownership hebben de schrijvers Jocko Willink en Leif Babin het over de “4 rules of combat”. Deze regels hanteerden ze tijdens hun uitzending als Navy SEAL naar Iraq. Hun SEAL team was daar onderdeel van taskforce Bruiser. De taskforce die betrokken was bij de tweede slag om Ramadi in 2006. De “4 rules of combat” zijn:
- Cover and move.
- Simple.
- Prioritize and execute.
- Decentralized Command.
Hoe kun je als Scrum Master deze regels binnen je Scrum Team toepassen?
1. Cover and move / Geef dekking en verplaats
In het boek wordt beschreven hoe 2 SEAL teams een missie uitvoeren. SEAL team 1 heeft als opdracht om dekking te geven vanaf een hoog gebouw terwijl SEAL team 2 de stad in trekt. Na het uitvoeren van de missie trekken beide teams zich terug naar de basis. SEAL team 2 komt daarbij onder vuur te liggen en haalt de basis net zonder gewonden. Eenmaal op de basis krijgen ze een uitbrander van de commandant omdat ze SEAL team 1 niet op hun plaats hebben gelaten zodat zij dekking konden geven bij het verlaten van de stad.
Het punt dat hierbij aangedragen wordt, is dat de mensen te veel focus op alleen hun eigen team hebben. Ze vergaten daarbij wat een ander team voor ze kan doen. Ook bij Scrum Teams kunnen we ons te veel focussen op ons eigen team. Focus is een van de Scrum waardes. Echter je kunt ook te veel focus hebben. Hierdoor kan het gebeuren dat je als team het wiel opnieuw uitvindt. Je maakt een service of een api die door een ander team al is ontwikkeld. Of je levert een feature op waardoor een ander team een aanpassing in hun software eerder moet doen omdat anders hun software omvalt. Kom je als team ergens niet uit, kijk dan verder in de organisatie wie je zou kunnen helpen en vraag daar om hulp. Maar overleg ook met elkaar waaraan je werkt. Dit kun je door de Product Owner laten oppakken, maar dit kan ook door een lid van het Ontwikkel Team gedaan worden. De Product Owners overleggen vaak op strategisch niveau terwijl leden van het Ontwikkel Team meer op operationeel niveau zaken bespreken. Ieder heeft een eigen niveau maar daarom is het een niet belangrijker dan het ander.
Ook Scrum Masters weten niet alles. Dus Scrum Masters, help elkaar, ga met elkaar in gesprek en vraag advies. Laat eens een andere Scrum Master een event bijwonen en vraag achteraf om feedback. Bespreek een casus met elkaar en kijk samen hoe je die casus op kan lossen. De dekking van andere Scrum Masters geeft je de mogelijkheid om verder te gaan met je team en als Scrum Master verder te groeien.
2. Simple / Simpel
De groepsleider van een nieuw team wilde voor het eerst van de basis af en kwam met een ingewikkeld en omvangrijk plan. Jocko gaf het advies om het simpel te houden. Vooral de eerste keer buiten de poort. De kans dat er heel snel contact met de vijand zou komen was groot. Na lang aandringen paste de groepsleider het plan aan en inderdaad kwam er al snel een aanval toen hij het kamp verlaten had. Omdat het plan simpel was, kon de groepsleider snel aanpassen en kon er vanuit de basis ondersteuning geboden worden. Ook de teamleden van de groepsleider begrepen het plan vanwege de simpliciteit en pasten zich tijdens de aanval aan. Hierdoor kon iedereen weer levend terugkeren naar de basis.
Hou het simpel. Denk aan user stories. Een grote complexe story kun je beter opknippen zodat je meerdere kleinere eenvoudige(re) stories hebt. In een blog van Christiaan Verwijs (10 powerful strategies for breaking down user stories in Scrum) worden verschillende manieren beschreven hoe je een story kunt opknippen. De blog is te vinden via https://medium.com/the-liberators/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb .
Door het opknippen van stories is het voor iedereen overzichtelijk wat er moet gebeuren. Ook heb je zo de ruimte om zaken aan te passen en op veranderingen in te spelen. Omdat iedereen snapt wat er moet gebeuren, kunnen alle teamleden input leveren. Aan de Scrum Master de schone taak om het team en de Product Owner te helpen bij het kleiner maken van de stories en uit te leggen wat de voordelen zijn van kleinere stories.
Hou het simpel geldt ook voor het sprintdoel. Dat moet duidelijk zijn voor iedereen in het Scrum Team. Het Ontwikkelteam kan zo goed inschatten wat er moet gebeuren om het sprintdoel te halen en kan bij de planning een goede voorspelling afgeven. Tijdens de sprint kan het Ontwikkelteam ook eenvoudiger toetsen of ze op de goede weg zijn om het sprintdoel te halen. Een eenvoudig sprintdoel geeft daarbij ruimte om de aanpak aan te passen om bij calamiteiten het doel alsnog te halen.
3. Prioritize and execute / Prioriteer en voer uit
Tijdens een missie kwam het SEAL team terecht op een dak midden in vijandig gebied. Een teamlid was naar beneden gevallen door een gat in het dak en lag een aantal meters lager. Vijanden zijn onderweg naar hun locatie. Een explosief staat op het punt van ontploffen. De enige manier om van het dak af te komen is afgesloten met een hek. Op dat moment houdt Leif Babin zich aan de zin “Relax, look around, make a call”. Blijf rustig, kijk om je heen, prioriteer en beslis wat er moet gebeuren.
Binnen je Scrum Team is het ook onverstandig om alles tegelijk te doen. Het is beter om 1 ding te doen en dat af te maken en dan pas aan het volgende te beginnen. Als je alles tegelijk doet, ben je veel langer bezig en de vraag is of je door het gebrek aan focus de gewenste kwaliteit haalt. Als je als Scrum Master merkt dat mensen met meerdere stories tegelijk bezig zijn, overleg dit dan. Waarom heeft iemand drie stories in de busy lane? Wat vindt het team hiervan? Zijn er misschien impediments die niet gemeld of opgevallen zijn? Prioriteer de redenen en los ze samen met het team op zodat de teamleden zich weer op 1 ding tegelijk kunnen richten.
Denk ook aan een spoedgeval. Een klant gebruikt jullie software voor een primair proces maar kan door een probleem met de software niet verder en het hele proces ligt nu stil. Wat doe je als team? Help je de klant waardoor je wellicht het sprintdoel niet haalt of hou je de focus op het sprintdoel waardoor de klant niet verder kan met het proces? Help het team bij prioriteren en het maken van een beslissing en faciliteer bij de uitvoering.
Uit de retro kan een hele waslijst met verbeterpunten komen. Als je als Scrum Master adviseert alle punten in de volgende sprint op te pakken is de kans groot dat geen van de punten ook echt verbeterd. Kies de belangrijkste punten uit en beperk je tot maximaal 2 punten. Liever 1 verbeterpunt goed opgepakt met een tastbaar resultaat aan het einde van de sprint dan 5 punten half.
4. Decentralized Command / Decentraliseer gezag
In het boek wordt een voorbeeld gegeven hoe tijdens de training geleerd wordt dat de leiders niet alles kunnen overzien wat er gebeurt De instructeurs gooien tijdens een trainingsscenario alles naar de SEALs wat ze kunnen verzinnen. De leiders moeten leren om niet alle beslissingen zelf te maken maar duidelijke lijnen uit te zetten en de teamleiders de teams aan te laten sturen om zo het doel te bereiken. Ook wordt verteld hoe schutters lange afstand (sluipschutter) keuzen in het veld moeten maken. Een voorbeeld is bij een gebouw komen waar ze zich zouden verschansen om dekking te geven tijdens een missie en het gebouw staat verder van de straat dan verwacht. Dan wordt in het veld bepaald welk gebouw wel geschikt is en wordt de nieuwe locatie doorgegeven aan de leiding op de basis. Er wordt dus niet aan de leiding gevraagd waar ze naartoe moeten.
Als Scrum Master is het je doel om jezelf eigenlijk overbodig te maken in je team. Een Scrum Master heeft geen gezag maar is een dienend leider. Je begeleidt het team zodat ze uiteindelijk zelfstandig het Scrum framework kunnen toepassen. Bijvoorbeeld bij de planning zorgt de Scrum Master ervoor dat de planning plaats kan vinden en dat alle aanwezigen het doel ervan begrijpen. De Scrum Master leert het Scrum Team om de planning binnen de time-box af te ronden. Er is in de Scrum guide geen verwijzing naar dat de Scrum Master de events voorzit of de leiding heeft over de events. Letterlijk staat er: “Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig”. Het gezag ligt bij het team. Het Ontwikkelteam voorspelt welke functionaliteit ze opleveren aan het einde van de sprint. Samen met de Product Owner bespreken ze wat het sprintdoel is. De Product Backlog wordt gebruikt om items te selecteren om het sprintdoel te bereiken. Hoeveel items er opgepakt worden, bepaalt het Ontwikkelteam. Dit wordt niet van bovenaf opgelegd. Tijdens de sprint houdt het Ontwikkelteam het sprintdoel voor ogen. Als het nodig is, worden de werkzaamheden aangepast om zo alsnog het sprintdoel te halen. Hetzelfde als de sluipschutters die tijdens de missie een ander gebouw moesten kiezen om toch de juiste dekking te kunnen geven aan hun mede SEALs.