In mijn vorige blog introduceerde ik onze Product Support & Maintenance aanpak om Agile teams te helpen gestructureerd aan beheer te werken. Bij de voorbereiding van de implementatie van die aanpak bij één van onze klanten ontstond er een levendige discussie of je al het beheer door de teams kunt/moet laten uitvoeren of dat er nog centrale beheerrollen nodig zijn.

Voordat ik hier dieper op in ga, ben ik benieuwd welke mening jij hierover hebt. Vind je dat je sommige beheertaken centraal zou moeten organiseren? Welke taken zijn dat dan? En waarom? En hoe ga je dan om met de “you build it, you run it, you own it” verantwoordelijkheid die zo kenmerkend is voor de Agile en DevOps werkwijze? Onderstaand heb ik een aantal uitgangspunten en handvatten uit onze aanpak op een rij gezet die je kunnen helpen om tot de juiste beheerbalans te komen!

Wat is beheer en waarom doe je het?

Te vaak merk ik nog dat beheer gezien wordt als “op de winkel passen”. En natuurlijk is dat belangrijk. Immers “you run it”. Dus je moet er voor zorgen dat je product beschikbaar is en conform afspraken functioneert. Maar als je denkt vanuit “you own it” beslaat beheer een veel breder taakgebied. Dan heb je ook tot doel dat je product in optimale conditie blijft en optimaal ingezet wordt. Wij werken vanuit deze laatste insteek. Want goed beheer zorgt voor een kwalitatief beter product dat je sneller en beter kunt vernieuwen. Een product waar je klanten en gebruikers efficiënter en effectiever gebruik van maken en dus meer rendement oplevert.

Beheer is van de teams

Dat lijkt bijna vanzelfsprekend. “You build it, you run it, you own it” impliceert natuurlijk dat je als team er voor zorgt dat je het product en al zijn onderdelen goed beheert. Als één DevOps team voor een complete dienst voor een klant(groep) zorgt, is het ook relatief makkelijk in te richten dat het team de verantwoordelijkheid neemt voor alle beheeractiviteiten. Dat betekent niet per definitie dat het team al het beheer zelf uitvoert. Ongetwijfeld bevat je product onderdelen die je niet zelf gebouwd hebt. Maar waar je wel afhankelijk van bent om “you own it” waar te kunnen maken. In die gevallen wordt het beheer door een derde partij uitgevoerd en bewaak jij als team dat dat adequaat gebeurt. Ingewikkelder wordt het als de teams gezamenlijk een end-to-end klantdienst maken en beheren; waarbij ieder team dus zijn eigen deel van het eindproduct heeft. Op zich levert dat nog geen noodzaak op om beheeractiviteiten centraal te organiseren. Met concepten als scrum-of-scrums zou je prima in staat moeten zijn om succesvol samen te werken aan de teamoverstijgende beheeractiviteiten.

Beheer door de teams, tenzij….

Omdat beheer van de teams is, nemen wij als uitgangspunt dat de uitvoering (en waar relevant regie) van de beheeractiviteiten in principe binnen de teams plaatsvindt. Echter, voor een aantal beheeractiviteiten zien wij dat volledige uitvoering binnen elk van de teams niet efficiënt en niet effectief is. Denk bijvoorbeeld aan gebruikersondersteuning, incident management en autorisatiebeheer. Voor gebruikersondersteuning (een kernactiviteit van functioneel beheer) lijkt het in veel gevallen onwenselijk als de gebruikers rechtstreeks de teams benaderen. Deels omdat het lastig en arbeidsintensief is om de gebruiker een juiste keuze te laten maken welk team hij/zij benadert. Maar ook omdat elk team dan in principe moet organiseren dat het adequaat kan reageren op rechtstreekse benadering door gebruikers. Daarbij komt ook nog dat de vereiste reactietijd vaak leidt tot ongepland werk dat slecht past bij het planmatige werken in sprints. Voor het teamoverstijgend optuigen van autorisatiebeheer en coördinatie van en communicatie over incidenten gelden soortgelijke argumenten.

Gezamenlijke beheeractiviteiten blijven van de teams!

Hoewel het dus goed lijkt om een aantal beheeractiviteiten centraal te blijven organiseren, is er één cruciaal verschil met hoe nu vaak de verantwoordelijkheden belegd zijn. En dat is dat deze gezamenlijke beheeractiviteiten geen eigen besturing en leiding zouden moeten krijgen! Ze zijn en blijven van de teams. De teams kiezen er vanuit efficiëntie en effectiviteit voor om een aantal taken gezamenlijk als een soort shared service te willen uitvoeren. Zij zijn er dan ook verantwoordelijk voor dat aan alle voorwaarden voor succesvolle uitvoering is voldaan. Zo dienen de teams er voor te zorgen dat de bemensing van de shared service adequaat wordt getraind op de nieuwe/gewijzigde functionaliteit. Ook zou je de teams verantwoordelijk kunnen maken voor de bemensing van de shared service vanuit hun teams. Waarbij ze dan ook de mogelijkheid hebben om dat te laten rouleren, afhankelijk van de benodigde kennis.

Werk aan je eigen beheerbalans!

Het vinden van de beheerbalans voor je eigen teams is maatwerk. Specifieke factoren als kennis en de verwachte frequentie en intensiteit van beheeractiviteiten kunnen je er toe doen besluiten om sommige beheeractiviteiten in de teams uit te laten voeren of juist in een shared service.

Vanuit de implementaties die wij bij/met klanten doen, ontstaan inmiddels de eerste hulpmiddelen om tot een juiste beheerbalans te komen. Ben je daarin geïnteresseerd of wil je meer weten over de voordelen en/of de implementatie van Product Support & Maintenance?

Neem dan gerust contact met ons op!