Hoe zet je een succesvol cloud-platformteam op

De aanleiding
De meeste organisaties hebben een centraal (cloud)platformteam — of zouden dat moeten hebben. Zo'n team opzetten is een leuke uitdaging, maar wel een uitdaging. In 2019 publiceerden Matthew Skelton en Manuel Pais hun boek “Team Topologies”. Daarin delen ze de geheimen van succesvolle teampatronen en samenwerkingsvormen, zodat je de juiste patronen voor je eigen organisatie kunt kiezen en laten meegroeien — en je software gezond blijft en waardestromen optimaliseert.
Stel, je wilt het gebruik van cloud- of PaaS-diensten binnen je organisatie faciliteren, veranderen of verbeteren, en je wilt daarvoor een platformteam beginnen. Wat is een goede definitie van een platform?
Een digitaal platform is een fundament van selfservice-API's, tools, diensten, kennis en ondersteuning, samengebracht als een aantrekkelijk intern product. Autonome deliveryteams kunnen dat platform gebruiken om sneller productfeatures te leveren, met minder afstemming. bron: martinfowler.com
In dit artikel en in het boek “Team Topologies” geldt bovenstaande als een bruikbare definitie van een platform.
Vier teamtypes
Nu proberen we een archetype vast te stellen voor de teams die we willen maken. Team Topologies onderscheidt vier teamtypes. Voor ons platformteam kiezen we uiteraard 'platform', maar de andere types spelen een belangrijke rol als enabler, specialist of afnemer.

Stream-aligned team
Het stream-aligned team is het meest voorkomende en belangrijkste teamtype in je organisatie. Typische voorbeelden zijn featureteams. Met 'stream' wordt de continue stroom werk bedoeld die aansluit op een businessdomein of een capaciteit van de organisatie.
Dit type team is gericht op één waardevolle stroom werk, zoals:
- Eén product of dienst
- Eén set features
- Eén user journey
- Of één gebruikerstype
Dit team werkt over de volle breedte van de levering, van idee tot productie.
Enabling team
Enabling teams werken er voortdurend aan om hun kunnen op peil te houden. Zo'n team bestaat uit specialisten in een bepaald technisch domein (of productdomein). Ze helpen het kennisgat te overbruggen en werken sterk samenwerkingsgericht. Ze waken ervoor 'ivoren torens' van kennis te worden en vergroten de autonomie van stream-aligned teams door hun kunnen te laten groeien. Teams horen niet blijvend afhankelijk te worden van een enabling team. Dit archetype gebruiken we voor ons cloud-acceleratieteam.
Complicated subsystem team
Dit team bouwt en onderhoudt een deel van het systeem dat sterk leunt op specialistische kennis. Het doel is om de cognitieve belasting van stream-aligned teams te verlagen.
Voorbeelden:
- Een codec voor videoverwerking
- Een wiskundig model
- Een realtime-algoritme voor het afstemmen van transacties
- Een transactierapportagesysteem voor de financiële sector
- Een gezichtsherkenningsmotor
Platformteam
Dit teamtype heeft als doel:
- Stream-aligned teams in staat stellen hun werk met veel autonomie te leveren
- Interne diensten leveren die de cognitieve belasting wegnemen die stream-aligned teams anders zouden hebben om die onderliggende diensten zelf te bouwen
Interactievormen
Nu we de vier archetypes op een rij hebben, beschrijven we twee van de drie interactievormen tussen teams.
X-as-a-Service
Het ene team neemt iets af (bijvoorbeeld een dienst of een API) dat een ander team 'as a service' aanbiedt. De verantwoordelijkheden zijn afgebakend, en als die grens goed gekozen is, kan het afnemende team snel leveren. Het aanbiedende team probeert zijn dienst zo makkelijk mogelijk afneembaar te maken.
Voorbeeld: stream-aligned teams die platform-as-a-service afnemen van een platformteam.


Faciliteren
Het ene team helpt een ander team gedurende een afgebakende periode om iets nieuws te leren of in te voeren. Het faciliterende team wil het andere team zo snel mogelijk zelfstandig maken, terwijl het ontvangende team zich open opstelt.
Voorbeeld: een enabling team dat een stream-aligned team of platformteam helpt.
Het complete plaatje
Zetten we de interactievormen en de teamtypes bij elkaar, dan zien we een cloud-platformteam (in blauw) dat platform-as-a-service levert aan het stream-aligned featureteam (in geel). Dat stream-aligned team wordt bijgestaan door het complicated-subsystem team (in oranjebruin) voor specialistische kennis van handelssystemen, en wordt gefaciliteerd (de stippellijnoverlap) door het cloud-acceleratieteam (in paars).

Met deze rollen en verantwoordelijkheden kan je organisatie platformen op schaal benutten en voorkom je zowel under-engineering en over-engineering als lange wachtrijen door overbelaste centrale cloudteams. Die wachtrijen leiden tot nare bijwerkingen: beveiligingsproblemen, schaduw-IT, meer verloop en minder betrokken engineers. Team Topologies stelt je organisatie in staat glashelder te zijn over de verantwoordelijkheden van een team en de manier waarop het met andere teams omgaat. Dat voorkomt bovenstaande bijwerkingen en zorgt voor optimale doorstroom in je organisatie.
Meer weten?
Effectieve softwareteams zijn voor elke organisatie onmisbaar om continu en houdbaar waarde te leveren. Team Topologies is een praktisch, stapsgewijs en meegroeiend model voor organisatieontwerp en samenwerking, gebaseerd op vier fundamentele teamtypes en drie interactiepatronen.
Het model behandelt teams als het fundamentele middel om te leveren, waarbij teamstructuren en communicatielijnen kunnen meegroeien met de technologische en organisatorische volwassenheid. Er is een goede samenvatting van het boek hier te vinden, of je kunt het boek hier aanschaffen.

book

Alles of Niets, Katapulteer naar de Cloud
Transformeer je softwareorganisatie naar een cloud-native onderneming
Lees ook:

Hoe zet je een succesvol cloud-platformteam op
De meeste organisaties hebben een centraal (cloud)platformteam — of zouden dat moeten hebben. Zo'n team opzetten is een ...

Team Topologies - de omgekeerde Conway-manoeuvre
Uit het boek [“Team Topologies”](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol...

Wat dertig minuten wachten per engineer per dag echt kost
Een half uur per dag. Zo weinig lijkt het. Maar reken het door en het is €5.000 per engineer per jaar, of een half miljo...

Van monolith naar microservices met behulp van het strangler pattern
Het strangler pattern is een techniek uit Dave Farley's 'Continuous Delivery' voor het transformeren van een monolithisc...

DORA-metrics lezen als AI de helft van je commits schrijft
Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde. Zodra een flink deel...

Wat is Agile Analytics?
Agile Analytics is ons platform om softwareorganisaties te optimaliseren. Het geeft teams inzicht in hun hele pijplijn e...
