Scrum is denk ik de meest gebruikte methode binnen het Agile werken. De scrum-methodiek is een logische keuze voor teams die werken in de software-ontwikkeling (van waaruit zowel het Agile Manifesto als de methodiek Scrum zijn ontstaan). De laatste tijd zie ik dat ook bij teams met andere werkzaamheden vaak Scrum als methodiek wordt geadopteerd. Maar de vraag die vervolgens te weinig gesteld wordt, is of dit ook de béste methode is om in te voeren voor jouw team(s). Je kunt gemakkelijk vooraf checken of de methode wel bij het team past…
1. Het team heeft weinig gemeenschappelijk
Een van de belangrijkste zaken voor een succesvol team is een helder gemeenschappelijk doel. In het Engels gebruiken we het woord ‘purpose’ in plaats van ‘doel‘. In het Nederlands wordt dit vaak vertaald naar het woord ‘doel’, maar het gaat verder dan dat. Purpose geeft aan dat het team een gemeenschappelijke drijfveer, of ‘hoger doel’ zou moeten hebben. Een team zonder duidelijk doel valt snel (soms zelfs letterlijk) uiteen. De term ‘groep’ is meer op zijn plaats dan ‘team’.
Scrummen zonder duidelijk gemeenschappelijk doel leidt vroeg of laat tot problemen. Symptomen die aangeven dat er weinig gemeenschappelijk is, zijn bijvoorbeeld veel userstories tegelijkertijd in sprint (doordat mensen weinig gezamenlijke userstories hebben), weinig energie in refinements en een lage opkomst bij standups.
De oplossing voor een dergelijk team is simpel: stop met het samenwerken als team of zorg dat je een helder gemeenschappelijk doel vindt. Of je nu in de Scrum methodiek werkt of een willekeurige andere, het gaat je team geen windeieren leggen om met meer samenhang aan zaken te werken! De enige keuze die niet gaat werken is geen keuze, hoe makkelijk dat soms ook is op de korte termijn.
2. Minder dan 60% is ontwikkelwerk
Een traditioneel scrumteam kan zichzelf elke ochtend bij de standup de vraag stellen: ‘Wat zullen we vandaag eens maken?’. Dit betekent dat ze (op welke manier dan ook) met een creatief proces bezig zijn. De inhoud is meestal complex, hetzij inhoudelijk of qua planning. Daar leent Scrum zich uitstekend voor. Met de oorsprong in software-ontwikkeling is dat dan ook niet zo gek.
Maar wat nou als jouw team niet het merendeel van zijn tijd bezig is met (software) ontwikkeling? Dan is de kans groot dat scrum niet de beste methodiek is. Kun je daarmee zeggen dat het nooit past? Nee, dat is te kort door de bocht. Maar de ervaring leert dat er aardig wat beren op de weg liggen. Hoe herken je die?
De symptomen van een team met minder ‘ontwikkelwerk’ waarbij de gekozen scrum-methodiek niet passend blijkt, zijn ook vrij duidelijk. De sprint moet vaak opengebroken worden (“maar dit moet echt even gebeuren deze sprint”), de backlog voor de komende sprints is kort (of in sommige gevallen zelfs afwezig) en teamleden trekken de methodiek vaak openlijk in twijfel, of haken zichtbaar af.
De manier om dit op te lossen is een beter passende methodiek te gebruiken. Voor de hand ligt Kanban. Kanban heeft een oorsprong in de LEAN-methodiek, en is in veel gevallen goed te gebruiken. Het legt, in vergelijking met Scrum, minder de focus op de planning en backlog en meer op ‘flow’. Door de werkzaamheden transparant weer te geven, en niet teveel tegelijk op te pakken, kun je als team enorm aan effectiviteit winnen. Daarmee zou voor dit soort teams ‘Kanban’ een veel betere methodiek kunnen zijn.
3. Voor ieder ‘project’ een Scrumteam
Ik kom geregeld in organisaties waar Agile wordt ingevoerd, zonder dat (bewust of onbewust) er getornd wordt aan bestaande werkafspraken. Zo kan de effectiviteit van het invoeren van Agile teniet worden gedaan. Wat ik vaak tegenkom is dat er een team is, maar dat er allerlei belangrijke werkzaamheden en doelen in projecten belegd zijn (de definitie van een project is daarbij variabel). In de praktijk betekent het wel dat een medewerker zomaar in 4 ‘projecten’ tegelijk kan zitten, naast zijn team.
Ga je die projecten als Scrumteams laten functioneren, dan wordt er het één en ander bloot gelegd. Symptomen die je hierbij ziet is een gebrek aan focus in het team (welke gezamenlijke doelen proberen we te behalen?), prioriteiten stellen lukt niet op het niveau van een scrumteam (wat is nu het meest belangrijk?) en de Product Owner heeft niet het overzicht om de juiste beslissingen te nemen. De afhankelijkheden op inhoud en capaciteit naar andere teams zijn vaak groot. Daarnaast zie je dat teamleden afhaken omdat zij in meerdere teams moeten deelnemen aan de scrum bijeenkomsten zoals stand-ups, retrospectives, planning etcetera.
Verder ontstaat er, als werk op deze manier verdeeld is, vaak een verkeerd beeld over de werkdruk, planning en bijbehorende beloftes richting klanten met alle gevolgen van dien. Omdat inhoud en capaciteit zo door elkaar lopen is het bijzonder moeilijk om (centraal) het overzicht te houden. Daarmee vindt besluitvorming over het algemeen niet plaats op basis van feiten en krijgt de ‘politiek’ gemakkelijk de overhand.
Als een organisatie gemotiveerd is om Agile te gaan werken, vraagt dit om een fundamentele aanpak. Daarmee is het dus van belang om het organiseren van teams en ‘brokken’ werk te herzien. Dit gaat niet zonder ook de doelen en prioriteiten opnieuw vast te stellen.
Aandacht voor teamvorming kost op de korte termijn tijd, maar gaat op de langere termijn zich zonder enige twijfel uitbetalen. Als je eenmaal goed functionerende teams hebt en behoudt, kun je daar het werk naar toe brengen. Dus niet de medewerkers (iedere keer in andere samenstelling) naar het werk brengen. In de nieuwe realiteit betekent dit bijvoorbeeld 1 vast team die alle 4 de ‘projecten’ oppakken. Dan moet helder worden gemaakt wat de prioritering is en in welke logische volgorde die 4 projecten moeten worden opgepakt, zodat dit voor de organisatie de meeste toegevoegde waarde oplevert.
Uiteraard heeft deze manier van denken gevolgen voor de teamsamenstelling. Want heb je in ieder team wel de juiste disciplines vertegenwoordigd? Kun je alle ‘projecten’ straks zonder het team aan te passen naar 1 van de teams brengen om die het ‘project’ te laten uitvoeren? Belangrijk om hier vooraf goed over na te denken!
Hoe voorkom je die “verkeerde” keuzes?
Wat is dan de juiste keuze? Ooit heb ik geleerd van de coaches van Spotify in Stockholm: “It depends…”. Zeer frusterend, maar wel ontzettend waar.
‘Bezint eer ge begint’ is in ieder geval op zijn plek. Ik denk dat mijn advies dan ook vooral is: Doe het goed, of doe het liever niet. Halfslachtige besluiten gaan je niet geven waar je naartoe wilt.
Is er dan helemaal geen tussenweg? Het antwoord is ‘nee!’. Maar daarom spreken we ook over ‘transformeren’. Door goed te weten waar je naar toe wilt ontwikkelen kun je stapsgewijs transformeren naar de optimale setting. Dit kun je zeker in een aantal fases uitsmeren. Om zo de inzichten van de eerste fases ook weer te gebruiken voor de volgende stap. Wees je er echter bewust van dat iedere keuze een consequentie heeft en dat het niet maken van keuzes vaak meer ellende oplevert.
Tip: loop niet achter de succeverhalen van andere organisaties aan, maar ga kijken wat Agile werken voor jouw organisatie kan betekenen, wat wil je ermee bereiken?En onderzoek welke methode goed bij jullie organisatie past!
De eerste vraag die je van mij kan verwachten is vrij overzichtelijk: “Waarom wil je dit uberhaupt?” Want daar begint het allemaal. Niet bij de methode maar de toegevoegde waarde die het uiteindelijk voor de organisatie moet brengen!