Door: Aaron Van Stappen
In hun boek ‘Team Topologies: Organizing Business and Technology Teams for Fast Flow’ nemen Matthew Skelton and Manuel Pais softwareteams onder de loep. Hoe stel je de beste teams samen voor jouw specifieke doelen, bedrijfscultuur en noden? Onze medewerker, Aaron Van Stappen las het boek en beveelt het van harte aan.
Case study uit eigen ervaring
Mijn eerste kennismaking met de wereld van softwareontwikkeling was een sociaal secretariaat dat een nieuwe applicatie voor salarisverwerking maakte (‘spoiler alert’: dit dure project moest een jaar nadat ik gestart was geschrapt worden, na vijf jaar van ontwikkeling en met meer dan honderd betrokken mensen, zowel intern als extern). Hoewel ik terechtkwam in een team dat niet direct verbonden was aan de nieuwe applicatie, kreeg ik inzicht in verschillende aspecten die minder soepel liepen dan verwacht.
De primaire applicatie bood een website waarop salarisverantwoordelijken alle nodige gegevens konden invoeren. Het team waar ik deel van uitmaakte was echter verantwoordelijk voor de integratie met grotere bedrijven en hun salarisapplicaties. Omdat de database sterk gebaseerd was op de schermen, moesten we talrijke aggregaties van database-oproepen uitvoeren.
Een mislukt project
Die database-oproepen werden afgehandeld via interfaces die toegang hadden tot een DB2-instantie op een mainframe, beheerd door een ander team. Onze analist bereidde het werk weken van tevoren voor en gaf een overzicht van welke interfaces gebruikt moesten worden en hoe ze samengevoegd moesten worden.
Helaas waren de interfaces vaak weer veranderd wanneer we met de implementatie begonnen. Dat leidde op zijn beurt tot aanzienlijke overhead bij het ophalen van de juiste interface declaraties.
Blijkbaar waren we niet de enigen die dit tegen kwamen. Na zes maanden werken aan het project introduceerde het bedrijf de SAFe-methodologie (Scaled Agile Framework). Die stap was bedoeld om duidelijke teamoverzichten te bieden en afhankelijkheden te benadrukken. Toch mislukte het project een paar maanden later.
Het is belangrijk om op te merken dat het hier niet mijn bedoeling is om dit specifieke bedrijf te bekritiseren. Ik ben ervan overtuigd dat het spookbeeld van een (bijna) mislukt project bij veel bedrijven hangt, waarbij sommige slagen terwijl anderen een soortgelijke afloop tegemoet gaan.
Problemen met teams
Toen ik ‘Team Topologies’ begon te lezen, moest ik onmiddellijk terugdenken aan deze ervaring. Ik botste echter ook op heel wat andere problemen die ik tijdens mijn carrière was tegengekomen. Vaak hadden ze een paar thema’s gemeenschappelijk:
- grote afhankelijkheid van andere teams
- onduidelijke domeingrenzen
- beperkte mogelijkheden voor teams om te experimenteren met nieuwe technologieën of architectuur
- gebrek aan ownership van ontwikkeling tot onderhoud
- top-down design beslissingen
- communicatieproblemen tussen teams
- hoge cognitieve belasting van het team
‘Team Topologies’ is geen pasklare oplossing om deze problemen aan te pakken. Het is wel een waardevolle benadering over hoe teams de beoogde architectuur voor een applicatie kunnen overbrengen en tegelijkertijd bekende valkuilen kunnen beperken.
De omgekeerde Conway
Het boek is gebaseerd op de wet van Conway: “Elke organisatie die een systeem (ruim gedefinieerd) ontwerpt, zal een ontwerp produceren waarvan de structuur een kopie is van de communicatiestructuur van de organisatie”.
In deze context verwijst “communicatiestructuur” niet alleen naar het formele organigram, maar vooral naar de feitelijke communicatiepatronen binnen de organisatie. Die communicatiestructuur beïnvloedt in belangrijke mate het ontwerp van “het systeem”.
Het boek stelt een specifieke aanpak voor om teams samen te stellen die op één lijn zitten met de gewenste architectuur: “het omgekeerde Conway manoeuvre”. Dat wordt al toegepast in bepaalde industriële sectoren maar Skelton en Pais hebben een systematische aanpak ontwikkeld die bekend staat als “Team Topologies”.
Vier Team Topologies
De auteurs stellen vier archetypische teams voor: stream-aligned, platform, enabling, en complicated subsystem.
- Stream aligned: een team dat is afgestemd op de hoofdstroom van de bedrijfsverandering, met een cross-functionele vaardighedenmix en het vermogen om significante bijdrages te leveren zonder te wachten op een ander team.
- Platform: een team dat werkt aan het onderliggende platform dat stroom-gebonden teams steunt bij de oplevering. Het platform vereenvoudigt anderszins complexe technologie en beperkt de cognitieve belasting voor teams die het gebruiken.
- Enabling: een team dat andere teams helpt bij het overnemen en aanpassen van software als onderdeel van een overgangs- of leerperiode.
- Complicated subsystem: een team met een speciale opdracht voor een subsysteem dat te gecompliceerd is om door een normaal stream- of platformteam behandeld te worden. Optioneel en alleen te gebruiken als het echt nodig is.
Deze vier teamtypes zouden voldoende moeten zijn voor de overgrote meerderheid van organisaties die software ontwikkelen. De auteurs benadrukken wel het belang van deze drie effectieve interactiemodi om de communicatie tussen teams te vergemakkelijken.
- Samenwerkingsmodus: twee teams werken samen aan een gezamenlijk doel, vooral tijdens het ontdekken van nieuwe technologie of benaderingen. De overhead is waardevol vanwege het snelle tempo van leren.
- X-als-een-dienst: één team gebruikt iets dat door een ander team wordt geleverd (zoals een API, tool of volledig softwareproduct). Samenwerking is minimaal.
- Faciliterende modus: één team (meestal een faciliterend) helpt een ander team bij het leren of overnemen van een nieuwe aanpak.
Tips voor teams
Skelton en Pais beweren dat interacties buiten deze kernmodi verspilling zijn en een aanwijzing voor slecht gedefinieerde teamgrenzen en doelen. Verschillende stakeholders moeten betrokken zijn bij de beslissingen over teamsamenstelling, interactiemodi en begrensde contexten, waaronder bedrijfsleiders, teamleiders, architecten en meer. Daarnaast speelt cognitieve belasting een cruciale rol in de effectiviteit van een team. Een te hoge cognitieve belasting staat aanzienlijke vooruitgang in de weg.
Wat de levensduur van teams betreft, is het misschien niet handig om de teamsamenstelling vaak aan te passen. Het doel of de interactiemodi kan na verloop van tijd wel veranderen. Regelmatige evaluaties moeten bepalen of een team nog steeds het beoogde doel dient.
Van groter belang is echter het evalueren van de interactiemodi tussen teams. Als de noodzaak voor twee teams om intensief samen te werken na een paar maanden verdwijnt, verschuift de interactiemodus van samenwerking naar x-als-een-dienst.
Het boek ‘Team Topologies’
Skelton en Pais geven een overtuigend betoog in het voordeel van ‘Team Topologies’. Het boek is goed gestructureerd en gaat effectief in op een veelvoorkomende uitdaging in de techindustrie. Het implementeren van teamarchetypes en interactiemodi zal niet noodzakelijkerwijs elk obstakel uit de weg ruimen. Het benadrukt wel, net als Agile, feedbackcyclussen en aanpassingen wanneer dat nodig is.
‘Team Topologies’ bevat ook getuigenissen van professionals uit de industrie die vertellen hoe zij de samenstelling van hun teams hebben aangepast aan de beoogde architecturen, op basis van het werk van Skelton en Pais of reeds bestaand onderzoek. Hoewel de aanpak van bedrijven als Spotify of Amazon inspirerend is, is het belangrijk om te onthouden dat elke context uniek is en een aangepaste aanpak vereist.
Dit boek is in de eerste plaats waardevol voor wie betrokken is bij beslissingen over teamsamenstelling, maar de inzichten kunnen iedereen in de technologie-industrie van nut zijn.