Inleiding

In grote organisaties, waarin ICT een steeds crucialere rol vervult, worden vaak initiatieven genomen op het gebied van wendbaarheid. Men wil wendbaarder zijn in de manier waarop de producten en diensten aan de klanten wordt aangeboden. Sneller kunnen inspelen op wijzigingen in klantvraag, toepassen nieuwe technologie etc.

Vele boeken zijn hier al aan gewijd waarbij termen als VUCA (Volatile Uncertain Complexity Ambiguity) worden gehanteerd. Bij veel van die initiatieven bereikt men niet de gewenste situatie, ondanks alle wijsheid in frameworks als SAFe (scaledagileframework.com) of TOAH (toahframework.com).

In dit artikel wil ik duiden dat één van de mogelijke oorzaken daarvoor ligt op het gebied van prioriteren en sturen op datgene wat echt het belangrijkst is voor de organisatie.

De ontbrekende schakel zit hem vaak in het prioriteren op het hoogste niveau. Door dit niet of niet nadrukkelijk genoeg te doen verschuift het prioriterings-issue dieper in de organisatie. Dit veroorzaakt vaak een gebrek aan focus door met teveel dingen tegelijk bezig te zijn met een geringe flow tot gevolg. Terwijl juist flow nodig is bij al die initiatieven om de wendbaarheid te verbeteren.

Het kiezen wat de belangrijkste prioriteiten zijn in een organisatie is een vorm van richting geven en één van de sleutelrollen van leiderschap. Dit moet op alle lagen van de organisatie plaatsvinden, dus ook op het hoogste niveau waar de prioriteit wordt bepaald voor die thema’s die het meest belangrijk zijn , dan wel de meeste waarde leveren voor de strategie van dat moment.

Situatieschets

Veel grote organisaties, zowel in de publieke sector als de private sector, kennen een structuur waarin op het hoogste niveau een splitsing gemaakt wordt in de organisatie.

Dit kan een splitsing zijn op basis van:

• Producten, zoals
  • Cosmetica en Voedsel
  • Kleding en Schoeisel
• Klantgroepen, zoals
  • Retail en Wholesale
  • MKB en Particulieren

In dit artikel wil ik het 2 divisies noemen.

De afgelopen jaren hebben veel organisaties zich verder ontwikkeld volgens een waardestroomprincipe. Deze waardestromen (vaak aangeduid als ketens of value chains) zijn vaak virtuele of functionele samenwerkingsverbanden waarbinnen men zich richt op het zo goed mogelijk waarde leveren vanuit een klantperspectief.

In grote organisaties zie je vervolgens ketens ontstaan die zich op dezelfde klant- of productgroep richten maar vanuit een verschillend perspectief. Als je bijvoorbeeld een divisie Schoeisel hebt naast Kleding, kan het zijn dat je een keten hebt die zich richt op de bediening van sporters of mode. Dit zou je kunnen duiden als primaire of lead ketens.

Heel vaak zie je echter ook dat er meer generieke ketens worden ingericht. Denk hierbij bijvoorbeeld aan Klantkanalen of Gegevens. Alle lead ketens in alle divisies maken gebruik van dezelfde kanalen waarmee met de klant wordt gecommuniceerd. Dus één website, één app etc.

Hetzelfde geldt voor bijvoorbeeld gegevens. De gegevens vastlegging van klanten vindt op eenduidige wijze plaats voor zowel Kleding als Schoeisel klanten teneinde hier analyses op plaats te kunnen laten vinden.

Er is dus ook vaak sprake van secundaire of follow ketens.

In die virtuele georganiseerde ketens (zowel lead als follow) zijn uiteindelijk ook teams gekoppeld die de ICT verzorgen voor die ketens. Ook hierin zie je weer vaak een verdeling ontstaan bestaand uit teams en clusters van teams.

Ik wil in dit artikel wegblijven van specifieke framework terminologie maar heel vaak kom je hier termen als ART (Agile Release Train) en DevOps-team tegen. Ook hier vind je dus weer de situatie terug dat er teams en clusters van teams (trein) aan specifieke (keten-) producten werken of aan wat meer generieke (keten-) producten.

