Agile lukt niet. Wat nu?

Veel organisaties zeggen agile te werken en te scrummen, terwijl de praktijk soms toch anders is. Werkt agile dan gewoon niet? Doen ze het niet goed? Wat zijn tips om agile werken tot een groot succes te maken?

Ik sloeg het boek ‘Agile with a smile’ (aff.) open, zag de opzet en had direct een flashback naar De Kleine Prince2 (aff.) met daarin een sprookje over een prins, geschreven door Ronald Giphart. ‘Agile with a smile’ is geen sprookje: het is eerder een soap. We volgen het verhaal van Bob de manager, die agile bij zijn verzekeraar heeft geïntroduceerd, maar nu worstelt met de implementatie én de gevolgen daarvan.

Bob’s intentie start goed. Hij ziet dat het werkproces van zijn marketingafdeling lang is en veel stappen kent. Ook ziet hij dat de verschillende partijen en zelfs teamleden allemaal hun eigen belang hebben en nauwelijks de samenwerking opzoeken. De designer is een ongeleid projectiel en sales is alleen geïnteresseerd in hoeveel geld een campagne uiteindelijk oplevert. Daarom besluit Bob agile werken te introduceren. De schrijvers melden hierbij cynisch dat Bob’s agile cursus niet te veel tijd van hem vraagt – de training duurt maar een dag. En daar begint dan ook meteen het gedonder.

Problemen bij agile werken

Bob’s organisatie loopt tegen het volgende aan bij de invoer van agile werken:

1. De nieuwe aanpak vraagt niet alleen om een andere werkwijze, maar ook om ander gedrag en een aanpassing en de cultuur.
2. Vroeger liepen projecten vaak uit. Nu komen er steeds nieuwe sprints bij. Is dat niet hetzelfde als uitlopen? Als manager mist Bob hier het overzicht van.
3. De chief marketing officer (CMO) is product owner (PO) geworden en heeft het enorm druk. Hij heeft maar weinig tijd om bij de teams betrokken te zijn en te prioriteren.
4. De teams sturen zichzelf, worden daar steeds enthousiaster over en werken – zeker bij afwezigheid van de PO – naar eigen inzicht.
5. Teams wisselen onderling geen kennis en ervaring uit.
6. Sommige teams blijven moeite houden met zelfsturing. Ze vinden poker een spelletje en moeten door de scrummaster worden aangespoord om hun werk te doen.
7. Compliance is boos. Er is geen inzicht in correct gebruik van klantdata, omdat dit niet meer wordt gedocumenteerd.
8. Bij retrospectives worden steeds dezelfde issues aangekaart, maar niemand lost ze op.
9. Ondanks de definition of done worden zaken opgeleverd die niet af of niet getest zijn.
10. Er is geen zicht meer op het hele portfolio, teams denken alleen aan hun eigen belang.

Door dit alles is enerzijds de kwaliteit van de opgeleverde producten onvoldoende en zakt anderzijds de energie weg en neemt het geloof in ‘de methode’ af.

Hulp is onderweg

Gelukkig treft Bob – langs het voetbalveld van zijn zoontje – Charles, een IT-manager die graag wat bijschnabbelt en Bob van advies voorziet. Zijn belangrijkste adviezen:

1. Kennis en begeleiding

Teams kunnen niet uit het niets perfect scrummen. Daar hebben zij begeleiding en training voor nodig. De scrummasters kun je laten begeleiden door een agile coach. En besef dat PO de lastigste rol van allemaal is. Ook die heeft opleiding en begeleiding nodig. Al is het maar om hem te helpen goede user stories te formuleren. Kennis binnen en tussen teams kun je vergroten door vakgroepen in te zetten. Spotify noemt dat tribes en guilds.

2. Verbeteren na een retrospective

Beperk je bij een retrospective tot maximaal 3 verbeteracties. Zet deze op de backlog of zet ze op het teambord om te borgen dat het team er echt mee aan de slag gaat.

3. Sprinten volgens de regels

Houd je aan de tijd de voor een sprint staat. Laat hem nooit langer doorlopen. Maak duidelijk wat de hoogste prioriteit heeft en zorg dat het team dat als eerste oplevert. Komen stories vaak niet af? Maak ze dan structureel kleiner. Houd je aan de definition of done. Test zo vroeg mogelijk en borg het testen in de definition of done.

