Introductie
In mijn ervaring met het organisatie breed inrichten van agile werkwijzen ben ik altijd geïntrigeerd geweest over de structuur van een organisatie. En hiermee bedoel ik niet alleen het organigram, maar ook alle informele structuren die aanwezig zijn in een organisatie, en de hiërarchie en rollen die zijn gedefinieerd in de organisatie.
De belangrijkste paradigmaverschuivingen zijn de verschuivingen van inside-out naar outside-in denken, van functioneel naar productgericht structureren, en van een Angelsaksische naar een Rijnlandse manier van leiden en organiseren. Het kantelen van organisaties van de Angelsaksische naar een Rijnlandse organisatiestructuur en besturing is eigenlijk wat impliciet dient te geburen bij agile transities.
(Zie het belangrijke werk van Jaap Peters over dit onderwerp: https://vimeo.com/48072510
Wat je ziet op de figuur aan de rechterkant zijn zelforganiserende teams van zelforganiserende multidisciplinaire teams. Dit betekent dat Business owners, IT, Architectuur, UX en eventueel staven als legal, risk, compliance, marketing en sales, allemaal zijn opgenomen in die productgeoriënteerde teams van teams. Deze productgeoriënteerde teams van teams worden ook aangeduid als Value Streams.
Zoals Jaap Peters in de video zegt, omdat die teams zich op het product hebben gericht, zijn ze in staat om beslissingen die ze nemen, in de context van hun product (en dus de eindklant) te plaatsen. Zo draagt het bij aan de kwaliteit en acceptatie van het product. De kwaliteit van het product wordt ook bepaald door de hoeveelheid technische, functionele en UX-schuld in het IT-landschap. Die teams houden dus meer rekening met het reduceren van die schuld, dan een organisatie waarin functies en (suboptimale) verantwoordelijkheden verdeeld zijn over verschillende (functionele) afdelingen.
Deze oriëntatie vereist slechts één (Business) manager die een team van teams leidt. Er is dus geen aparte IT-manager of IT-afdeling nodig.
Maar er is veel meer over te zeggen.
Het fractale structuurpatroon in grote organisaties
1. Teamniveau
Ik zie het volgende fractale structuurpatroon ontstaan bij het schalen van productgeoriënteerde teams van teams.
Een enkelvoudig team is (volgens Scrum al) business georiënteerd. We noemen dat een feature team. Echter, veel klassiek georiënteerde organisaties beginnen met teams gericht op een (of meerdere) applicatie(s), en vertegenwoordigen dus geen businesswaarde. We noemen die teams component teams. Omdat ze zelfstandig niet in staat zijn om businesswaarde te realiseren. Er kan dus een mix ontstaan van business georiënteerde en component georiënteerde teams.
Ditziet het er als volgt uit:
De backlog van een feature team bestaat uit User Stories voor één specifiek bedrijfsproduct. De backlog van een component team bestaat uit User Stories, aangevraagd door beide feature teams. Voorbeeld: Featureteam 1 heet Incasso en featureteam 2 heet betalingen. Het component team kan een ondersteuningsteam of mid-tier team zijn, dat beide feature teams ondersteunt. Natuurlijk, de ideale situatie zou een platte organisatie zijn, bestaande uit niets meer dan featureteams en een CEO. Dat zou er zo uitzien:
In de praktijk heb je echter bijna altijd ook componentteams. Hoe dan ook, het is afhankelijk van veel factoren die bepalen of een organisatie beslist voor al dan niet component of featureteams. De mate van ‘loosely coupling’ (lees flexibiliteit) van uw IT-landschap is hierbij oa een belangrijke factor. Dus een combinatie van component en feature teams is niet verboden, noch vreemd.
2. Team van teams niveau
Wanneer we meer dan 5 teams hebben, of 50 medewerkers, gericht op één product, noemen we dat een team van teams, of een tribe. Het betekent dat deze mensen allemaal samenwerken in dezelfde cadans en flow om een product te innoveren en onderhouden. Schematisch zou het er als volgt uitzien:
Opmerking: dit is gewoon schematisch, om een fractal karakter te benadrukken. Ik heb al gezegd dat je niet moet organiseren in een tribe als minder dan 50 mensen betrokken zijn. Dan kun je bij teamniveau blijven.
3. Waardestroomniveau
Als een product geinnoveerd en onderhouden kan worden door tussen de 50 en 150 personen, of ongeveer 5 tot 15 teams, kun je volstaan met slechts één tribe. Echter, als een product vraagt om meer dan 150 mensen of 15 teams om te innoveren en onderhouden, dan kun je organiseren in een waardestroom voor dat product met meerdere tribes. Tribes op hun beurt kunnen ook weer business of component-gericht zijn. Dit zou er als volgt uitzien:
Als we dan de positie van de teams binnen de tribes ook visualiseren (nogmaals, ik houd het patroon aan van een component team met 2 feature teams om schematische redenen, in realiteit zou je vanzelfsprekend allerlei verschillende samenstellingen zien), zou het er als volgt uitzien:
4. Bedrijfsniveau
Neem nu een Telco. Deze heeft als voorbeeld deze twee waardestromen:
- Telefonie
- Televisie
Dus het patroon kan zelfs worden uitgebreid tot bedrijfsbreed niveau. Dit ziet er als volgt uit:
Het shared service center zou bijvoorbeeld de infrastructurele diensten kunnen vertegenwoordigen. De backlog van dir shared service center zal grotendeels worden gevuld door aanvragen van de twee business georiënteerde waardestromen.
Als we opnieuw aannemen dat dit zeer grote waardestromen zijn met meer dan 15 teams elk, dan kunnen zij op hun beurt weer meerdere tribes bevatten. Dit maakt het fractal karakter compleet en ziet er als volgt uit:
Nogmaals, dit pure fractal karakter zul je in de praktijk nooit vinden. Maar wat ik hoop te benadrukken is dat er een totaal nieuwe manier van kijken naar de structuur van bedrijven is. Deze is product georiënteerd is en kan bestaan uit meer lagen, afhankelijk van de schaal en grootte van het betrokken bedrijf. En een echte wendbare organisatie zal per kwartaal kijken of deze structuur nog steeds werkt gezien de populariteit (en dus benodigde medewerkers voor innovatie en onderhoud) van hun producten portfolio. Zie daar de zich continu aan de omstandigheden aanpassende organisatie, de wendbare organisatie. Voor een andere blik op deze wendbaarheid zie ook mijn blog (Boston).
En nogmaals, ik benadruk dat het doel altijd moet zijn om de organisatie zo plat mogelijk te houden. Maar ik weet uit ervaring dat dit niet altijd mogelijk is in grote organisaties.