Een belangrijk aspect bij  teams, treinen en ketens is autonomie zodat er een betere flow kan ontstaan. Autonomie van bijvoorbeeld een team betekent dat het team volledig zelf verantwoordelijk kan zijn voor het product. Dit product is vaak een applicatie of een deel van een applicatie. Zeker als er een streven is om volgens DevOps principes te gaan werken is de noodzaak om zo autonoom mogelijk te werken een must.

In onze voorbeeld organisatie ontstaat dus het volgende beeld:

We onderscheiden dus 4 niveaus in de organisatie waar lijsten worden gehanteerd met activiteiten:

• Divisie niveau
• Keten niveau
• Trein (ART) niveau
• Team niveau

Deze lijsten worden meestal als backlogs aangeduid.

Twee belangrijke kenmerken van deze backlogs zijn:

1. De scope of het beschouwingsniveau
2. De noodzaak van prioriteren

Ten aanzien van beschouwingsniveau worden vaak de volgende termen gehanteerd voor de verschillende backlog items:

• Op divisie niveau een lijst van backlog items die vaak termen als strategische initiatieven worden genoemd.
  • Deze initiatieven vormen meestal een beperkte lijst omdat het gaat over wat voor de gehele organisatie of een divisie het meest belangrijk geacht wordt om de thans geldende strategie te implementeren. Dit zijn vaak onderwerpen die van top belang worden gezien en waar vaak meerdere jaren aan gaat worden gewerkt. Denk hierbij aan voorbeelden als ‘we willen voor sporters het meest toonaangevende merk zijn’ of ‘we willen door de klanten van onze kleding en schoeisel als het meest klantvriendelijke merk worden beschouwd’.
• Op keten niveau een lijst met backlog items die vaak aangeduid worden als epics. Een epic is een groepering van activiteiten die met elkaar een bijdrage leveren aan de divisie of de gehele organisatie en die vaak meerdere kwartalen in beslag neemt.
  • Denk hierbij aan zaken die elke keten gaat bijdragen aan het initiatief om het meest toonaangevende merk te worden. De keten topsport zal zich dus gaan richten op de markt van aansprekende sportclubs en topsporters die dit gaan uitdragen. De keten klantkanalen zal zich gaan richten op het opzetten en bedienen van alle kanalen die voor die specifieke groep relevant zijn.
  • Op keten niveau worden echter niet alleen epics benoemd die gekoppeld zijn aan strategische initiatieven. Dit kunnen ook initiatieven zijn die voor de specifieke keten heel belangrijk zijn vanuit hun eigen verantwoordelijkheid. Bijvoorbeeld de keten Gegevens kan aangeven dat er een vervanging van de bestaande klantadministratie moet komen waarmee meer wendbaarheid kan worden bereikt dan wel dat de bestaande applicatie technisch end-of-life is.
• Op trein niveau een lijst met backlog items die vaak aangeduid worden als features. Een feature is een groepering van activiteiten die vaak door meerdere teams in de trein gedurende een kwartaal kunnen worden gerealiseerd.
  • Denk hierbij aan zaken als dat de trein die in de keten Gegevens gekoppeld is aan de klantenadministratie een eisen en wensen pakket samenstelt waaraan een aanbod vanuit een marktpartij moet voldoen.
  • Of een trein in de keten klantkanalen heeft een eerste deel van hun YouTube kanaal gerealiseerd voor een specifieke sport.
• Op team niveau een lijst met backlogitems die vaak aangeduid worden als User-stories. Dit zijn activiteiten die met elkaar een deel van een feature realiseren dat binnen een sprint van 2 weken kan worden gerealiseerd door het team.

Ik hanteer hierbij begrippen als initiatieven, epics, features en stories die in veel grote organisaties herkenbaar zijn in het voortbrengingsproces van producten en diensten. Soms kiezen organisaties voor andere termen maar in dit artikel wil ik daar verder niet op in gaan.

