Agile werken draait om rendementsturing en waardelevering. De praktijk laat zien dat de meeste organisaties die agile oppakken net dat het lastigst vinden. Want hoe meet je de waarde van kleine stapjes? Hoe meet je waarde sowieso? En is het eigenlijk nog zinvol om waarde van tevoren in te schatten en achteraf te meten? En wat is de impact van het denken in waardeketens? Dat zijn dagelijkse vragen waar je mee worstelt als je agile gaat werken. Welke rol kun je daar als controller in spelen? En waarom is de agile mindset extra lastig voor de controller?
Iedere controller krijgt vroeg of laat te maken met toenemende snelheid en grotere complexiteit. Het is niet de vraag of dit gaat gebeuren, maar wanneer. En daarnaast hoe
groot en voelbaar dit wordt, zodat het niet langer valt te negeren. De stap naar agile is dan snel gemaakt. Agile is namelijk de manier van werken die bijzonder goed om kan gaan met dynamiek en onvoorspelbaarheid. Het is aan u om te bepalen hoe u hier mee omgaat. Grofweg zijn er vier manieren om met agile aan de slag te gaan, zie figuur 1.
Proactief met agile aan de gang | De gids | De ontdekkingsreiziger |
Reactief met agile aan de gang | De hulpverlener | De toerist |
Anderen helpen agile te werken | Zelf agile gaan werken |
Figuur 1. Vier keer agile werken
De hulpverlener (reactieve helper)
Veel controllers worden als vanzelf in de reactieve houding gedwongen, doordat de agile transformatie in de organisatie van start gaat en doordendert. Meestal op afstand, zonder er zelf bij betrokken te worden. Doordat er vanuit de agile-teams geen belang is om business controllers er direct bij te betrekken, vindt de transformatie aanvankelijk low profile plaats. Ook is er nog weinig geld mee gemoeid. De controller vindt het wel best.
Maar vroeg of laat komt er een moment dat men zaken gaat vragen, bijvoorbeeld op het gebied van budgetten en het vastleggen van kosten en investeringen. Kan uren schrijven niet beter worden afgeschaft in stabiele agile teams?
Of waarom hebben we projectbudgetten als het uiteindelijk toch weer op een grote hoop wordt gegooid? In veel gevallen gaat dan inmiddels veel geld om in de agile-teams en zijn de belangen groot. Op dat moment komt de controller als reactieve helper in actie om een aantal zaken te gaan fixen. Het aanpassen van de governance en het inrichten van een procesmatig en financieel pad voor agile werken, is dan meestal een eerste stap.
De gids (pro-actieve helper)
Soms is het handiger om vanaf het begin een proactieve houding aan te nemen. Agile werken heeft alles te maken met nieuwe, uitdagende doelen van de organisatie en het is de natuurlijke rol van de controller om faciliterend te zijn bij het bereiken van deze doelen. Uiteindelijk is het snel leveren van businesswaarde een gedeeld doel.
Dit betekent dus dat de controller zich vanaf het begin positief opstelt en op zoek gaat naar manieren om te helpen. Bijvoorbeeld door in gesprek te gaan met product of business owners. Hen vragen wat hun belangrijkste doelen zijn en concreet hulp aanbieden om deze te helpen realiseren. Helpen met het meten van waarde en berekeningen maken om backlogs te ordenen op rendement.
Omdat de collega’s in deze agile rollen die hulp niet uit zichzelf gaan vragen bij de business controller, is het zaak snel te laten zien waar de persoonlijke toegevoegde waarde zit. Als de business controller hierin slaagt, zal diens positie in de toekomst duidelijk verstevigd zijn.
De toerist (reactieve toepasser)
Een bekende discussie in het kader van agile werken en controlling is in hoeverre de controller zelf agile moet werken. Je kan als controller op het moment dat je – op verzoek – wordt aangehaakt het roer omgooien en jezelf (ook) laten omscholen. De trainingen voor alle direct betrokkenen zijn inmiddels al wel gegeven, maar dat kan je wel inhalen. Voordeel van zelf ook de taal leren spreken, is dat er meer wederzijds begrip ontstaat en dat je als controller in de toekomst ook beter in staat zult zijn snel in te spelen op alle veranderingen die nog gaan komen.
Het nut van ook echt zelf agile gaan werken binnen controlling zal van geval tot geval verschillen. In ieder geval leg je een basis om in de toekomst niet alleen een ondersteunende rol te spelen, maar ook de taal van de ander te spreken en in het vervolg van de agile transformatie te kunnen helpen bij het maken van lastige keuzes. Want dergelijke keuzes komen er gegarandeerd.
De ontdekkingsreiziger (proactieve toepasser)
De meest proactieve en betrokken vorm is om al in een vroeg stadium als controller betrokken te raken en zo snel mogelijk ook zelf ‘agile te worden’. De controller wordt dan onderdeel van de agile transformatie. Echt als deelnemer of zelfs als trekker. Door de natuurlijke rol van de controller als kritische partner en adviseur kan dit veel meerwaarde opleveren. Het pad van de transformatie naar agile werken is namelijk glibberig en onzeker.
Het kan zeker geen kwaad als er kritische teamleden meedoen aan deze expeditie die met een onafhankelijke blik de voortgang bewaken. En dit vanuit een positieve, bouwende en betrokken houding. En hoe kan dat beter dan ook zelf, samen met de anderen in de organisatie, te gaan ervaren hoe het is om agile te werken? Op deze manier zal je veel beter in staat zijn om de (beoogde) voordelen van agile te ontdekken, ze te versterken en te helpen om de ervaren nadelen het hoofd te bieden.
Lees ook: Meer grip op investeringen met scrum
Waarom is agile extra lastig voor de controller?
De praktijk laat zien dat agile lastig is om te leren, maar juist extra lastig voor controllers. Dat komt niet doordat ze wars zijn van verandering of niet open zouden staan voor nieuwe ideeën. Integendeel. Kijkend naar het (gewenste) competentieprofiel van de gemiddelde controller is dat onder meer resultaatgerichtheid, flexibel, klantgerichtheid en organisatiesensitief. Dit sluit mooi aan bij agile werken. Maar toch is het extra lastig doordat agile werken de business controller vraagt nu juist dátgene los te laten waar controllers heel goed in zijn.
Agile werken past namelijk uitstekend bij complex werk: kleine stapjes zetten en leren door te doen (zie kader Stacey-matrix). Complexiteit is onvoorspelbaar en verandergevoelig. Dan lukt het niet om alles voorspelbaar te maken en via procedures dicht te timmeren. Helder maken waar je ongeveer heen wilt en dan de eerste stap zetten, werkt wel. Het lef hebben om die eerste stap te zetten en er op vertrouwen dat je de tweede stap pas gaat ontdekken tijdens die eerste stap. Dat is de essentie van agile.
De business controller is echter van nature juist heel goed in het voorspelbare domein (‘gecompliceerd’ zie Stacey-matrix). Goed in het maken van haalbare plannen, goed in analyseren, goed in het vooraf helder krijgen van eisen en verplichtingen en op basis daarvan een haalbaar plan maken. Veel werk in het domein van de business controller is herhaalbaar. Je doet het vaak en doorlopend en wordt er zodoende steeds beter in.
STACEY-MATRIX