4. De rol van de product owner

De PO bepaalt de prioriteit, maar is geen alleenheerser. Hij bepaalt – binnen door het management/de organisatie/de strategie gestelde kaders wat er in welke volgorde moet worden gebouwd. Hij stemt met de verschillende bedrijfseenheden af wat belangrijk is (gewoon goed stakeholdermanagement dus…). Bovendien moet de PO de gebruiker vertegenwoordigen en de wensen van de gebruiker dus goed kennen. Hij moet voor het team goed bereikbaar zijn en snel face to face geraadpleegd kunnen worden. De PO is dus waarschijnlijk niet de CMO, maar een echte inhoudsdeskundige met stakeholdermanagementvaardigheden.

De PO bepaalt de prioriteit, maar is geen alleenheerser.

5. Voldoen aan compliance-regels

Is compliance ongerust? Dan heb je ze onvoldoende als stakeholder aangehaakt terwijl ze heel essentieel zijn.  Hoe pak je dit aan?

1. Laat compliance niet boos wijzen naar een hele boekenplank aan regels en wetten, maar laat hen werkinstructies maken voor het scrumteam inclusief wat expliciet moet worden gedocumenteerd.
2. Laat compliance per product aangeven welke eisen aan elk product worden gesteld en neem die eisen op in elke definition of done.
3. Zorg dat compliance werkzaamheden zijn benoemd als user stories.
4. Laat compliance je product mee beoordelen.

Mijn tip hierbij: Kijk en bevraag wel kritisch of alles wat compliance wil écht nodig is. Soms zijn ze toch te veel het braafste jongetje van de klas. Mijn ervaring is dat hoe eerder en intensiever je deze afdeling betrekt, hoe welwillender ze zijn om mee te helpen én kritisch naar hun eigen eisen te kijken.

6. Zicht en sturing op het hele portfolio

Agile werken betekent niet dat je portfolio-denken overboord moet gooien. Ook binnen scrum is het zaak te kijken naar technische, achtereenvolgende en capaciteitsafhankelijkheden. Hier zijn methoden voor als scrum-of-scrums, LeSS en SAFe. Charles ziet deze vraag van Bob overigens als een uitnodiging om een pleidooi te houden voor de combinatie van waterval Prince2 met Scrum.

Zijn dit aanpassingen aan agile werken?

De achterkaft van ‘Agile with a smile’ stelt dat ‘met een paar eenvoudige aanpassingen het agile werken veel successvoller kan zijn’ en ‘dat die aanpassingen komen uit de methoden die hij overboord had gezet’.

Ik ben enorm bang dat mensen met wat minder agile ervaring dit boek lezen en denken: “Zie je wel, die vrijheid-blijheid-mentaliteit van agile werkt dus helemaal niet. Goed dat er een stuk Prince2 bij wordt gegooid om de boel op te strakken.” En dat is natuurlijk pertinente nonsens. Bijna alle issues die Bob noemt, zijn geen zwakke punten van Scrum, maar laten zien dat scrum bij deze verzekeraar helemaal niet op de juiste manier wordt toegepast. Een dagje training, sprints die verlengd worden, retrospectives waar niets met de uitkomsten wordt gedaan, teams die geen kennis willen delen, PO’s die te druk zijn om in nauw contact met hun teams staan en op eigen houtje werken. En natuurlijk, ook ik zie dit soort dingen regelmatig in organisaties. Maar dit zijn allemaal voorbeelden van het niet goed uitvoeren van het scrum-raamwerk.

Prince2 als hulpmiddel bij agile werken?

De auteurs hebben alledrie een hart voor de projectmanagementmethode Prince2. Ze leggen terecht uit dat ook deze methode vaak in de praktijk verkeerd gebruikt wordt (namelijk veel te rigide). Vervolgens bepleiten zij dat als je grote veranderingen wil doorvoeren, het het beste is om daarvoor een project in te richten. Dat via Prince2, of eventueel de speciale agile variant daarvan bestuurd kan worden. De vraag is of een project hiervoor de heilige graal is. Agile werken kent allerlei manieren om in zogenaamde release trains of value streams op grotere schaal te werken aan een verandering. Hier zijn vele succesverhalen van bekend, waar geen projectgroepen en stuurgroepen voor nodig waren.

Controle op teams houden

