Autonomie vs. Initiatief

Om de serie over autonomie van teams voort te zetten, wil ik na Autonomie vs. Opdracht nog dit belangrijke aspect aan het onderwerp toevoegen. Het gaat hierbij om de gevolgen die grote initiatieven met veel teams in de praktijk hebben.

Wat is een initiatief?

Als ik "initiatief" zeg, bedoel ik daarmee de werklast voor een product waarbij veel teams betrokken zijn. Dat kan bijvoorbeeld zoiets zijn als: het verbeteren van de gebruiksvriendelijkheid van een website, de overstap naar Responsive Design, een internationalisering of het betreden van belangrijke nieuwe markten zoals China. Het zijn stuk voor stuk behoorlijk belangrijke zaken, maar ze vereisen normaal gesproken de gezamenlijke inspanning van meerdere – zo niet alle – productteams.

In principe is het herontwerpen van een platform voor betere schaalbaarheid of prestaties – zoals bijvoorbeeld een nieuwe architectuur of nieuwe technologische basis – ook een soort initiatief. Met deze technische schuld ga je echter anders om, en daarom ga ik daar in dit artikel niet op in.

Laten we even buiten beschouwing laten of het in principe een goed of slecht idee is om een bepaald initiatief uit te voeren. Dat onderwerp heb ik al in een ander artikel behandeld. Laten we hier gewoon aannemen dat het initiatief een goede en belangrijke zaak is. Ik wil de drie mogelijkheden bespreken hoe teams met deze grote en complexe initiatieven kunnen omgaan.

Het gaat om het volgende: per definitie hebben we een complex project waar we ons om moeten bekommeren en waarbij veel teams betrokken zijn. Elk team heeft zijn eigen details uit te zoeken, maar de vraag is wie dit allemaal leidt en hoe. Als het bij het initiatief gaat om het productaanbod aan te passen aan de Chinese markt, sturen we dan elk afzonderlijk team naar China om uit te zoeken wat er gedaan moet worden? Dat zou niet erg zinvol zijn en hoogstwaarschijnlijk zou elk team met een andere oplossing komen.

Strategie 1: Een leidend team

In de meeste gevallen wordt een van de teams uitgekozen om de hoofdrol op zich te nemen en het initiatief te leiden, dus de leiding over Discovery en Delivery te nemen. Uiteraard is dit team afhankelijk van het werk van de andere teams, maar het leidt en coördineert deze werkzaamheden ook. Het zou bijvoorbeeld een groep klanten identificeren om samen met hen de noodzakelijke veranderingen aan het product te bepalen, en daarna helpen om de benodigde werkzaamheden (Discovery en Delivery) op te splitsen en aan te pakken.

Voordelen van deze aanpak zijn het duidelijke verantwoordelijkheidsgebied en eigenaarschap. Uiteraard moet je proberen een leidend team te kiezen waarop dit werk een grote impact heeft.

Er is echter ook een nadeel aan deze aanpak. Als het leidende team namelijk niet voortdurend de andere teams informeert over nieuwe inzichten en beslissingen, zullen ze deze beslissingen niet kunnen begrijpen of er bezwaar tegen maken zodra het werk verdeeld moet worden. En op dat punt wordt autonomie echt een uitdaging.

Strategie 2: Een tijdelijk team

Bij deze aanpak wordt geen van de bestaande teams belast met het leiden van het initiatief. In plaats daarvan wordt er speciaal (voor de duur van dit initiatief) een tijdelijk Discovery Team gevormd dat zich dan tenminste om de Discovery-werkzaamheden bekommert. Normaal gesproken bestaat zo'n team uit een Product Owner, een leidende UX Designer en minstens één leidende ontwikkelaar. Zodra deze groep de benodigde Delivery-werkzaamheden heeft geïdentificeerd en Backlog Items heeft aangemaakt, gaan de leden van dit tijdelijke team terug naar hun eigenlijke teams.

Het voordeel hierbij is dat je een sterk team hebt met toegewijde mensen die zich op dit werk kunnen concentreren. Het nadeel is dat deze mensen relatief snel weer teruggaan naar hun eigen teams. Dat is eigenlijk iets goeds, omdat ze hun teams dan kunnen vertellen wat ze geleerd en besloten hebben. Maar dan is er ook geen duidelijk eigenaarschap meer. En ook hier bestaat het risico dat de andere teams niet begrijpen of het niet eens zijn met wat hen verteld wordt. Een bijkomend nadeel is dat je door mensen uit hun teams te halen het doel van stabiele teams ondermijnt.

Strategie 3: Een verenigd team

De derde mogelijkheid om deze initiatieven aan te pakken is iets dat ik normaal gesproken niet aanbeveel. Ik moet het echter noemen, omdat het af en toe voorkomt. Bij deze aanpak slaan enkele teams (niet noodzakelijkerwijs allemaal) de handen ineen om de Discovery-werkzaamheden gezamenlijk uit te voeren.

Het grote voordeel hiervan is dat alle nieuwe informatie gedeeld wordt, en dat is van zeer grote waarde.

Het grootste nadeel is echter dat er veel personen betrokken zijn bij de besluitvorming, en te veel koks bederven de brij.

Conclusie over Autonomie vs. Initiatief

Waarvoor je ook kiest, je moet een oplossing voor het initiatief vinden en ook uitvoeren. Dit zijn de drie mogelijkheden hoe teams hiermee om kunnen gaan. Je kunt moeilijk zeggen dat een ervan wat betreft autonomie beter is dan de andere, want bij een initiatief gaat het er uiteindelijk om iets goeds te doen voor de organisatie, en niet noodzakelijkerwijs om hoeveel beslissingsvrijheid de individuele teams hebben. Misschien is het treffender om te zeggen dat je een van deze aanpakken kunt kiezen om zo het gevoel van autonomieverlies te minimaliseren.

Onthoud dat deze initiatieven vaak uiterst waardevol zijn voor onze klanten en ons bedrijf, dus er is ontzettend veel om trots op te zijn als je dit initiatief succesvol afrondt.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.