Team Topologies: optimaliseer DevOps teams

Feedbackloop tussen Enabling- en Platformteams voor DevOps begint bij het Organisatiemodel

Grotere organisaties hebben vaak teams die ondersteunend zijn aan de ontwikkelteams. Binnen het boek Team Topologies zijn er o.a. twee ondersteunende team typen gedefinieerd, namelijk een enabling team en een platform team.

Een enabling team zorgt ervoor dat een ontwikkelteam (binnen ‘Team Topologies’ een stream alligned team) goed het werk kan uitvoeren. Dit teamtype bestaat uit specialisten met een bepaald domeinkennis en kan technisch, product of vakkennis gerelateerd zijn. Ze hebben het doel kennis en expertise over te brengen naar de ontwikkelteams.

Een platform team ontwikkelt interne producten om te zorgen dat ontwikkelteams sneller producten kunnen ontwikkelen. Het team ontwikkelt bijvoorbeeld diensten of tools die de ontwikkelteams kunnen afnemen.

Binnen ‘Team Topologies’ worden drie samenwerkingsverbanden gedefinieerd, namelijk, x-as a service, collaboration en facilitating. Platform teams proberen hun diensten en tooling vooral te ontsluiten via een ‘as a service’ model, terwijl een enabling team facilitating zou moeten zijn richting de ontwikkelteams.

Persoonlijke Ervaringen

In beide teamtypen ben ik de laaste jaren werkzaam geweest. Binnen enabling teams heb ik gewerkt als testcoach, CI/CD Enabler en DevOps coach om mijn kennis over te brengen naar ontwikkelteams en ze te ondersteunen in hun (delivery) uitdagingen. Binnen platform teams heb ik gewerkt als platform engineer om zo diensten te ontsluiten richting ontwikkelteams ten behoeve van CI/CD en testen. Denk aan tools zoals Azure DevOps, SonarQube/ SonarCloud, Artifact storage, testtooling en security scan tools. Beide teams zijn er om de DevOps way of working te ondersteunen en te laten groeien binnen de organisatie. Het enabling team vanuit de practices en het platform team vanuit de tooling. 

Organisatorische Indeling

Grote organisaties kiezen er vaak voor om teams per type te clusteren. Platform teams worden vaak bij elkaar geplaatst en krijgen dezelfde manager. Denk bijvoorbeeld aan het bij elkaar plaatsen van alle teams die IT4IT diensten ontwikkelen of het samenbrengen van een DevOps tooling team, cloud team en infrastructuur team onder één lijnmanager. Logisch want bij DevOps behoort uiteraard ook de infrastructuur. Enabling teams worden vaak bij elkaar geplaatst bijvoorbeeld onder de architectuur, strategie of way of working vlag.

Problemen met de Huidige Indeling

Het probleem met bovenstaande organisatorische indeling is dat, als het gaat om DevOps, de feedbackloops suboptimaal zijn ingericht tussen het enabling en platform team. Zo ontstaan er een aantal problemen:

• Het DevOps enabling team wordt als stakeholder gezien door het DevOps platform team met vertraging van de realisatie van technische capabilities als gevolg.
• Het DevOps enabling team is vaak het eerste aanspreekpunt als het gaat om feedback over het platform. Er ontstaat automatisch een handover van de feedback richting het platform team. Dit levert vertraging en vertalingsproblemen op.
• Het niet hebben van één duidelijke community en aanspreekpunt. Ontwikkelteams zijn vaak verward bij welk ‘loketje’ ze moeten zijn als het gaat om DevOps.
• Er treedt inefficiëntie en ineffectiviteit op als het gaat om afdelingsoverleggen en rapportagelijnen, zelfs binnen matrixorganisaties.