Autonomie vs. Opdracht

In mijn laatste artikel heb ik geschreven over de afwegingen tussen de verschillende doelen van autonomie en externe sturing bij teams. Ik heb een aantal reacties ontvangen waarin stond dat dit een groot thema is binnen organisaties, en sommige mensen wilden er meer over weten – maar dan eerder vanuit een product- en designperspectief dan vanuit ontwikkeloogpunt. Het onderwerp is zeer veelzijdig en daarom leek het me de moeite waard om er dieper op in te gaan.

Hier zijn een aantal vraagstukken die ik wil behandelen:

• Wat als een team een nog betere kans ziet en besluit zich op een ander type klant te richten?
• Wat als een team het werk niet wil uitvoeren dat een groot bedrijfsinitiatief moet ondersteunen (bijv. internationalisering van het product)?
• Wat als een team ervan overtuigd is van koers te moeten veranderen om de kansen op de mobiele markt te benutten, terwijl het team slechts verantwoordelijk is voor een deel van het geheel?
• Wat als een team ervan overtuigd is over te moeten stappen naar een ander User Experience Design, ook al zou dat afwijken van wat de andere teams hanteren?

In elk van deze gevallen hebben team en management waarschijnlijk heel verschillende standpunten. Veel teams beweren dat ze – als ze echt zelfstandig mogen werken – zulke beslissingen kunnen nemen.

De problematiek

In gezonde teams en organisaties komt men normaal gesproken tot een compromis tussen deze twee standpunten, door het management de controle te geven over twee belangrijke punten in het besluitvormingsproces. Het eerste is de overkoepelende visie op het product en het tweede zijn de specifieke bedrijfsdoelen die aan elk team worden meegegeven.

Er kunnen echter problemen ontstaan wanneer het management deze twee belangrijke punten niet duidelijk genoeg formuleert, want dan ontstaat er een grijs gebied en is het niet meer helder wat het team zelf kan beslissen en wat niet.

De productvisie beschrijft het totaalplaatje van de doelklanten en de diensten die je elk type klant wilt bieden. Deze productvisie moet de bedrijfsstrategie ondersteunen. Als je bijvoorbeeld een bedrijfsstrategie hebt die gebaseerd is op een low-touch verkoopmodel (weinig persoonlijk klantcontact), bevordert dat een heel specifiek type productvisie. Als een team dan een product wil ontwikkelen dat afwijkt van de visie en dit model, wordt het behoorlijk lastig om het product op de markt te brengen.

De specifieke bedrijfsdoelen worden aan de teams gepresenteerd in de vorm van geprioriteerde KPI's (Key Performance Indicators – prestatie-indicatoren) – ook wel Product Scorecards genoemd – of in de vorm van OKR's (Objectives and Key Results), die eveneens neerkomen op verschillende KPI's. Als het bedrijfsdoel bijvoorbeeld is om het klantverloop aanzienlijk te verlagen, dan is dat de opdracht voor het team.

De teams krijgen de productvisie en de KPI's weliswaar van het management aangereikt, maar er wordt niet gezegd hoe ze deze moeten realiseren. Dat is het punt waarop het team autonoom en flexibel kan werken. Ik omschrijf sterke productteams graag als een werkgemeenschap voor het oplossen van moeilijke problemen. Het klantverloop verlagen kan absoluut een grote uitdaging zijn en er zijn waarschijnlijk ontelbare manieren om dit doel te bereiken. Hetzelfde geldt voor het verhogen van de "Customer Lifetime Value" (de waarde die een klant gedurende de gehele zakelijke relatie voor het bedrijf vertegenwoordigt) of het verlagen van de klantacquisitiekosten enzovoort.

Als productvisie en KPI's zijn vastgesteld, is het verschil tussen autonome teams en alle andere, of er een roadmap voor het bedrijf is of niet. Als het management of de stakeholders het team een lijst met verplichte features voorleggen, waar klanten en stakeholders al vast op rekenen, heeft het team weinig speelruimte om de beste oplossing te vinden voor de onderliggende bedrijfsvraagstukken (laat staan voor echt fundamentele thema's).

