Wie is er verantwoordelijk voor Beheer in een Agile omgeving?
Werk je in een organisatie met een Agile werkwijze? Dan stel ik graag de bovenstaande vraag aan je! Wie is er volgens jou verantwoordelijk voor beheer? Voordat je verder leest, daag ik je uit om hier even goed over na te denken en je antwoord en argumentatie te formuleren.
In deze blog ga ik verder in op deze vraag. Ik bespreek een aantal alternatieven die ik in de praktijk tegen kom en geef je een handvat om deze discussie ook in je eigen organisatie op te starten als je daar door het lezen van deze blog aanleiding toe ziet.
Wat versta je onder Beheer?
De eerste discussie die vaak losbarst! Wat is Beheer nou eigenlijk? Een veelkoppig monster! In de blog Ontwikkeling in IT beheer: Looijen, BiSL, Run & Change, DevOps gaan we daar dieper op in.
Qua werkzaamheden hanteer ik voor Beheer meestal de volgende definitie: een object in optimale conditie houden en optimaal benutten.
Wat je beheert koppel ik graag aan het ‘hele apparaat’ dat je nodig hebt om je diensten aan je klant te kunnen leveren. De processen waarmee je de diensten levert, de informatieproducten die je nodig hebt, de data die je gebruikt en die de dienstverlening oplevert, de onderliggende applicaties en technische infrastructuur.
De toegevoegde waarde van Beheer
Continuïteit wordt vaak beschouwd als primaire toegevoegde waarde van Beheer. Natuurlijk is dat cruciaal, maar tegelijkertijd een hygiëne factor: moet gebeuren, zo weinig mogelijk geld aan uitgeven. De echte toegevoegde waarde van Beheer zit bijvoorbeeld in optimale aanwezigheid en gebruik van functionaliteit. En in maximale ontwikkelproductiviteit om optimaal te reageren op veranderende behoeften en omstandigheden. Hoeveel groter zou je ontwikkelproductiviteit zijn (elke sprint!) als je alles netjes beheerd hebt?
Welke kandidaten zijn er voor de verantwoordelijkheid voor Beheer?
Met bovenstaande in gedachte, wordt in de praktijk de verantwoordelijkheid voor Beheer in een Agile omgeving vaak bij de volgende kandidaten belegd:
1. Beheerder(s)
2. Hoofd(en) beheer
3. Ketenregisseur / service level manager
4. Agile team
5. Product Owner
Dit lijstje is zeker niet uitputtend, maar voldoende om meerdere invalshoeken van de problematiek duidelijk te maken.
1. Beheerder(s) als verantwoordelijke
Veel organisaties kennen (nog?) combinaties van Agile werken en formele beheerfuncties. Denk aan functies als procesmanager, functioneel beheerder, applicatiebeheerder, manager data-quality. Hoewel je vaak als onderdeel van een Agile team opereert, heb je ook nog steeds een formele verantwoordelijkheid voor het beheer en de te behalen KPI’s op het gebied van beheer.
Deze verantwoordelijkheid blijkt in de praktijk vaak lastig in te vullen: hoe borg je dat het kortcyclisch opleverende Agile team blijft voldoen aan de vaak weinig flexibele acceptatiecriteria en KPI’s? En hoe doe je dit als er meerdere Agile teams werken aan het product waarvoor jij verantwoordelijk bent?
2. Hoofd(en) Beheer als verantwoordelijke
Organisaties met beheerfunctionarissen kennen vaak één of meerdere hoofden Beheer. Meestal voor een specifiek gebied, zoals bijvoorbeeld hoofd Functioneel Beheer. Deze hoofden hebben een formele bevoegdheid/verantwoordelijkheid voor het beheer (binnen hun aandachtsgebied) van een aantal producten/diensten van de organisatie. Hoofden Beheer hebben dezelfde uitdaging als beheerders, maar dan voor alle producten/diensten die ze met hun team ondersteunen. Hoe kun je met al die zelforganiserende Agile teams grip blijven houden op de effectiviteit en efficiëntie van Beheer?
3. Ketenregisseur (service level manager) als verantwoordelijke
Beheer is steeds vaker (in)gericht op de ondersteuning van het bedrijfsproces in plaats van de ondersteuning van onderliggende componenten zoals een applicatie. Vaak komen dan ook ketenregisseurs en/of service level managers in beeld die de verantwoordelijkheid toegewezen krijgen voor het adequaat (laten) beheren van de voor de keten relevante componenten. Als de organisatie Agile gaat werken, ontstaat een uitdaging voor de ketenregisseur: hoe stuur ik het beheer binnen de Agile teams die voor mijn keten relevant zijn? En wat doe ik met de beheeractiviteiten die niet op teamniveau maar op ketenniveau moeten worden uitgevoerd zoals gebruikersondersteuning?
4. Agile teams als verantwoordelijken
You build it, you run it, you own it! Het Agile team krijgt de verantwoordelijkheid voor ontwikkeling en beheer van de aan hun toegewezen componenten. Prima uitgangspunt! De scope van het beheer is vaak nog beperkt tot applicatiebeheer. Als er BizDevOps teams ontstaan (bijvoorbeeld squads en tribes) is de beheerverantwoordelijkheid ook breder. Beheer is in deze teams geen functie meer, maar een expertise! Het borgen en zichtbaar maken van de aandacht voor beheer en de kwaliteit daarvan (zowel binnen het team als overkoepelend) is vaak nog lastig!
5. Product Owner als verantwoordelijke
De Product Owner is verantwoordelijk voor de prioritering van het werk voor het Agile team. Daarmee kun je stellen dat de Product Owner keuzes maakt over het beheer dat het Agile team uitvoert. Ik ken Product Owners die dit inmiddels helemaal onder de knie hebben. Helaas zijn er nog veel Product Owners die onvoldoende kennis van Beheer hebben om hun stakeholders te overtuigen van de toegevoegde waarde van Beheer voor het bedrijfssucces.
Wie geef jij de verantwoordelijkheid?
Wat was jouw keuze voordat je deze blog begon te lezen? Hoe is het beheer eraan toe in jouw organisatie? Herken je de uitdagingen bij het invullen van de verantwoordelijkheid voor beheer? Ik zal mijn keuze met je delen.
Mijn keuze: de Business Owner!
In onze gesprekken met organisaties die deze problematiek proberen te adresseren bij hun transformatie naar Agile werken, wordt in mijn ogen één kandidaat voor de verantwoordelijkheid voor Beheer structureel onvoldoende betrokken en benoemt. En dat is de Business Owner. De persoon die verantwoordelijk is voor de dienstverlening naar de klant. Hij is de primaire belanghebbende van een optimaal beheerd ‘apparaat’ dat de dienstverlening aan de klanten verzorgt.
De Business Owner moet in mijn ogen het beheer organiseren en aansturen. Dat doe je met de verschillende leveranciers van (deelgebieden van) beheer. Op die manier kun je voor je hele apparaat zorgen dat er structurele aandacht voor beheer is. Waardoor je niet alleen continuïteit borgt, maar bijvoorbeeld ook zorgt voor maximale ontwikkelproductiviteit waardoor jouw dienstverlening beter blijft aansluiten op de behoeften!
Hoe voer je deze discussie?
Als je deze discussie wilt aanzwengelen binnen jouw organisatie, hebben we daar een aantal ondersteunende hulpmiddelen voor. Als de problematiek herkend wordt, is mijn advies om een voorstel te maken voor de Business Owner om jullie Beheer van de Toekomst vorm te gaan geven. Daar kan ons Stappenplan je bij helpen.
Wil je onze hulp om deze discussie in jouw organisatie op te starten? Neem dan contact met ons op! Heb jij deze discussie al gevoerd? Deel je ervaringen!