Wat betekent de nieuwe Scrum Guide in de praktijk?
Woensdag 18 november werd in een aangekondigd webinar van Scrum.org en Scrum.inc de nieuwe Scrum Guide gepresenteerd, een document met daarin alle basisregels van Scrum. Het was dringen in de virtuele rij om een plekje te bemachtigen.
Wij, Martin van den Berg (Agile Coach) en Jeroen Aelen (Trainer & Scrum Master) waren aanwezig en nemen je mee in onze bevindingen. Wat is ons opgevallen aan de renovatie van de scrumgids? Zijn de wijzigingen wel echt een verbetering? Lees hieronder de wat en waarom’s. We beginnen met waarom deze wijzigingen volgens ons nodig waren. Daarna gaan we in op de wijzigingen zelf en hun effect op de praktijk.
Wat is Scrum ook alweer?
En waar komt dit Agile gedachtengoed vandaan?
Volgens de Scrum Guide is Scrum ‘een lichtgewicht raamwerk dat mensen, teams en organisaties helpt om waarde te creёren door middel van adaptieve oplossingen voor complexe problemen.’ Een hele mond vol.
De kern van Scrum is dat de scope van projecten niet van A tot Z wordt vastgezet. In plaats daarvan worden deze projecten, producten of processen (afhankelijk van waar je Scrum voor inzet) stap voor stap ontwikkeld door het Scrum Team en getoetst met de klant. Lees hier meer over Scrum. Scrum valt als werkwijze onder de agile manier van werken, een filosofie die draait om sneller en wendbaarder klantwaarde kunnen leveren. Lees hier meer over Agile werken.
Waarom waren er wijzigingen nodig in de scrumgids?
Het stap voor stap ontwikkelen van het product binnen Scrum betekent dat je regelmatig een nieuwe versie oplevert, een deelproduct. In Scrum wordt dit het ‘Increment’ genoemd. Het gedachtengoed van Scrum wordt ook op deze manier ontwikkeld. Eens in de paar jaar wordt er een nieuwe versie gepubliceerd, gebaseerd op de ervaringen die zijn opgedaan wereldwijd. Wij zien twee belangrijke redenen waarom de scrumgids toe was aan een nieuwe update.
1. Agile en Scrum worden gezien als een doel op zich, terwijl het een middel is
Als je als organisatie wilt beginnen met Scrum, is het heel belangrijk om goed na te denken waarom je dat precies wilt. Veel bedrijven doen dat niet, waardoor Agile werken opeens een losstaand doel wordt. ‘Agility is not the goal’ is hier het duidelijke advies. Uiteindelijk wil je met Agile een bepaald doel bereiken, bijvoorbeeld een bepaald product ontwikkelen waar je klanten blij van worden. In de oude Scrum Guide werd er – wat ons betreft – niet veel nadruk gelegd op het ‘waarom’ van Scrum. Reden voor verandering dus.
2. De regels van Scrum worden uitgevoerd, zonder de gedachte daarachter na te leven
Wat ons nog verder opviel aan de vorige versies van de Scrum Guide, is dat Scrum Teams de adviezen die erin staan vaak letterlijk nemen. In de vorige versie stond bijvoorbeeld dat je de Daily Scrum (de dagstart) kan inrichten aan de hand van drie vragen. In praktijk betekende dit dat de Daily Scrum vaak uitmondt in het elkaar mechanisch stellen van deze drie vragen:
- Wat heb je gisteren gedaan?
- Wat ga je vandaag doen?
- Zijn er nog belemmeringen die je tegenhouden?
Het probleem is dat deze aanpak niet leidt tot samenwerking en het bereiken van je Sprint Doel. Uiteraard was dit niet hoe Scrum oorspronkelijk bedoeld was. Maar lerend van de praktijk, was het naar ons idee wel noodzakelijk dat hier een aanpassingen in gedaan zou worden.
Taferelen zoals hierboven zien we vaak als we bij een klant op de werkvloer komen. Een goede Scrum Master is verantwoordelijk (accountable) voor de effectiviteit van het Scrum Team en zou zich dus geroepen moeten voelen om van de mechanische Scrum weer een levendige Scrum te maken. Helaas wordt in veel organisaties de Scrum Master gezien als een secretaresse of iemand die alleen de obstakels (impediments) wegbezemt voor het team. In de nieuwe Scrum Guide zijn de verantwoordelijkheden van de Scrum Master aangepast, om zo het leiderschap van de Scrum Master meer te benadrukken.
Hoe veranderen de wijzigingen van de scrumgids jouw praktijk (als Scrum Master of Agile coach?)
Oké lang genoeg in spanning gewacht, tijd voor hoofd-act van dit artikel; de wijzigingen in de nieuwe scruimguide. Hieronder vind je een overzicht van de belangrijkste wijzigingen. En we geven daarbij direct een toelichting op het effect in de praktijk.
De wijzigingen op een rijtje
Veel adviezen over ‘hoe’ Scrum in de praktijk toegepast moet worden zijn in deze editie versimpeld of verwijderd. Al deze kleine wijzigingen maken Scrum flexibeler in de uitvoering. Scrum is nu in theorie ook beter toepasbaar in omgevingen buiten IT, waar men niet dagelijks te maken heeft met het digitale processen. Dit is iets wat wij toejuichen en ook al benadrukken in onze Agile en Scrum trainingen: het is een framework wat in allerlei omgevingen toe is te passen. Van marketing tot innovatie en van communicatie tot onderwijsontwikkeling. Scrum is simpel gesteld een framework om complexe problemen op te lossen, waar die zich ook maar voordoen.
Veel Scrum Teams leven in de waan van de dag. Ze ronden taak na taak af, zonder daarbij altijd een duidelijke uitkomst voor de klant voor ogen te houden. Die uitkomst helpt juist het hele Scrum Team te focussen, wat ervoor zorgt dat je eerder je visie in de praktijk gaat brengen. Daarnaast werkt het motiverend voor een team om naar een helder doel toe te werken. Je wilt als teamlid niet alleen maar een losse taak uitvoeren, maar ook het gevoel hebben dat het werk bijdraagt aan een hoger doel. Daarom is in deze editie van de Scrum Guide het Product Doel (Product Goal) geïntroduceerd. Dit lange termijn doel geeft richting aan de Product Backlog: wat komt er wel of niet in en waaraan geven we prioriteit? Je kan het vergelijken met wat een Sprint Doel is voor de Sprint; je hebt er maar één van tegelijk.
Oh nee! Scrum gaat toch over teamwerk? En nu wordt het Development Team verwijderd en vervangen door Developers. Een groep. Dit lijkt een kleine tekstuele wijziging, maar betekent in theorie en praktijk heel veel. Volgens de oude regels van het spel bestonden er twee teams, namelijk het Scrum Team en het Development Team. In de nieuwe Scrum Guide zijn alle verantwoordelijkheden ondergebracht in één team: het Scrum Team. Het Development Team gaat verder als Developers.
Deze subtiele wijziging benadrukt het commitment van de Product Owner en de Scrum Master aan de Developers. Het benadrukt het teamwerk nog meer door het verwijderen van wat soms als een sub-team werd ervaren, het Development Team. Uiteraard blijven de Developers samen een heldere verantwoordelijkheid hebben en zullen zij veel moeten samenwerken om het (deel)product te leveren. Waar de Scrum Master vaak werk heeft om de Product Owner en het Development Team echt goed samen te laten werken is het belang nu versterkt in een team, het Scrum Team. Dat maakt de rol van teamcoach voor de Scrum Master een stukje makkelijker. Wat ons betreft een krachtige wijziging!
Wij verwachten dat het makkelijker wordt om elkaar aan te spreken en om het gevoel van samen presteren te ervaren. Het vormen van één team is cruciaal voor het ontwikkelen van een high performing team. Een high performing team ervaart een diepgewortelde gedeelde verantwoordelijkheid, waardoor zij onder andere elkaar op een goede manier houden aan afspraken en effectief beslissingen kunnen nemen. Wij zien in de praktijk dat developers het gebrek aan goede resultaten afschuiven op de Product Owner. Een concreet experiment wat wij de Scrum Master van zo’n team zouden aanraden is als volgt. Neem met het gehele Scrum Team de wijzigingen in de verantwoordelijkheden in de Scrum Guide door. Bepaal vervolgens wat jullie op basis hiervan anders willen gaan doen als team.
Bij UPD vinden wij Kaizen, continu verbeteren in kleine stappen, cruciaal voor het succes van teams en bedrijven. We zien dat sommige teams tijdens de Sprint niet actief bezig zijn met het ophalen en implementeren van verbeteringen, maar hiervoor wachten tot de Sprint Retrospective. Vanuit de Sprint Retrospective wordt dan minimaal één verbetering toegevoegd aan de Sprint Backlog van de volgende Sprint. In de nieuwe Scrum Guide staat echter: ‘De meest impactvolle verbeteringen worden zo snel mogelijk aangepakt. Ze kunnen zelfs worden toegevoegd aan de Sprint Backlog voor de volgende Sprint’.
De nieuwe beschrijvingen houden andere mogelijkheden tot verbetering open en daar worden wij zeker enthousiast van. Door Continu Verbeteren te verkleinen naar het toevoegen van minimaal één verbetering aan de Sprint Backlog voelt heel duidelijk, maar het laat de Scrum Master en Product Owner vrij. Dit omdat het Development Team verantwoordelijk is voor wat er in de Sprint Backlog staat. Wat wij in de praktijk veel terugzien is de afstand tussen de Product Owner en het Development Team. Veel Product Owners hebben iets van ‘Ik bedenk het en zij doen het’. Wat logisch is, gezien de achtergrond van veel Product Owners als projectmanager of teamleider. Agile en Scrum gaan echt veel meer over teamwerk dan PRINCE2. Scrum vraagt meer van het zelfsturende/organiserende vermogen van een team. Wat betreft continu verbeteren staat de Product Owner nu dus niet meer los van het team. Een hele verbetering!
Om als team en organisatie te kunnen presteren is het nodig om gedeelde verantwoordelijkheid te nemen om het gemeenschappelijke doel en de ‘taak’ of processen. Als teamlid moet je jezelf in kunnen zetten voor de groep, voor het grotere geheel. Commitment op de Sprint Goal gaat over het creëren van die gedeelde verantwoordelijkheid. En om te doen wat nu belangrijk is voor het team. En bijvoorbeeld niet die ene story die jij zo leuk vindt eerst oppakken, terwijl er belangrijkere stories nog niet af zijn.
Nu is er de Product Goal bijgekomen. Volgens ons helpt dit om de gedeelde verantwoordelijkheid binnen het Scrum Team te vergroten. De productvisie is niet alleen van de Product Owner, maar van het gehele team. De Product Owner is alleen maar een rol die de verantwoordelijkheid draagt om een productvisie en klantwensen te vertalen naar werk. Nu er commitment wordt verlangd van het hele team op de Product Goal kan niemand er meer om heen.
De nieuwe Scrum Guide is enerzijds minder voorschrijvend, maar op het gebied van commitment schept het eigenlijk meer verwachtingen van het Scrum Team. Namelijk voortdurend met elkaar commitment afgeven op zowel, Product Goal, Sprint Goal, Sprint Backlog en Definition of Done. Het team maakt dus voortdurend afspraken met elkaar. Hoe lukt het in jouw team eigenlijk met afspraken maken en besluiten nemen? Wat wij zien is dat dit makkelijker wordt als een team inzicht heeft in elkaars voorkeursrol(len) en er meer begrip is voor verschillen. Dit kan bijvoorbeeld met het teamrollenmodel van Belbin.
Al tijdens het schrijven van het Agile Manifesto (2001) werd al benadrukt dat het meten van de hoeveelheid werk die een team kan verrichten, ondergeschikt is aan de waarde (kwaliteit) en de snelheid waarmee de incrementen naar de markt kunnen worden gebracht. Lean denken is altijd al aanwezig geweest. Binnen Agile is men zeker bewust van Lean principes. Agile Coach Hendrik Kniberg heeft hier in 2014 dit, inmiddels meer dan honderdduizend keer bekeken, filmpje over gemaakt: https://www.youtube.com/watch?v=CostXs2p6r0
In dit filmpje over Agile werken gebruikt hij concepten die veel binnen Lean worden gebruikt, zoals flow en throughput, om de optimale capaciteit en doorlooptijd van het team te bepalen. Deze manier van Lean-werken heet Kanban en wordt binnen Scrum steeds populairder. Lean wordt voor het eerst genoemd in deze Scrum Guide: ‘Scrum is gebaseerd op empirisme en Lean denken. Empirisme beweert dat kennis ontstaat uit ervaring en dat men beslissingen neemt op basis van wat bekend is. Lean denken vermindert verspilling en richt zich op de meest belangrijke dingen.’
Laat dat tweede nou precies zijn waar wij in de praktijk met Scrum Teams vaak tegenaan lopen. Met Scrum kan je heel goed leren tijdens het ontwikkelproces en op basis daarvan nieuwe beslissingen maken. Het is echter wel zo handig om tijdens dat proces na te denken over standaarden. Je wilt als team niet elke keer het wiel opnieuw uit hoeven vinden. Door het proces te bekijken via een Lean bril, kom je als team erachter dat sommige zaken efficiënter ingericht kunnen worden. Wij zeggen daarom al jaren dat Agile en Lean heel goed samen toegepast kunnen worden en zijn dan ook heel blij dat dat in de nieuwe Scrum Guide wordt benadrukt. Door bijvoorbeeld met je team een waardestroomanalyse (Lean) te doen, kan je onderzoeken hoe lang elke stap duurt in jullie proces en waar de bottlenecks liggen. Op die manier kan je beter inschatten wat je wel of niet binnen een Sprint kan afronden, waardoor je beter waarde kan leveren voor de klant.
Kortom
Wat ons betreft zijn de wijzigingen deze editie van de Scrumgids dus een welkome verbetering. Er wordt veel meer gewezen op de doelen achter Scrum, die in de praktijk wel eens verloren gaan. Mogelijk is het voor nieuwe gebruikers van Scrum wat lastiger om vanaf de start deze doelen goed te begrijpen. Daarom is het belangrijk dat er vanuit de organisatie of het team zelf goede begeleiding wordt geboden. Als de basis goed is gelegd, kan het team zelf gaan experimenteren met de ‘hoe’, de uiteindelijke invulling van Scrum. Want daar draait Scrum uiteindelijk om: waarde creëren voor échte klanten in de praktijk.
Scrumgids wijzigingen toepassen in de praktijk?
Wil je na dit alles meer weten over Agile en Scrum? Neem dan een kijkje bij een gratis introductie Agile en Scrum of bij één van onze andere opleidingen.
Wil je met jouw afdeling of organisatie Agile gaan werken? Bij UPD hebben we het Scrum Framework toepasbaar gemaakt voor jouw eigen praktijk in de vorm van de UPD Scrum Roadmap. Al onze opleidingen en consulting zijn op die manier ingericht om je te helpen Agile en Scrum voor jou te laten werken, voor het doel wat jij daarmee voor ogen hebt!
Auteurs: Jeroen Aelen & Martin van den Berg
Jeroen heeft als Scrum Master, Lean trainer en Belbin coach ruime ervaring opgedaan bij toonaangevende organisaties als Rabobank en Van Lanschot. Hij kenmerkt zich als een energieke en innovatieve Agile professional die als geen ander de toegevoegde waarde van Agile en Scrum kan vertellen én overbrengen.
Martin is Agile & Lean Coach, Transformation Lead en gecertificeerd teamcoach. In zijn carrière begeleidde hij onder andere ING en NS tot een meer wendbare organisatie.
Wil je eens met Jeroen of Martin van gedachten wisselen over Agile, Scrum en/of Lean? Neem dan contact met hen op via 020-345 3015.