EPIC Heatmap: Effectief risicogestuurd werken in een SAFe-programma

EPIC Heatmap: Effectief risicogestuurd werken in een SAFe-programma

De aankomende Omgevingswet, die 26 wetten over de openbare ruimte bundelt, wordt ondersteund door een nog te ontwikkelen digitaal stelsel (DSO). Dit DSO is de digitale basis voor het maken van omgevingsplannen, het verstrekken van vergunningen en ontsluiten van geo-informatie. En dat op landelijk, provinciaal, gemeentelijk en waterschapsniveau. Kortom: een flinke klus!

De omvang, complexiteit, bestuurlijke en juridische component maakt dat een standaard Prince2, MSP of Agile aanpak niet volstaat als governance. Daarom is gekozen voor SAFe. Maar hoe stuur je effectief op risico's binnen een SAFe-omgeving in de context van een interbestuurlijk programma? Dat blijkt een pittige opgave. Uiteindelijk is de EPIC heatmap ontwikkeld en deze wordt naar tevredenheid toegepast. Dit product zorgt voor een lichtgewicht kijk op risico's die elke twee weken actueel is. Het geeft directe stuurinformatie aan het management, brengt impact van projectrisico's op programmadoelstellingen in beeld en de communicatie over onzekerheden wordt bevorderd. In de volgende hoofdstukken is de methode verder uitgewerkt.

Inleiding
De EPIC heatmap maakt Agile-methoden als SAFe beter toepasbaar op grote programma's.

Complexe IT-programma's bevatten grote onzekerheden op het gebied van besluitvorming, gebruikerswensen, raakvlakken techniek, governance en juridische impact. Door de dynamiek en vele stakeholders is grote afstand tussen de productontwikkeling en de veranderopgave. Bestaande Agile-methoden zijn onvoldoende toegerust om de impact te overzien van onzekerheden in de Release Train op Programmaniveau en omgekeerd.

De EPIC heatmap is een praktisch toepasbaar, visueel instrument, dat door middel van zes eenvoudige stappen inzicht geeft in de kritische onderdelen uit het Agile ontwikkelproces binnen een complex (IT-)project of programma. De EPIC heatmap vergroot op eenvoudige wijze de beheersbaarheid en tijdige sturing op het programma en draagt hiermee bij aan grip op de risico’ s en behalen van de beoogde doelstellingen.

Huidige praktijk
Complexe IT-programma's bevatten grote onzekerheden en de bestaande methodes zijn niet voldoende in staat om de impact van onzekerheden in de Release Train op Programmaniveau en omgekeerd in zicht te hebben. Hierdoor kan er onvoldoende effectief op gestuurd kan worden.

Een oorzaak is de omvang van het programma in combinatie met complexiteit: Scope, bouw en veranderprocessen zijn in elkaar grijpende processen die zich ontwikkelen tijdens het verloop van het programma. Bij omvangrijke programma's is de afstand tussen de Agile Release Train en veranderopgaven relatief groot. Hierdoor is de relatie tussen onzekerheden in de haalbaarheid van gepland werk en de impact op het programma als geheel lastig te overzien. Daarnaast zijn gebruikerswensen vaak niet eenduidig omdat het geen product is dat wordt opgeleverd, maar een hulpmiddel bij een veranderopgave die vaak onderdeel is van verschuivende (politieke) belangen.

Daarnaast is risicomanagement in Agile methoden zoals SAFe vooral onderdeel van de Release Train en is gericht op het maken van het product. De kortcyclische manier van werken wordt daarbij gezien als een goede manier van omgaan met onzekerheden. Immers, mocht iets niet goed gedaan zijn, dan ben je maximaal 1 increment kwijt.

Programmamanagement-methoden zoals MSP van Axelos hanteren wel een bredere rol voor omgaan met risico's en bijvoorbeeld expliciet maken van stakeholderbelangen, maar de rapportage-gerichte aanpak hiervan sluit in de praktijk op product-niveau onvoldoende aan bij de waarde-gedreven aanpak van bijvoorbeeld SAFe.

