Begroten in een agile omgeving

We werken agile! Iedereen blij?

Voor steeds meer bedrijven is het agile (door)ontwikkelen van hun software de standaard aanpak geworden. De gebruikers vanuit de business zijn blij, omdat ze sneller gewenste veranderingen zien in de software. De ontwikkelaars zijn blij, omdat ze direct met de gebruikers in contact zijn en software maken die ook echt gebruikt wordt.

Voor de mensen uit de financiële rapportagelijnen (zoals budgethouders en controllers) ligt dit blije gevoel minder voor de hand. Hoe kunnen zij de beslissers overtuigen om budget vrij te maken voor agile projecten. Hoe zorgen ze ervoor dat de agile ontwikkelde software ook echt waarde gaat toevoegen aan de organisatie? En welke mogelijkheden hebben ze om te zorgen dat de gewenste waarde ook binnen het beschikbare budget wordt geleverd? Van een groot project kun je een business case maken, maar hoe doe je dat met tweewekelijkse releases, om maar niet te spreken van continuous deployment, waarbij iedere wijziging automatisch getest wordt en in productie wordt genomen? En welke waarde willen we meten van de software? Bij agile denken we vooral aan gebruikerswaarde, waarbij user stories met de meeste gebruikerswaarde - ten opzichte van de kosten om ze te realiseren - de hoogste prioriteit krijgen. Beslissers denken veelal in boekwaarde, waarbij vooral de kosten van het realiseren van de software een grote rol spelen.

Waar wringt de schoen?

De traditionele manier waarop organisaties met begroten omgaan, gaat vaak wringen met een agile aanpak. Afhankelijk van de mate waarin het agile gedachtengoed is doorgedrongen binnen een organisatie ontstaat er ergens een ‘torsiemoment’ tussen het agile gedachtengoed - gericht op het creëren van waarde - en de traditionele financiële verantwoording.

In de financiële verantwoording wordt de bedrijfsvoering in elementen opgedeeld die elk hun eigen kosten en opbrengsten hebben. Voor de besturing van de organisatie is het echter van belang om naar het totaal te kijken en de samenhang van de verschillende elementen niet uit het oog te verliezen. Als het torsiemoment te dicht bij de werkvloer komt, kan dit het succes van de agile aanpak kapot maken.
De impact van agile werken op de financiële organisatie is onderbelicht

Er is binnen het agile gedachtengoed maar weinig te vinden over de impact van agile werken op de financiële organisatie, terwijl iedere organisatie een financiële aansturing heeft. Dit ‘torsie­moment’ blijkt in de praktijk remmend te werken op de transformatie naar een echt wendbare organisatie.

Om succesvol te kunnen begroten is het van belang om duidelijk vast te stellen waar in de organisatie het torsiemoment ligt. In veel gevallen liggen de drijfveren, en daarmee ook de informatiebehoefte, aan beide zijden van het ‘torsiemoment’ anders. Aan de kant van de financiële sturing en verantwoording ligt de nadruk veelal op het aspect planning, terwijl aan de agile kant de nadruk veelal op de prioritering ligt. Hierdoor ontstaat aan de kant van de financiële verantwoording het idee dat die agile teams 'maar wat doen'. Aan de agile kant is er onbegrip over de vragen over efficiëntie, terwijl men bezig is zo effectief mogelijk nieuwe software te realiseren.

De balans tussen flexibiliteit en voorspelbaarheid

Eén van de hulpmiddelen die eenvoudig kan helpen om over het ‘torsiemoment’ heen de balans te vinden tussen flexibiliteit en voorspelbaarheid is de burn-up chart. Deze brengt de drijfveren van beide kanten samen. De totale backlog wordt afgezet tegen de tijd en samen met de al gerealiseerde velocity getoond. Hierdoor ontstaat een projectie op welk moment welk gedeelte (dus niet de exacte functionaliteit) van de backlog gereed kan zijn. Voor de kant van de financiële verantwoording is dit een planning hoeveel er opgeleverd kan gaan worden, terwijl het voor de agile kant een prioriteringsgrens is welke backlogitems er wel en niet binnen het project vallen. Zeker als de organisatie een laag torsiemoment heeft, is een burn-up chart een goed instrument om ook in de planmatige en budgetgedreven informatiebehoefte te voorzien naast de informatie­behoefte van agile teams aan inzicht in de hoeveel werk die nog in de backlog staat.

Meer weten? Lees het whitepaper.