De auteurs van Agile with a Smile pleiten ervoor om de burn-up grafiek in te zetten als middel om de voortgang van een team in de smiezen te kunnen houden. De burn-down grafiek laat zien hoeveel werk er is uitgevoerd en hoe snel dat gaat, uitgedrukt in story points. De burn-up grafiek laat zien hoeveel werk er nog uitgevoerd moet worden. Dit wordt berekend op basis van het aantal opgetelde story points van alles op de backlog. Dat wordt dan gezien als de scope.

Ik krijg hier persoonlijk jeuk van. Dit soort grafieken zijn hulpmiddelen voor het team zelf, zijn scrummaster en PO. Als je ze gebruikt om te sturen, controleren en verantwoorden (of zelfs afrekenen), dan ben je gewoon weer ouderwets aan het managen. En dat wordt onderstreept in het boek. Ik parafraseer manager Bob: “Hee, dit zijn maatregelen van projectbeheersing die al jaren bestaan en nu op een nieuwe manier worden toegepast!” Als Bob hierop stuurt, zal het team voor je het weet zijn intrinsieke motivatie verliezen en weer braaf doen wat hun manager hen opdraagt.

De worsteling van de midden-manager

De auteurs maken in hun boek duidelijk hoe Bob worstelt met het verliezen van de controle. Vroeger was dat zijn rol: precies weten wat zijn team deed en de laag boven hem daarover keurig informeren. Met de komst van scrum verandert dat. Als Bob te veel statusupdates aan het team vraagt, voelen zij zich gecontroleerd. En wat de PO goedkeurt, daar heeft Bob helemaal geen zicht meer op. Enerzijds komt dat doordat we al constateerden dat de PO zijn rol niet correct oppakt en het team te veel vrijheid krijgt in het bepalen wat het oppakt. Het is begrijpelijk dat Bob zich zorgen maakt, zeker als de kwaliteit van de producten onder de maat is.

Anderzijds, als scrum werkelijk goed geïmplementeerd was bij deze verzekeraar, zou Bob waarschijnlijk nog steeds die behoefte aan controle hebben. Terwijl dat dan juist contraproductief zou werken. De ontwikkeluitdaging van Bob is om de agile waarden zelf daadwerkelijk te omarmen en deze vervolgens over te brengen aan zijn mensen. Vertrouwen te hebben in de teams, en hen te leren dat het gaat om moed, openheid, focus, betrokkenheid, respect.

Er zijn stromingen die zeggen dat de midden-manager ten dode is opgeschreven. Maar als er één laag is in een organisatie die snel kan schakelen en bij veranderingen het verschil kan maken, dan is dat deze middenlaag. Meer weten over die waarden? Ik heb er eerder dit artikel over geschreven.

Vermakelijk, anekdotisch, vol tips

Ik had goede hoop toen ik de beschrijving van het boek las. Ik herken zeker dat bedrijven die nog niet volledig agile werken moeite hebben met agile. En ik hoopte oprecht dat hier wijzigingen in het scrumraamwerk en agile werken gesuggereerd werden die daadwerkelijk helpen. Denk aan dingen als: hoe ga je om met een PO die onvoldoende mandaat krijgt?

Wat als mensen niet volledig mogen scrummen? Hoe ga je om met de beperkingen van afdelingsgrenzen als een waardestroom daar dwars doorheen loopt? In dit boek gaat het echter niet om verbeteringen van agile principes, maar om agile principes die gewoon niet goed worden uitgevoerd. Dus het sluit niet aan op mijn verwachtingen en geeft geen antwoord op de vragen waar vele organisaties mee worstelen.

Daarnaast ergerde ik me af en toe aan het feit dat de stijl regelmatig wisselt van verleden tijd naar tegenwoordige tijd en weer terug op een voor mij onlogische manier.

Maar bevind jij je in een organisatie die zegt agile te werken en heb je het idee dat de juiste ‘regels’ niet gevolg worden? Dan kan dit een herkenbaar, vermakelijk en anekdotisch boekje zijn, vol praktische tips.

Over het boek

Titel: Agile with a smile
Auteur: Kotteman, Portman, Heideman
Uitgever: Van Duuren Management
Jaar: 2017
Nummer: 9789089653956
Mediatype: Boek, 126 bladzijdes
Prijs: €20,-
Bestellen: via Managementboek (aff.)