De meeste Agile-teams werken veel minder Agile dan je zou willen. Ze doen de taak die ze hebben aangevraagd, en dat is het. Zonde, want zo mis je een hoop creativiteit in je team.
En het ergste is: eigenlijk dwing je ze iets voor je te verbergen!
Ze schamen zich niet om het je te laten zien, maar je maakt het hen onmogelijk om het te laten zien!
Laat het me uitleggen:
Als je je team precies vertelt wat je wilt dat ze doen, dan doen ze dat! Ze stoppen bijna met zelf nadenken.
Wat is er nodig voor creativiteit?
Agile teams groeien als ze de mogelijkheid hebben om creatief te zijn; deze kracht zal voor je verborgen blijven, maar om die verborgen kracht te ontketenen, moet je ze motiveren!
SOPHIA Ontdek hoe je de aanpak van SOPHIA ook in jouw organisatie kunt doorvoeren om wendbaar en inclusief te organiseren. Download gratis de eerste 2 hoofdstukken van dit nieuwste boek.
Download de eerste 2 hoofdstukken
De wijsheid van wendbare organisaties
In de meeste organisaties fungeren Product Owners als managers of teamleiders. Ze vragen het team niet om een probleem op te lossen, maar vertellen het team welke acties moeten worden ondernomen.
En zo missen die Product Owners het hele voordeel van een echt Agile team.
In plaats van gebruik te maken van de creativiteit en kennis van een heel team, proberen ze zelf de oplossing uit te zoeken en het praktische werk te delegeren.
In die gevallen gebeuren er een paar dingen:
- De Product Owner heeft veel werk te doen. Zij moeten het stakeholder-management doen en daarnaast ook de oplossingen bedenken;
- Teamleden raken gedemotiveerd omdat ze alleen het eenvoudige werk doen; het echte denken is al gedaan;
- De kwaliteit van het product kan beter. Het is in de eerste plaats zo goed als de oplossing die één persoon kan bedenken;
- Er is minder innovatie omdat de Product Owner het te druk heeft om de tijd te nemen om over alle mogelijkheden na te denken;
- Teamleden raken ontevreden omdat ze weten dat er veel betere oplossingen zijn om de problemen op te lossen;
Ik zal je laten zien wat ik vaak zie gebeuren.
Een team is verantwoordelijk voor de website van het bedrijf. De marketing manager ziet een daling in de online verkopen en vroeg de Product Owner iets te doen om de website-conversie met 20% te verhogen.
De Product Owner begint met het opstellen van een plan om de laadtijden te versnellen, stelt een nieuwe navigatiestructuur voor en ontwerpt de productpagina's volledig opnieuw.
“Klinkt goed”, zegt de marketingmanager.
Dat is ‘go’ voor de Product Owner, dus hij begint met een aantal User Stories:
- Als marketeer wil ik dat alle CSS-bestanden op de website worden verkleind, zodat de sitesnelheid toeneemt;
- Als klant wil ik een eenvoudiger navigatie, zodat ik meer producten kan vinden (en kopen);
- Als klant wil ik een nieuw ontwerp van de productpagina's, zodat deze er voor mij aantrekkelijker uitzien;
Er zijn veel meer User Stories om te delen, maar je begrijpt wel wat ik bedoel.
Het team heeft de User Stories in no-time voltooid.
Na een maand is de marketingmanager woedend. Er is geen sprake van een stijging van de omzet. Erger nog, de omzet daalde met 2% extra!
Het team was teleurgesteld na al het werk dat ze hiervoor gedaan hebben. En dit hadden ze nog zien aankomen ook!
Het probleem was helemaal niet de sitesnelheid, navigatie of ontwerp.
Het team bekeek de gegevens en zag dat 50% van de klanten wegging tijdens het afrekenen. Het afreken-proces bestond uit te veel stappen.
Maar in plaats van het team te vragen een oplossing te bedenken voor de omzetdaling, bedacht de Product Owner die zelf. En ze maakten die oplossingen op basis van verkeerde aannames.
Dus wat er gedaan het moeten worden, was het team vragen vanaf het begin wat ze van het probleem vonden.
En dat had de Product Owner veel tijd bespaard!
Hij hoefde slechts één User Story te creëren:
“Als Marketing Manager wil ik een stijging van de online verkopen met 20%, zodat we geen geld meer verliezen.”
Met deze User Story, een blik op de gegevens van het team en hun input, kwamen ze waarschijnlijk met zoiets als ‘het afreken-proces verkorten’.
Het team zou gemotiveerder zijn om aan deze oplossing te werken, wat de Product Owner veel minder tijd zou kosten, en de oplossing zou veel beter zijn.
Nog een neveneffect: het team moet veel herstelwerk verrichten om de problemen op te lossen die zijn ontstaan door de implementatie van de eerste oplossing. Werk dat het team überhaupt niet had mogen doen!
Wil je de echte kracht van groepskennis en creativiteit ontketenen? Geef je team dan problemen die ze kunnen oplossen in plaats van oplossingen die ze moeten bouwen.
Deze manier van werken bespaart je tijd, resulteert in betere resultaten, verhoogt het teammoreel en bespaart je veel geld!