Hoeveel prioriteit geef jij als Product Owner aan gestructureerd werken aan beheer?

De meeste Agile en DevOps teams werken vanuit het principe “you build it, you run it, you own it”. Voor een Product Owner betekent dat balanceren tussen beheer en vernieuwing. En dat blijkt in de praktijk vaak lastig. De druk vanuit stakeholders op vernieuwing is veelal zo hoog dat de Product Owner en het team onvoldoende gestructureerd werken aan beheer. En dat terwijl goed beheer juist een kwalitatief beter product oplevert waardoor je sneller en beter kunt vernieuwen!

Wat moet je nu doen als Product Owner doen om de juiste keuzes qua beheer te kunnen (laten) maken? In dit blog geef ik je hiervoor een vijftal pragmatische handvatten.

5 Handvatten

1. Bepaal met de stakeholders en het team de toegevoegde waarde van goed beheer.

2. Laat het team vaststellen hoe je (werken aan) beheer zichtbaar maakt, bijv. in de backlog.

3. Benoem de rol van Product Support & Maintenance Owner in het team voor het managen van de beheerbacklog.

4. Laat het team de kennis vergroten van de objecten waar je product uit is opgebouwd, de kwaliteitseisen en de huidige kwaliteit.

5. Stel met je team vast welke beheeractiviteiten jullie prioriteit geven en hoe jullie die (willen) uitvoeren.

Bovenstaande maatregelen maken deel uit van onze Product Support & Maintenance aanpak waarmee we Agile organisaties en teams helpen om gestructureerd aan beheer te gaan werken. Ik ben er van overtuigd dat je met een goede implementatie van deze vijf maatregelen al in een paar sprints een duurzame verbetering kunt bereiken.

Bepaal met de stakeholders en het team de toegevoegde waarde van goed beheer

Eén van de belangrijkste oorzaken voor gebrek aan prioriteit voor beheer is dat stakeholders niet goed weten waarom gestructureerd werken aan beheer belangrijk voor ze is. Iedereen die een rol speelt bij het stellen van de prioriteiten van het team zou moeten weten welke toegevoegde waarde het team met goed beheer nastreeft.

Het is essentieel om het denken over beheer te veranderen. Beheer heeft niet alleen het borgen van continuïteit tot doel. Dan zou het geen nieuwe waarde toevoegen, “slechts” waardeverlies voorkomen en logisch zijn dat je alleen het minimaal noodzakelijke doet.
Essentieel om te beseffen voor stakeholders is dat goed beheer er voor zorgt dat je sneller en beter kunt vernieuwen. Deze week helaas nog een treffend voorbeeld bij een organisatie waarbij door méér focus op beheer een paar maanden doorlooptijd gewonnen zou zijn. Zonde van de waarde die daarin bereikt had kunnen worden!

Zodra de stakeholders de toegevoegde waarde inzien, is de weg vrij om te borgen dat er structureel capaciteit aan beheer wordt besteed en het niet als eerste van de wagen valt wanneer er iets anders tegen zit in een sprint!

Laat het team vaststellen hoe je (werken aan) beheer zichtbaar maakt, bijv. in de backlog

Als je gestructureerd wil werken aan beheer, zul je inzichtelijk moeten krijgen (en houden!) aan welke beheeritems je wil werken en welke waarde ze voor je hebben. Net als andere items op je product backlog. Door deze items binnen je product backlog van een beheerlabel te voorzien, is het als team mogelijk om eenvoudig overzicht te houden over je beheerprioriteiten. En over het tempo en de omvang waarmee beheer ook daadwerkelijk in de sprints wordt ingepland en uitgevoerd.

Daarnaast vereist gestructureerd werken aan beheer dat je tijdig een analyse maakt van de beheerimpact van epics en features die het team gaat realiseren. Dit kan leiden tot aanpassingen in de DoR/DoD of tot het expliciet plannen van features / user stories / tasks om het adequaat beheer van een epic of feature mogelijk te maken. Tenslotte dient beheer ook een plekje te krijgen in sprintplanning, maar vooral ook in Demo.

Benoem de rol van Product Support & Maintenance Owner in het team voor het managen van de beheerbacklog

Zoals al eerder aangegeven is het de verantwoordelijkheid van de Product Owner om de prioriteiten te stellen. Zowel voor vernieuwing als beheer. In de praktijk is het voor een Product Owner vaak lastig (qua kennis en/of beschikbare tijd) om te (laten) zorgen/bewaken dat de juiste beheeritems juist op de backlog komen en dan ook te managen (zoals bijvoorbeeld refinement).

Maar wie doet dat dan? Wij hebben hiervoor de rol van Product Support & Maintenance Owner ontwikkeld. Geen functie, maar een rol binnen het team, zoals je ook andere rollen in het team kent. Het benoemen en inregelen van deze rol leidt in mijn ogen tot een efficiënte en effectieve invulling van de teamverantwoordelijkheid om gestructureerd te werken aan beheer. Zonder deze rol loop je het risico dat beheer van iedereen en daardoor tegelijkertijd van niemand is. Het is natuurlijk wel belangrijk om te beseffen dat deze rol door meerdere teamleden kan worden uitgevoerd!

Laat het team de kennis vergroten van de objecten waar je product uit is opgebouwd, hun kwaliteitseisen en hun huidige kwaliteit

Beheer definiëren wij als: een object in optimale conditie houden en optimaal inzetten. Professioneel beheer vereist dat je als team weet hoe een product in elkaar zit. En welke onderdelen van het product van jou zijn, “you own it”. Ben je als team eigenaar van een (deel van een) bedrijfsproces? Welke functionaliteiten hebben jullie daarvoor ontwikkeld? Welke data is van jullie? Welke applicaties heb je gebouwd, gekocht of hergebruikt om de functionaliteit in te realiseren? En op welke infra draait het?

Om goed te kunnen beheren zul je moeten weten wat de kwaliteitseisen zijn die voor deze objecten gelden. Maar natuurlijk ook wat de huidige kwaliteit is, zodat je kunt zien waar deze afwijkt van de kwaliteitseisen. Vaak zijn de Agile teams opgezet zonder dat er een degelijke overdracht is geweest van dit soort informatie. Daarnaast wordt deze informatie vaak niet structureel bewaard en onderhouden.

Stel met je team vast welke beheeractiviteiten jullie prioriteit geven en hoe jullie die (willen) uitvoeren

Als je gestructureerd aan beheer gaat werken is het natuurlijk belangrijk om vast te stellen welke activiteiten je daarvoor dient te ontplooien. Gebruikersondersteuning, incident management en monitoring liggen misschien voor de hand, maar mogelijk zijn Business Continuity Management en onderhoud van Knowledge Items wel net zo relevant.

Bij het opbouwen van gestructureerd werken aan beheer vinden wij het belangrijk dat je focus aanbrengt. Kijk welke verbeteringen in activiteiten je het best kunnen helpen om de kwaliteit van je beheer te verhogen. Kijk waar je deze activiteiten innovatief kunnen vernieuwen met best practices uit de markt. Bepaal een vorm waarin je je werkwijze vast legt zodat je het in en over de teams kunt delen.