We zien het allemaal wel gebeuren: een team in de organisatie levert snel, goede resultaten. Het heeft een directe relatie met de business, doordat een PO-er of liever nog een domeineigenaar onderdeel uitmaakt van het team. Er wordt slim samengewerkt. De lijntjes naar operations zijn goed gelegd of nog beter volledig in het team getrokken. Een succesvol team!
De directie is enthousiast en wil meer. Wat als we opschalen naar meerdere teams? Hoe kunnen we onze andere teams ook zo effectief krijgen?
In de praktijk blijkt dit een heel lastig vraagstuk te zijn. Het punt wat altijd naar voren komt is namelijk: Wat is een logische indeling van verantwoordelijkheden per team? Teams worden ingericht naar hun vakinhoudelijke discipline; producten die ze ondersteunen of klantgroepen die ze bedienen. Er zijn nog vele indelingen te bedenken.
Waar we in software architectuur aan het leren zijn dat de opdeling van systemen in logische ‘bounded contexts’ belangrijk is en nog belangrijker is hoe deze bounded contexts met elkaar communiceren. Zien we dit nog beperkt terug in de organisatiestructuur.
Bounded contexts zijn echt iets anders dan de gemiddelde component of service opdeling in CBD/SOA/API-architectuur termen. Het beoogt invulling te geven aan het decompositie vraagstuk waar we al jaren naar zoeken: maximale samenhang en minimale koppeling.
Wat is een Bounded Context?
De term bounded context is door Eric Evans geïntroduceerd in zijn werk Domain Driven Design. Het wordt ook wel beschreven als: “A semantic contextual boundary”.
Semantic: het heeft directe betekenis binnen het (business) domein. Een orderverwerking heeft in een productiebedrijf een andere betekenis dan voor een dienstverlener.
Contextual: het expliciet maken van de situationele omgeving waarbinnen we ons bevinden. In het productiebedrijf wordt in de orderverwerking een product verwerkt. Binnen de context van orderverwerking zijn we geïnteresseerd in specifieke eigenschappen van het product.
Boundary: de afbakening van de context waarbinnen we actief zijn. Voor de orderverwerking is het van belang dat de betaling binnen is, de voorraad wordt bijgewerkt, de producten geleverd worden. Daarmee worden de grenzen van de bounded context gezet.
Meerdere bounded contexts vormen het domein waarin een organisatie actief is. Bounded contexts hebben dus interactie met elkaar. Dat zelfde geldt dus ook voor de teams die verantwoordelijk zijn voor een of meerdere bounded contexts.
Tot dus zien we de bounded contexts nog beperkt terug in de organisatiestructuur. We zien wel het omgekeerde gebeuren, waardoor Conway’s Law kon ontstaan: “Organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations“. Vrij vertaald uit de opbouw van systemen kunnen we de organisatiestructuur afleiden.
Dit leert ons dat wanneer we de verbintenis tussen de organisatiestructuur en software architectuur niet expliciet maken dit impliciet wel zal ontstaan. Gevolg is dat na de zoveelste doorgevoerde reorganisatie we er achter komen dat deze toch niet lekker werkt. Teams hebben een te grote afhankelijkheid van elkaar, omdat ze dezelfde onderdelen uit de codebase moeten muteren. Het ineens blijkt dat we meerdere teams nodig hebben om die ene customer journey te kunnen leveren.
Het wordt dus tijd dat we de software architectuur/design meenemen in het afbakenen van de teamverantwoordelijkheid en organisatie inrichting.
Gelukkig is dit langzaam een denkwijze aan het worden die in Team Topologies van Matthew Skelton en Manuel Pais heel mooi omschreven wordt.
Hun werk is zeer de moeite waard om te lezen. Uit eigen ervaring kan ik zeggen dat het best wat tijd kost om het ook goed te doorleven.
De team typologie die ze uitgebreid beschrijven kent vier fundamentele team type:
- Stream-aligned
- Platform
- Enabling
- Complicated-subsystem
Interessante is dat in deze opdeling een sterke relatie gelegd wordt met het business domein / bounded contexts en de verantwoordelijkheden van teams.
Stream-aligned teams zijn gefocust op het primaire business doel. Voorbeelden als: het aansluiten van nieuwe klanten, afhandelen van claims, het vinden van de juiste advertentie, etc.
Ze hebben hierin end-to-end verantwoordelijkheid. Definiëren de metrieke die nodig zijn om hun succes aan te tonen. Ze zorgen dat de waarden van de metrieke zo positief mogelijk zijn, waardoor de dienst/functionaliteit het beste bij de doelgroep aansluit.
Platform teams faciliteren het stream-aligned team door het bieden van services/API’s die in de streams gebruikt kunnen worden. De Complicated-subsystem teams zijn verantwoordelijk voor die bounded context(s) waar hoge mate van domein logica een rol speelt. Complexe regelsets of andere vormen van gedrag in een domein, waar veel domein kennis een rol speelt.
Enabling teams faciliteren de steam-aligned teams met nieuwe inzichten of ontwikkelen die ze kunnen helpen hun doelen nog slimmer te bereiken.
Hierbij worden een drietal interactie-modi onderkent:
- Collaboration
- X-as-a-Service
- Facilitating
Deze interactie-modi geven inzicht hoe de teams onderling kunnen samenwerken.
Team Topologies is een denkstijl waarin een directe relatie met de onderliggend software architectuur wordt gelegd.
Zoals gezegd biedt Team Topologies veel denkstof. Een van de interessante perspectieven die mij in de praktijk al meerdere keren geholpen heeft is de Cognitive Load van een team.
Cognitive load wordt omschreven als: “the total amount of mental effort being used in the working memory“, John Sweller pagina 32.
Bij het bepalen van de verantwoordelijkheden van een team blijkt de cognitive load een interessante graadmeter. Hoeveel kennis moet een team hebben? Hoeveel nieuwe inzichten moeten en kunnen ze opdoen? Wat is de diversiteit van kennisgebieden? Door dit ook met teams zelf te bespreken ontstaat een hele mooie reflectie naar het team en haar omgeving. Al snel blijkt dat het team veelal zelf instaat is aan te geven wat ze aan kunnen en of de verantwoordelijkheden nog passend zijn.
Deze reflecties leveren inzicht op wat wel en niet werkt. Door hier doorlopend mee aan de slag te gaan past de organisatie zichzelf ook steeds meer aan….
“Organizations should be viewed as complex and adaptive organisms rather than mechanistic and linear systems” — Naomi Standford pagina 3.