Datzelfde geldt voor de ritmiek. Ik ga hier uit van een rolling forecast ritmiek waarin altijd meerder kwartalen (bijvoorbeeld 8) vooruit wordt gekeken in combinatie met een kwartaalritmiek voor de treinen en teams en een sprint ritmiek van 2 weken. Ook hierin kunnen organisaties afwijkende keuzes maken maar de door mij gehanteerde ritmiek is vrij algemeen toegepast.

Er ontstaat hiermee een gelaagdheid van backlogs die er in ons voorbeeld als volgt uit ziet:

Dit geeft een beeld van de complexiteit die er komt kijken in zo’n situatie met meerdere ketens, tientallen treinen en soms honderden agile teams. Complexiteit die vaak tot vele vormen van samenwerken leidt maar ook complexiteit waarin prioriteren helpt om een deel van de complexiteit te verminderen.

Prioriteren

In de hierboven beschreven situatie met backlogs op 4 niveaus is prioriteren een noodzakelijk proces om een goede flow tussen alle 4 de lagen te bereiken. Dit prioriteren moet er voor zorgdragen dat voor iedereen op elk moment duidelijk is wat de gekozen volgorde is van backlogitems waaraan gewerkt gaat worden. Verderop in dit artikel wordt geduid wat de consequenties zijn van niet prioriteren in alle lagen.

Dit vindt plaats op alle niveaus, vaak met een andere tijdshorizon als uitgangspunt (jaren, kwartalen, weken). Op het hoogste niveau houdt men zich bezig met de prioriteit van de activiteiten die invulling geven aan de strategie. Dat zijn vaak activiteiten met een langduriger realisatietijd.

Uiteindelijk gaat ook deze activiteit opgedeeld worden in kleinere eenheden waarbij een kwartaalritmiek een prima manier is om te definiëren wat het gewenste resultaat is aan het eind van het volgende kwartaal. Dit wordt vaak als OKR bestempeld, het Key Result dat je aan het einde van het volgende kwartaal op een bepaalde Objective bereikt wilt hebben.

Dit prioriteren is een proces dat zich dus in een kwartaalritmiek afspeelt maar is meer dan een gebeurtenis (event). Het is een proces dat zich in eerste instantie top-down voltrekt. Het begint met het vaststellen wat de prioriteit is van de meest belangrijke initiatieven van de organisatie. Het resultaat hiervan is dus een gepriotiseerde backlog van in eerste instantie initiatieven op organisatie niveau. Dit is dus niet een via MoSCoW (Must, Should, Could, Would) gerubriceerde set aan initiatieven (met vaak een veelheid aan Must-Do’s) maar echt een volgorderlijkheid met ‘dit is prio 1, dit is prio 2 etc’. Er is dus altijd maar 1 prio 1 op dat moment.

Dat betekent dat je er als organisatie wel voor moet zorgen dat alle componenten waarover geprioriteerd moet worden beschikbaar zijn. Dit zijn dus niet alleen de strategische activiteiten (of de politieke werkelijkheid in het publieke domein van dat moment) maar ook de activiteiten die voortkomen uit beheer en onderhoud. Ik vergelijk dit altijd met het onderhoud aan een auto. Iedere auto zal af en toe onderdelen moeten vervangen om probleemloos rijden te kunnen blijven garanderen. Er wordt daarmee geen nieuwe functionaliteit toegevoegd (de auto blijft gewoon een auto om mee te rijden) maar het niet doen van de vervanging leidt er toe dat functionaliteit niet meer beschikbaar is (de auto stopt er dan op een gegeven moment mee).

Door het prioriteren als een top-down proces te zien kun je regelen dat dit ook gebeurt. De backlogs op de lagere niveaus erven als het ware de prioriteit van het daarboven liggende niveau maar voegen daar wel hun eigen prioriteiten bij in.

Als bijvoorbeeld op het hoogste niveau van een bepaalde prioriteitsvolgorde van de initiatieven wordt uitgegaan, wordt dit besproken met de ketens die de backlogs op ketenniveau bijhouden. Een specifieke keten kan dan aangeven dat in hun keten een applicatie vervangen die aan het einde van de lifecycle zit, belangrijker is dan bijvoorbeeld een strategisch initiatief. Op keten niveau krijgt de gepriotiseerde backlog dus een volgordelijkheid waarin bijdragen aan strategische initiatieven en keten prioriteiten zijn gewogen.