Ten slotte is bij IT-gerelateerde programma's bij overheden of grote bedrijven op opdrachtgevers en politiek niveau sprake van een waterval-achtige aanpak. De globale eisen worden vooraf uitonderhandeld, op basis daarvan stellen partijen budget beschikbaar en worden mijlpalen vastgezet. Dit botst per definitie met de Agile-benadering die voor het halen van de opgave óf scope, óf tijd óf beschikbare middelen als variabele ziet.

Visie / oplossing

De EPIC heatmap is een visueel aantrekkelijk dashboard, bedoeld om effectief te kunnen sturen op onderdelen uit het Agile ontwikkelproces die kritisch zijn voor het Programma als geheel. Het is hiermee een handzaam middel om methoden als SAFe en MSP beter toepasbaar te maken voor grote IT-programma's.

Voor de aanpak zijn grofweg 6 stappen te onderscheiden.

Stap 1: Doelstelling
Programmamijlpalen in de nabije toekomst zijn een belangrijk richtpunt voor de prioritering van het realiseren van de Program-backlog. Een veel gebruikte werkwijze is om het werk gedetailleerd te plannen/sizen per increment, grover voor een jaar vooruit en op hoofdlijnen tot het eind van het programma zodat raakvlakken met andere processen en doelstellingen van stakeholders in zicht is.

Voor effectief gebruik van de EPIC heatmap is het van belang dat complexiteit in de nabije toekomst te overzien is. Als het vervolg echt nog alle kanten op kan, heeft het weinig zin om een gestructureerde aanpak te kiezen. In dat geval is een aanpak van "probing" meer van toepassing. Daarin wordt op basis van de beschikbare informatie een richting gekozen en wordt op basis van die uitkomst beoordeeld of het de juiste weg is. Deze aanpak valt hier buiten beschouwing.

Bij een SAFe-aanpak volgens incrementen is een kwartaal een goed richtpunt. PI-objectives of belangrijke besluitvorming die afhangen van het succes van het komende increment worden meegenomen in de analyse.

Stap 2: Roadmap
Basis voor elk goed lopend Programma is een overzichtelijke roadmap. Vorm en omvang zijn maatwerk en verschillen per Programma, doelgroep en fase. Kenmerkende onderdelen zijn:
● Maximaal 25 stappen of processen gerelateerd aan de doelstellingen
● Verschillende sporen of disciplines en afhankelijkheden gezamenlijk in beeld
● Denk bij disciplines aan techniek, proces, besluitvorming en extern: politiek/governance/wetgeving/juridisch

Stap 3: Kritische Processen
Bij een EPIC heatmap als onderdeel van de Agile Releasetrain worden tijdens de Programa Increment Planning de highlights van het komende increment in kaart gebracht. Wat wordt er opgeleverd? Dit zijn vaak Features die gebundeld zijn per Epic of gekoppeld aan een Capability. 10 tot maximaal 25 onderdelen zouden te onderscheiden moeten zijn om een balans te vinden tussen diepgang en overzicht.

De eerste vraag die wordt gesteld: "Hoe zeker schat je de haalbaarheid van dit onderdeel"?
Haalbaarheid hangt af van veel factoren. Denk aan:
● budget
● beschikbare capaciteit
● afhankelijkheden binnen of buiten het team
● helderheid Definition of Done

Het begrip haalbaarheid is niet zwart-wit in de Agile wereld. Het kan best zijn dat niet alle (stretched)goals en commited features gehaald worden en je toch kan zeggen dat een onderdeel succesvol is afgerond. Inschatting op basis van de expertise van de Product Owner of het team is hier van belang.

Met behulp van Post-its worden deze onderdelen -bij voorkeur door de Product Owner- op de horizontale balk van de heatmap geplakt. Rechts is "zeer haalbaar". Links is "zeer onzeker".

