• Agile & Scrum Basics

Scrum – Back to Basics

Scrum wordt steeds populairder. Scrum is hip. En dat terwijl 3 jaar geleden nog bijna niemand wist wat scrum was. De terminologie vliegt je om de oren: sprint, demo, backlog, planning poker, spike,… Iedereen ontwikkelt zijn eigen variant. Allemaal net anders. Maar wie heeft de wijsheid in pacht?

In dit artikel geeft Anton Vanhoucke, scrum master van het eerste uur, 4 handvatten waarmee je het kaf van het koren kunt scheiden. Elke tool en spelregel van scrum kan je meten tegen deze ‘Agile’ principes. Dragen ze er aan bij? Houden! Twijfel je? Probeer het zo snel mogelijk weg te laten. Misschien gaat je proces wel soepeler lopen!

Handvat 1: Interactie tussen mensen gaat boven processen en tools

Scrum brengt veel nieuwe mini-processen en -tools. Het is makkelijk om je daarin te verliezen. Je bent geneigd om extra regels en afspraken te bedenken bij elke tussentijdse evaluatie. Of je plakt scrum-namen op de dingen die altijd al deed. Zo ga je scrummen in vorm maar niet in geest.

Want Agile werken betekent dat je mensen en interactie tussen mensen laat voorgaan op processen en regels. Als het niet helemaal werkt, kan je beter even de koppen bij elkaar steken dan je proces verder definiëren.

En scrum zelf, dat is toch ook een proces? Is dat niet paradoxaal? Het principe zegt dat interactie boven processen gaat, maar het zegt niet dat je alle processen de deur uit moet doen.

Het kan zo veel makkelijker. Als je maar anders kijkt.

Neem bijvoorbeeld scrum story points. In scrum kennen we story points toe aan de werkvoorraad. Dit doen we om gevoel te krijgen voor de grootte van die werkpakketten in de werkvoorraad. Het toekennen van story points is een groepsproces dat tot gezonde discussie leidt: aannames komen altijd boven water als je bespreekt waarom iets veel of weinig werk is. Het zorgt er ook voor dat een team zich kan committeren aan een hoeveelheid werkpakketten. In de praktijk kan het echter voorkomen dat een voortvarende scrummaster in haar eentje de story points gaat toekennen. Dat lijkt wel zo efficiënt want je hoeft er niet zo lang over te praten. Maar dan ga je voorbij aan het doel van de story points en stel je het proces boven de interactie. Je gaat voorbij aan het eerste Agile principe.

Handvat 2: Producten gaan boven administratie en documentatie

In scrum willen we dingen maken. Omdat het fijner is om dingen te hebben die werken dan om dingen te hebben waar je enkel lang over hebt gepraat. Omdat je van werkende dingen het meest kan leren. Omdat werkende dingen het meest waardevol zijn voor de eindklant. Toch is het handig om hier en daar wat administratie bij te houden. Bijvoorbeeld van ideeën voor features die je niet direct gaat bouwen. Of problemen die je niet direct kan oplossen. Of van stappenplannen die je niet elke dag doorloopt.

Het is belangrijk om je steeds af te vragen: is het echt nodig om dit op te schrijven? Gaat iemand het ooit lezen? Wie? Wat is het doel van deze administratie? Kan ik dat ook op een eenvoudigere manier bereiken?

Neem bijvoorbeeld scrum planning poker: Je kan slaafs bij elke sprint planning meeting alle user stories schrijven en inschatten met planning poker omdat dat nu eenmaal zo hoort. Je kan je ook afvragen: als planning poker als doel heeft om verborgen aannames boven water te halen en de burn down eerlijk te laten verlopen, kan het dan ook eenvoudiger? Wat als we alle user stories schrijven en gewoon even groot zouden maken? Dat laat je toe om zonder story points te werken. Dit werkt niet in alle projecten, maar het kan de administratie in je scrumproject verlagen.

Handvat 3: Samenwerken gaat boven onderhandelen over contracten

Je haalt het beste uit een team als de leden eigenaarschap voelen. Als het hele team uitgedaagd wordt om samen te werken aan het leveren van business value. Het draait op intrinsieke motivatie. Het opstellen van een klassiek contract, waarbij voor een bepaald bedrag bepaalde functionaliteiten worden geleverd heeft juist het omgekeerde effect. Dan wordt het project een soort kleurplaat, waarbij het team netjes binnen de lijntjes gaat kleuren. In scrumcontracten staat dan ook geen vastomlijnde projectscope.

Je gebruikt de scrum backlog — de werkvoorraad — om een gezonde discussie te hebben over prioriteit en mate van afwerking van de projectresultaten.

Ik heb meegemaakt dat een backlog gebruikt wordt als contract. Dan is er geen samenwerken meer, maar een stok achter de deur. Het team gaat haar energie stoppen in het ontwijken van de stok in plaats van in creativiteit.

Handvat 4: Handelen naar voortschrijdend inzicht boven het slaafs volgen van een plan

Als je aan een groot project begint is een plan altijd handig. Het helpt je om dingen niet over het hoofd te zien. De kunst is om flexibel met een plan om te gaan. Zo’n plan is namelijk nooit gemaakt met een kristallen bol: er is nooit een totaaloverzicht van de situatie of totaal inzicht in de toekomst. Je kan er bijna gif op innemen dat het anders uitpakt dan je gedacht had.

Een Agile en Scrum methode zoals scrum houdt daar rekening mee en helpt je om flexibel te blijven. Maar het is geen garantie. Veel hangt ook af van je mindset. Zo kan het voorkomen dat de staande werkvoorraad beter opgepakt kan worden in een andere teamsamenstelling. Stug door gaan met hetzelfde team is dan een minder goed idee, zelfs al was het zo geregeld en gepland. Het kan zelfs voorkomen dat scrum op een bepaald moment niet meer de handigste manier is om het werk aan te pakken wat er ligt. Misschien is een kanban proces effectiever. Bijvoorbeeld als het team na de eerste oplevering in een service & support situatie terecht komt.

Conclusie

Als je overdonderd wordt met een berg nieuwe spelregels en processen omdat je scrum voor het eerst toepast kan je altijd teruggrijpen op deze vier eenvoudige principes:

• Mensen en interactie gaan boven processen en tools
• Afgewerkte producten gaan boven administratie en documentatie
• Samenwerken gaat boven onderhandelen over contracten
• Handelen naar voortschrijdend inzicht boven het slaafs volgen van een plan
• Ze helpen je prioriteiten stellen en de spelregels van scrum goed te interpreteren.