Dit wordt dan in het prioriteitsproces teruggekoppeld aan degenen die de backlog van strategische initiatieven bijhouden. Men weet dan van elkaar dat het komende kwartaal de keten een backlog heeft die aan sommige strategische initiatieven minder prioriteit geeft dan aan een keten initiatief. Dit voorkomt misvattingen en maakt transparant welke keuzes er gemaakt zijn.

Dit zelfde geldt in het geval dat er in de organisatie wordt gewerkt met programma’s die invulling geven aan een strategisch initiatief. Dit programma gedraagt zich in het prioriteringsproces als stakeholder voor het strategisch initiatief. In de handshake met het top-down prioriteren bewaakt het dus of invulling wordt gegeven aan de programma doelstelingen in een bepaald kwartaal in de betrokken keten- trein- en team-backlogs.

Speciale aandacht verdient nog de backlog op trein en team niveau.

Dit is het moment waarop voor de agile teams, geclusterd in treinen, de verlanglijst de concreetheid krijgt van een boodschappenlijst. Men gaat zich dan committeren in het komende kwartaal om resultaten te leveren in lijn met de gepriotiseerde backlogs op keten niveau.

Dit doet men door de capaciteit die beschikbaar is vol te plannen met features en user-stories die een gedefinieerde bijdrage leveren aan de keten prioriteiten. Let wel, vol plannen betekent niet dat teams uitsluitend met dit soort portfolio-items hun capaciteit gaan gebruiken. Afhankelijk van het type team of trein zal er altijd een gedeelte van de capaciteit beschikbaar moeten zijn voor incident en probleembeheer. Bovendien fluctueert de capaciteit ook door rekening te houden met vakantie, studie etc.

Op deze manier is er dus elk kwartaal een evenwicht in de organisatie op dat moment tussen de backlogs op alle niveaus. Deze transparantie kun je vervolgens nog in Obeya’s zichtbaar maken waarmee je een mooie manier van visueel management kunt bereiken.

Doordat alle backlogs zijn geprioriteerd zullen er relatief weinig prioriteitsissues plaatsvinden. Van elk backlog item is bekend aan welk hoger backlogitem dit is gekoppeld (‘deze story is gekoppeld aan deze feature, is gekoppeld aan deze epic, is gekoppeld aan dit initiatief’).

En waarom lukt het nu vaak niet?

Een vaak voorkomende situatie is dat prioriteringsvraagstukken vaak te diep de organisatie in worden geduwd. Het komt dan bijvoorbeeld op het bord van een generieke keten of trein te liggen om te prioriteren tussen initiatieven Daarmee ontstaat voor teams vaak een situatie waarin men probeert iedereen tevreden te houden met als gevolg een WIP-limit (work-in-progress) die veel te hoog is met een verslechtering van flow tot gevolg. Men maakt niets meer helemaal af en verliest veel tijd door stop/start-werkzaamheden.

Vaak zijn er 3 onderliggende redenen aan te wijzen als er teveel prioriteitsvraagstukken zijn in organisaties,

1. Niet echt prioriteren (1,2,3,…) maar alleen MoSCoW toepassen
2. Niet prioriteren op het hoogste niveau
3. Prioriterings issues niet transparant maken

Ad1: Niet echt prioriteren (1,2,3,…) maar alleen MoSCoW toepassen

Een vaak voorkomende vorm van prioriteren is het gebruik van MoSCoW. Als bijvoorbeeld de strategische initiatieven uitsluitend via MoSCoW zijn geclusterd, zullen alle Must-do’s de keten backlogs in worden geduwd. Dan ontstaat daar dus het prioriteits vraagstuk of het belangrijker is om een bijdrage te leveren aan strategisch initiatief 1 of 2 (beiden must-do).

