Anders rapporteren in Agile softwareontwikkeling om grip en controle te houden
In de software bieden resultaten uit het verleden geen garantie voor de toekomst. Iedereen kent voorbeelden van softwareontwikkelingen die na zoveel jaar zonder resultaat worden gestopt. Controlemechanismen worden daarom op elk niveau ingericht. Een belangrijk maar vaak vergeten aspect bij controle is: hoe rapporteer je wanneer met Agile Werken software wordt ontwikkeld? Belangrijk omdat vrijwel alle software met een vorm van Agile Werken wordt ontwikkeld: Scrum, DevOps, SAFe etc. Bij Agile Werken is een ander ritme en zijn andere meetinstrumenten nodig om grip en controle te houden op softwareontwikkeling.
Wat is Agile werken?
Agile Werken gaat uit van sprints, waarin steeds stukjes software worden gebouwd. Het einde van de sprint is een presentatie van de gebouwde software aan de product owner. De product owner vertegenwoordigt de business. Op basis van het opgeleverde werk, inzichten en nieuwe wensen wordt afgesproken wat de komende sprint(s) wordt gebouwd. Aan de hand van gebruikerswensen (ook wel user stories genoemd), geeft de product owner opdracht. De product owner is bij Agile werken verantwoordelijk voor grip en controle op het product.
Dashboard van Agile meetinstrumenten
Grip en controle van de product owner is geen garantie. Geen garantie voor een kwalitatief goed product in het juiste tempo. Hiervoor is het belangrijk om ook Agile metrieken te gebruiken in een dashboard. In Agile werken zijn de afgelopen jaren veel meetinstrumenten als best practices beschreven die inzicht geven in het Agile Werken van diverse teams. Inzicht is er alleen wanneer er een eenduidige (programma) backlog is. De backlog is de plek waar alle gebruikerswensen worden uitgeschreven en geprioriteerd.
Dashboard van Agile meetinstrumenten
Grip en controle van de product owner is geen garantie. Geen garantie voor een kwalitatief goed product in het juiste tempo. Hiervoor is het belangrijk om ook Agile metrieken te gebruiken in een dashboard. In Agile werken zijn de afgelopen jaren veel meetinstrumenten als best practices beschreven die inzicht geven in het Agile Werken van diverse teams. Inzicht is er alleen wanneer er een eenduidige (programma) backlog is. De backlog is de plek waar alle gebruikerswensen worden uitgeschreven en geprioriteerd.
Voorbeeld van Agile meetinstrument: sprint focus
Onderstaande illustratie toont het meetinstrument Sprint Focus:
Deze metriek laat op sprintniveau de focus van alle teams zien. De blauwe balken geven de user stories aan waar gewerkt is aan business waarde. In de eerste sprint besteedde de teams nog ruim 80% van hun tijd aan werken aan business waarde, maar dit neemt af in sprint 2 en 3. De oranje balk groeit daarentegen. Dit geeft aan dat de teams meer tijd zijn gaan besteden aan technische aspecten van de software. Dit levert niet direct business waarde op, maar is soms belangrijk voor efficiëntie op de langere termijn. Het is belangrijk dat de stakeholders onderzoeken of het echt noodzakelijk is dat zo’n groot percentage van het werk aan de technische functionaliteit wordt besteed. Werken aan zoveel mogelijk business waarde is namelijk het primaire doel. Het bespreken van de metriek van de Sprint Focus ondersteunt het gesprek om grip en controle te krijgen én houden op teamoverstijgend niveau.
Grip en controle door actief gebruik dashboard
Een dashboard inrichten is een goede eerste stap, maar nog niet genoeg. Meten is niet perse weten. Weten is wel: Praten over wat de cijfers zeggen over de gebouwde software. Pas wanneer de product owner het dashboard gebruikt in zijn bespreking met stakeholders (opdrachtgevers, controllers, persvoorlichters etc.), is er grip en controle op software ontwikkeling. Het voorbeeld sprint focus laat zien dat er meer te sturen valt in Agile Werken, dan alleen te kijken welk stukje software de afgelopen twee weken is gebouwd. Gebruik dit en andere meetinstrumenten in een dashboard om grip en controle te hebben in Agile software-ontwikkeling.