Figuur 2. Stacey-matrix
De Stacey-matrix (figuur 2) laat zien dat er verschillende vormen van werk zijn: simpel, gecompliceerd, complex en chaotisch. Deze vier typen komen voort uit de mate van zekerheid over het wat en het hoe. Is het wat en hoe heel duidelijk en het verband ertussen altijd aanwezig, dan gaat het om simpel werk. Gecompliceerd wordt al onduidelijker, maar met goede analyse en gebruik van expertise is het werk haalbaar en voorspelbaar te maken. Gecompliceerd past bij de business controller.
Worden het wat en hoe nog onduidelijker, dan spreekt het model van complex werk. Complex is vooraf maar beperkt voorspelbaar en planbaar. Dingen gaan namelijk altijd anders dan verwacht. Bij complex past dan ook om kleine stapjes te zetten en daar van te leren. Complex is achteraf wel verklaarbaar maar vooraf nauwelijks voorspelbaar. Hier past agile heel goed bij. Tot slot chaotisch, daar is wat en hoe volstrekt onduidelijk en niet helder gerelateerd. Bij chaos spreken we dan ook vaak in termen van geluk of pech. Zowel vooraf als achteraf totaal niet voorspelbaar of verklaarbaar.
Daarom is agile extra lastig voor de business controller: datgene waar hij van nature heel goed in is, past eigenlijk niet bij het complexe domein. Agile werken vraagt daardoor veel van een business controller. Namelijk dat hij niet langer leunt op de eigen kwaliteiten maar juist onzekerheid leert omarmen en vertrouwen leert krijgen in het nemen van stappen zónder dat vooraf helder is of het gaat lukken.
Al snel ontstaat ook een emotioneel conflict: fouten maken is bij agile namelijk heel goed omdat het inzichten biedt en hoort bij het leren door te doen. Echter, de controller voelt zich daar niet in thuis. Sterker nog, de controller is een kei in het voorkomen van fouten en ziet een fout als (persoonlijk) falen. Want in het gecompliceerde domein is een fout een teken van slechte voorbereiding of slordige analyse waarover gerapporteerd moet worden.
Agile werken vraagt dus om een behoorlijke persoonlijke mindshift en vraagt van de controller om niet te doen waar deze juist heel erg goed in is. Ga er maar aan staan. Dit betekent dus concreet dat er extra aandacht nodig zal zijn voor de selectie en ontwikkeling van de agile controller van de toekomst.
Dit artikel is verschenen in cm: 2018, afl. 10, geactualiseerd op 7 februari 2022
Auteurs: Eelko Plomp en Rini van Solingen
Eelko Plomp (RC) is Certified SAFe 4 Agilist en business consultant bij Eiffel en Rini van Solingen is cto bij Prowareness We-On en deeltijdhoogleraar aan de TU Delft.
Illustraties: Emanuel/Bagilla
cm: op Linkedin
Volgt u cm: al op Linkedin? Zo blijft u nog meer op de hoogte van de nieuwste updates en heeft u de kans om op artikelen te reageren. Zo blijven wij ook bij cm: op de hoogte van onze lezers en kunnen wij meer op de wensen inspelen.