Volg ons en blijf op de hoogte van nieuwe content!
Wat is het commitment van het Scrum Team ?
Welke van onderstaande commitments wordt door het Scrum Team genomen volgens de Scrum Guide?
Het antwoord geven we onderaan dit artikel!
Eerst leggen we uit wat het verband is tussen de Sprint Planning en Stratego (of een ander gezelschapsspel)
Scrum Basics
Scrum is een framework dat mensen, teams en organisaties helpt om waarde te creёren door middel van adaptieve oplossingen voor complexe problemen.
In het kort heeft Scrum een Scrum Master nodig om een omgeving te bevorderen waar:
- Een Product Owner het werk voor een complex probleem ordent in een Product Backlog.
- Een Scrum Team een selectie van dit werk verandert in een waardevol Increment tijdens een Sprint.
- Een Scrum Team en zijn belanghebbenden de resultaten inspecteren en zich aanpassen voor de volgende Sprint.
- Herhaal.
Developers zijn de mensen in het Scrum Team die iedere Sprint gecommitteerd zijn aan het maken van
elk aspect van een bruikbaar Increment.
Developers zijn altijd verantwoordelijk voor:
- Het creëren van een plan voor de Sprint; de Sprint Backlog;
- Het garanderen van kwaliteit door vast te houden aan een Definition of Done;
- Het dagelijks aanpassen van hun plan richting het Sprint Doel;
- Het elkaar verantwoordelijk houden als professionals.
Dus volgens de Scrum Guide is het team verantwoordelijk voor het creëren van een plan voor de Sprint alsook het dagelijks aanpassen van hun plan richting het Sprint Doel.
Wat wil dit zeggen? 🤷
Let’s talk Stratego-taal !
Stratego?!
Je kent het spel vast wel? 2 spelers, elk met een leger gaande van bommen, sergeanten, generaals en de vlag. Elke speler start aan een zijde van het bord, met als doel de eigen pionnen zo te plaatsen dat “de vijand” de vlag niet kan pakken en ook de strategie te bedenken om de vlag van de tegenspeler wel te kunnen bemachtigen en dus het spel te winnen.
Memories! 
Zet ik de bommen vooraan en er sterke achter om de Ontmijner van de tegenspeler te pakken als die onze bom onschadelijk gemaakt heeft? Waar zet ik mijn spion? En mijn Maarschalk ? En mijn vlag? In de linkeronderhoek omgeven door bommen? Of toch maar ergens in het midden omdat de andere dat niet zal verwachten?
Stratego vraagt dus ook om te anticiperen op hoe de tegenspeler (waarschijnlijk) hun opstelling zal doen.
Hier heb je weer andere inzichten voor nodig om een goed plan-van-aanpak op te stellen : Hebben jullie dit spel al samen gedaan? Wat waren eerdere strategieën van de tegenspeler, zowel naar verdediging als aanval? En hoe zeker zijn we dat nu een zelfde strategie toegepast zal worden?
Stratego is dus een combinatie van:
- inzichten in de sterkte en zwakte van de eigen pionnen.
- inzichten in hoe de eigen pionnen het best geplaatst worden ten opzichte van elkaar en tov mogelijke aanval acties van de tegenspeler.
- inzichten van op welke manier de tegenspeler hun pionnen zou kunnen plaatsen.
- inzichten om snel van aanpak te kunnen wisselen moest de tegenspeler anders handelen dan verwacht.
Zonder het toen als kind te beseffen, waren we onze eerste stappen aan het zetten in systeem denken (systems thinking), waarbij we verschillende aspecten in rekening moesten brengen om tot een plan-van-aanpak te komen. Deze aspecten bevatten zowel zaken waar we zeker van waren (bv de sterkte en zwakte van eigen pionnen) alsook zaken die we met een hoge kans tot realiteit gingen inschatten (bv de strategie van de tegenspeler).
Systeem Denken (Systems Thinking)
Systeemdenken is een wetenschappelijke benadering die tracht overzicht van het geheel te behouden, in plaats van zich te concentreren op afzonderlijke onderdelen zonder te overwegen welke rol deze delen in het groter geheel spelen. Men beschouwt het gedrag van een systeem (bijvoorbeeld een ecosysteem) niet als een simpele keten van oorzaak-gevolgrelaties, maar als het samenspel van met elkaar interagerende deelsystemen, waarbij terugkoppeling een belangrijke rol speelt. Systeemdenken vereist een holistische kijk op het te bestuderen systeem. Dit wil zeggen dat er niet alleen naar de afzonderlijke deelsystemen gekeken wordt, maar vooral ook naar de manier waarop zij wisselwerking vertonen en naar hun plaats in het geheel.
Wanneer – zoals in ons Stratego voorbeeld – er een menselijke activiteit of emotie onderdeel is van een systeem, dan neemt de complexiteit en de mogelijke uitkomsten van dat systeem toe. Ik zet mijn vlag links tenzij ik weet dat de tegenspeler weet dat ik dat altijd doe .. dan zet ik em in het midden .. of weet de tegenspeler dat ik dat nu denk?
The behavior of a system cannot be known just by knowing the elements of which the system is made.
Systeem denken en software ontwikkeling
Als we het Increment als de uitkomst beschouwen van het systeem, dan zijn een aantal elementen uit dat systeem oa. 1000den lijnen code, third party componenten, organisatie procedures, team afspraken, build systemen, beschikbare documentatie, data kwaliteit, … , en mensen, binnen en buiten het Scrum Team die iets bij te dragen hebben.
Software bouwen is met andere woorden geen evidentie. (Alhoewel, zoals elke professional, Developers dit als piece-of-cake laten uitschijnen). Het is zich bewegen in een complexe en soms zelf chaotische omgeving (https://en.wikipedia.org/wiki/Cynefin_framework)
Het kenmerk van complexe en chaotische systemen? De uitkomst kan niet op voorhand worden vastgelegd. We kunnen er wel, vaak proefondervindelijk, naar toe werken.
Waarom? bv. Een build runnen duurt meestal 20 minuten, maar soms ook meer dan een uur. Data op de test omgeving opnieuw opladen vraagt 5 uur werk. De databanken worden door een ander team beheerd, we hebben geen zekerheid op responsetijd in geval van issues, …
Dus op het moment dat iets niet-standaard voor valt (wat in software ontwikkeling of in het algemeen binnen complexe of chaotische systemen de modus operandi is), gaan mensen, teams proef ondervindelijk aan de slag om het issue op te lossen.
Systeem denken, software ontwikkeling en Sprint Planning
Zonder het misschien te beseffen is software ontwikkeling Systeem denken : We kijken niet naar elk onderdeel (build systeem, data, mensen, .. ) apart. Zouden we dit wel doen en op basis van onze ervaring een planning maken .. ‘k denk dat er niet veel tijd over blijft om te programmeren 
In de Sprint Planning bespreekt en besluit het team, op basis van de Product Backlog en toelichting van de Product Owner, de wat en hoe ze dit gaan realiseren (= Sprint Backlog).
Om de opgestelde Sprint Backlog realistisch en haalbaar te maken, wordt er naar data gekeken van de vorige Sprints, zoals Velocity, Eerdere schattingen tov effectieve werk, gekende afhankelijkheden met andere teams, .. alsook naar zaken die we kunnen voorspellen : geplande afwezigheden, test omgeving niet beschikbaar op bepaalde dagen, …
Echter heel wat zaken zijn nog niet gekend en zullen pas aan het licht komen op het moment dat het team aan een Backlog Item werkt.
De Sprint Planning is bijgevolg een indicatie, een streven naar wat het team denkt te kunnen opleveren rekening gehouden met wat ze weten. Enkel met wat ze weten!
Stratego en Sprint Planning
Interesse om samen met ons, teams en organisaties te helpen groeien?
ohja … TLDR; Het juiste antwoord:
Het Scrum Team commit zich op het halen van het Sprint Doel zoals tijdens de Sprint Planning door hen is opgesteld. Ze committen hun niet op het halen van de planning.
Reden : Product ontwikkeling is een complex gegeven met heel wat onzekerheden en risico’s. Het Sprint Doel zorgt voor richting en voor de nodige vrijheidsgraden zodat het team op basis van de realiteit hun plan kunnen aanpassen om het Sprint Doel te halen binnen de timebox van de Sprint. Het Sprint Doel is leading. De planning er naar toe is supporting.