De tweede vraag luidt: "áls het onderdeel onverhoopt niet succesvol wordt afgerond in dit increment, wat is dan de impact voor het vervolg of het Programma als geheel?"
Bij grote impact kun je denken aan:
● Een essentieel onderdeel loopt vertraging op
● Vertraging in de besluitvorming op Programmaniveau
● Een impedement met sneeuwbaleffect in het volgende increment

De post-its worden nu op de verticale as verschoven. Bovenaan is "zeer grote impact". Onderaan is "geringe impact".

Na deze stap zijn de onderdelen die onzeker zijn en met grote impact als kritisch aan te merken. Dit zijn er in de regel 5 a 7.

Bij onderdelen die onzeker zijn zonder impact zou de product owner nog eens naar de planning kunnen kijken en wellicht vooraf al zeggen dat een onderdeel doorgeschoven wordt.

Met zekere onderdelen met grote impact wordt in eerste instantie niks gedaan. Pas bij de update luidt de vraag: Is de haalbaarheid nog steeds groot?

Zekere onderdelen zonder grote impact zijn business-as-usual en worden verder niet beschouwd door de EPIC heatmap.

Stap 4: Analyse Kritische Processen
Bij de kritische onderdelen schrijft het team:
1. De (belangrijkste) oorzaken van de onzekerheid
2. De impact op het programma mocht het onderdeel niet succesvol afgerond kunnen worden in dit increment

Stap 5: Actieplan
Onzekerheden zijn een normaal onderdeel van het werk van professionals. Het kan dus best zijn dat de onzekerheid acceptabel is. Omdat het een kritisch onderdeel betreft, is het wel van belang om dit expliciet uit te spreken. Aansluitend bij de SAFe-methode wordt een risico gecategoriseerd als volgt:
● "Resolved" – Het risico is voldoende beheerst
● "Owned" – Het risico kan niet ter plekke worden gemitigeerd, dus iemand neemt het risico op zich om later uit te werken.
● "Accepted" – Risico's die geaccepteerd (moeten) worden omdat beheersing niet mogelijk of wenselijk is, of omdat het risico onderdeel van het dagelijks werk is.
● "Mitigated" – Teams bedenken een beheersplan ter plekke

Indien er wel maatregelen genomen moeten worden om de haalbaarheid te verbeteren, is het SMART omschrijven van belang:
● Wat moet er gebeuren?
● Wie is daarvoor verantwoordelijk? Eigen team? Of besluitvorming op Programma, Opdrachtgevers of Stakeholdersniveau?
● Urgentie: Wanneer moet het duidelijk zijn?

Stap 6: Update
De grote kracht van de EPIC heatmap is dat hij zonder veel rapportagewerk actueel te maken is. Na elke sprint brengen de productowners van de kritische onderdelen een update aan: Is het onderdeel zekerder of onzekerder geworden? Of zijn er veranderingen in de impact? Door de Post-its te verhangen en de verandering bij te houden, is het overzicht altijd up to date en kan het management tijdig zien of er gestuurd of geëscaleerd moet worden.

Toepasbaarheid binnen SAFe
Stap 1 en 2 is het in kaart brengen van PI-objectives en de beschikbare roadmap
Stap 3 bepalen kritische onderdelen gebeurt tijdens de PI-planning.
Stap 4 en 5 analyse en bepaling actie gebeurt eveneens tijdens de PI-planning.
Stap 6 is onderdeel van de PO-sync.

Het toepassen van de EPIC heatmap maakt onzekerheden een normaal en expliciet onderdeel van een IT-programma. Doordat de werkprocessen centraal staan, is het eenvoudig op te nemen in de bestaande manier van werken en ontstaat op een natuurlijk manier het gesprek over de oorzaak, impact en beheersbaarheid van onzekerheden tussen product-team en senior user, zodat de kritische onzekerheden in beeld zijn en indien nodig tijdig gestuurd kan worden.