En precies daarom ben ik zo blij met de heropleving van OKR's. Als ze correct worden toegepast, helpen ze namelijk om deze situatie te verschuiven van output (features op roadmaps) naar outcome (bedrijfsresultaten).

2 bijzondere gevallen

Er zijn twee bijzondere gevallen die het vermelden waard zijn, omdat ze heel vaak voor spanning binnen het bedrijf zorgen.

Het eerste bijzondere geval heeft met design te maken. Er is geen twijfel over mogelijk dat het een enorme winst is voor een team en de klanten om een designer in elk team te hebben (die klantgerichte functionaliteiten verzorgt). Deze designers bouwen een hechte band op met hun product en de ontwikkelaars en zijn volwaardige teamleden. Bovendien proberen ze niet te werken volgens een model dat lijkt op een intern designbureau. Maar hoe zorg je ervoor dat de designers de ervaring voor alle gebruikers willen verbeteren en niet alleen voor de doelen van hun eigen team? De gebruikers hebben geen boodschap aan je teamstructuur. Maar hoe bevorder je zelfstandigheid en zorg je tegelijkertijd voor consistentie?

Hiervoor bestaan verschillende methoden – van het inzetten van een "Design Manager" (of Senior Designer), die het werk van alle designers controleert en goedkeurt, tot het zoveel mogelijk automatiseren met "Pattern Libraries", "Style Guides" en "Stylesheets".

Met het oog op zelfstandigheid en snelheid geef ik de voorkeur aan automatisering, omdat het team daarmee relatief eenvoudig en goed het design (Interaction en Visual) voor elkaar krijgt. Natuurlijk is er af en toe ook "Design Debt", d.w.z. we stellen vast dat het design herzien moet worden, en dat pak je aan zodra je het probleem hebt gesignaleerd. Ik vind deze aanpak prettig, omdat de Design Manager weliswaar nog steeds een groep goede designers samenstelt, maar niet meer bij elke kleinigheid aanwezig hoeft te zijn voor review (dat vertraagt alles en ondermijnt de autonomie).

Het tweede bijzondere geval zijn bedrijfsinitiatieven. Dat zijn de projecten die altijd meerdere teams omvatten. Een vrij veelvoorkomend geval is internationalisering. Een ander is het zogenaamde "Responsive Design". Weer een ander is het serieus nemen van de mobiele markt. Ik denk dat je begrijpt wat ik bedoel. In het beste geval sluiten deze initiatieven goed aan bij de geprioriteerde KPI's van elk team en vaak is er een concreet OKR-doel voor zo'n initiatief. Je moet je er echter van bewust zijn dat een belangrijk initiatief niet altijd ook een duidelijke winst is voor elk individueel team. Toch moet elk team zijn taak vervullen, anders mislukt het initiatief. Ik zeg dan altijd tegen de teams dat je soms gewoon je taak als onderdeel van het geheel moet vervullen. Het goede eraan is dat deze initiatieven echt geweldig zijn voor het product en de klant, dus we kunnen er in ieder geval tevreden mee zijn.

Conclusie over autonomie vs. opdracht

Als je teams dus niet het gevoel hebben voldoende eigenverantwoordelijkheid te hebben, dan moet je elk team een duidelijke productvisie en ondubbelzinnige, geprioriteerde bedrijfsdoelen meegeven. De daarin vervatte context is de opdracht van het team. Zorg ervoor dat de teams deze opdracht begrijpen en geef ze zoveel speelruimte als mogelijk om hun opdracht te kunnen vervullen.

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

Productvisie opstellen

=> Product Vision Canvas - De handleiding voor je productvisie.

Scrum Master Training

=> Word gecertificeerd Scrum Master bij de Agile Academy!

Agile metrics goed gebruiken

=> Welke kengetallen zou je als Scrum Master moeten kennen?