Dit probleem zet zich dan door naar de treinen en de teams waardoor soms op team niveau dit soort overwegingen door de Product Owner gemaakt moeten worden. Met name in grote organisaties waarin geen volledige autonomie bereikt kan worden en er altijd ketens, treinen en teams met een meer generieke doelstelling zullen zijn, zal dit prioriteitsvraagstuk zich daar veel voordoen.

Dit heeft veel frustratie tot gevolg voor iedereen. Zowel bij de teams die vaak niet optimaal waarde kunnen leveren als de teams die graag gebruik willen maken van features van anderen maar niet geleverd krijgen. In plaats van continu moeten interveniëren zou de organisatie zich beter bezig kunnen houden met de vraag hoe dit te voorkomen door een goed prioritering in alle backlogs.

Een betere en objectievere vorm van prioritering is te bereiken door de businesswaarde te gebruiken in de relatieve prioritering. Dit wordt ook als best practice in SAFe toegepast en daar WSJF genoemd.

Ad2: Niet prioriteren op het hoogste niveau

Het niet prioriteren op het hoogste niveau is een vaak voorkomend fenomeen. Vaak zijn organisaties zo verzuild dat men zich niet bewust is van het feit dat zij voor de levering van diensten en services afhankelijk is van leverende partijen (ketens, treinen, teams) die aan alle divisies leveren.

Dit kan alleen maar worden opgelost door toch het gesprek aan te gaan op strategisch niveau wat nu de echte organisatie brede prioriteiten zijn. Dit is soms erg schurend en voelt soms aan als een ‘appels en peren’ discussie. Dat is het vanuit een doelgroep aspect ook vaak (‘waarom is een strategisch initiatief voor de divisie Kleding nu belangrijker dan een strategisch initiatief voor de divisie Schoeisel?’) maar voor bijvoorbeeld  een keten die de totale interactie met de klant moet verzorgen is dit zeer relevant. Het zou niet hun probleem moeten zijn om tussen deze 2 strategische initiatieven te kiezen.

Soms wordt hiermee ook duidelijk dat er geen gezamenlijke strategie is van de organisatie als uitgangspunt voor het wegen/prioriteren van het portfolio. Dat ontaardt dan in een nietje slaan door de divisie portfolio’s. Dit appelleert aan de belangrijkste taken van het senior leiderschap in een organisatie; richting geven (prioriteren), ruimte geven (aan ketens/treinen/teams voor de uitvoering) en blokkades wegnemen (kiezen als zich toch keuzevraagstukken voordoen).

Ad3: prioriterings issues niet transparant maken

Als je het effect van prioriteren over alle 4 de niveaus wilt bereiken is het belangrijk dat je ten allen tijde inzicht hebt in de bijdrage die de stories hebben aan features, features aan epics en epics aan initiatieven. Daarmee heb je ook een manier om de overerving van de prioriteiten transparant te maken.

Als je dit dan samenbrengt met de voordelen van visual management volgens de Obeya aanpak, heb je een heel krachtige manier om met blokkades (impediments) om te gaan. Het is immers in één oogopslag duidelijk waar de blokkades op de belangrijkste initiatieven liggen. Hiermee is er een veel grotere waarborg om de gewenst flow in het voortbrengingsproces te bereiken.

Samenvatting 

• goed prioriteren is een voorwaarde voor flow in het voortbrengingsproces
• prioriteren op het hoogste niveau is niet makkelijk maar voorkomt belemmeringen op de lagere niveaus
• verbind de verschillende backloglagen met elkaar zodat er transparantie ontstaat in de manier waarop invulling wordt gegeven aan het veranderportfolio
• kies voor een prioriteringsritmiek die:
  • ieder kwartaal wordt bijgesteld aan de hand van de nieuwste inzichten
  • vanaf het committeren via een PI Plan het karakter van een boodschappenlijst waar je alleen in hele bijzondere gevallen van afwijkt
  • verschil maakt tussen prioriteiten stellen als rol van senior leiderschap en uitvoering geven in een kwartaalritmiek door autonome teams
• deze wijze van prioriteren geldt ook voor strategische initiatieven in de vorm van programma’s