plof

vlomp

Improv inzetten om voor een Agile Mindset te zorgen

Zodra ik begreep hoe motivatie werkt en hoe onze industrie ons richting een responsieve mindset heeft geduwt, begon ik mijn zoektocht naar manieren om voor een gezonde mindset te zorgen. Om voor motiverende omgevingen te zorgen op de plekken waar ik werk. Mijn eerste ontdekking was Improv.

Improv laat ons zelf onze soft skills ontwikkelen

Improv is een open format dat ons de ruimte geeft om onze soft skills te ontwikkelen, met name:

  • Scherpte
  • Communicatie
  • Teamwork
  • Luisteren
  • fail-fast houding

Belangrijk hierbij is dat het de ruimte geeft. Improv moet nooit gebruikt worden om mensen te forceren om iets te leren. Mensen die meedoen zullen voor zichzelf bepalen of en welke softskills zij willen ontwikkelen (dit gebeurd meestal onbewust). Onbewust omdat mensen vanuit zichzelf al een vaag idee hebben over welke soft skills belangrijk voor hun zijn, en welke zij leuk vinden. Omdat mensen een intrinsieke drijfveer hebben om skills te leren die relevant zijn voor hun omgeving, zullen mensen zoeken naar soft skills die voor henzelf en hun omgeving belangrijk zijn.

Gebruik korte Improv Sessies om mensen actief te betrekken in workshops

Improv hoeft niet altijd om 1-2 uur lange workshops te gaan.  Je kunt ook korte sessies van 15-30 minuten organiseren, voordat je begint aan een interactieve training of workshop. Hierdoor kun je Improv gebruiken om:

  • Mensen in een actieve/assertieve mindset te krijgen
  • Energizer!
  • Groeps kennismaking
  • Mensen fouten te laten durven maken

Organiseer je eigen Improv sessies met deze oefeningen

Ik heb een pdf gemaakt met Improv oefeningen die je kunt gebruiken om je eigen Improv sessie te organiseren. Deze is wel in het engels.

Improv-exercises

Agile is een geloof aan het worden

Zoals ik in mijn blog post over perspectieven zeg, zijn er geen echte waarheden, maar alleen perspectieven. Geloof is een perspectief voor de mensen die hierin geloven. Deze groep zal dit zien als hun ‘waarheid’.

Als Agile Test Coach binnen de IT, werk ik veel met Agile. Maar sinds een paar jaar begin ik me zorgen te maken over Agile werken. Het begon als een inspirerende visie om op de juiste manier software te maken. Maar het lijkt erop dat ieder jaar Agile meer en meer wordt gezien als de ‘waarheid’. Regelmatig vertelt een collega of manager mij dat wij een bepaalde techniek of methode moeten hanteren, omdat dit ‘Agile’ is…

Maar… maar… Wat is ‘Agile’ nou voor argument? Dat is ongeveer hetzelfde als zeggen dat wij nu allemaal kaas moeten eten, omdat kaas!

En toch doen steeds meer mensen dit. Steeds meer mensen gebruiken Agile als een waarheid hoe wij moeten werken, zonder ons af te vragen waarom? En toen besefte ik het me…

Agile begint een geloof te worden

Agile begint steeds meer karakteristieken te vertonen van een geloof. Aanhangers van Agile voelen zich persoonlijk aangevallen als jij ze vraagt wat de toegevoegde waarde is van het SAFe framework. Medewerkers en managers voeren nieuwe methodes en technieken in, omdat ze ‘Agile’ zijn. Wat zelfs in tegenstrijd is met de values van Agile…

Ik hou van Agile. Met heel mijn hart. Maar de gedachte dat Agile een geloof wordt, breekt mijn hart.

Laten we gewoon weer eens gaan nadenken. En doordachte keuzes maken. In plaats van alles maar doen omdat Agile.

Waarom zijn wij een marathon aan het sprinten?

Enkele jaren geleden had ik een discussie met een collega over Scrum. Scrum is een framework om software op te leveren. Zelf ben ik een groot voorstander, maar hij kwam wel met een ongelofelijk goed argument tegen Scrum.

De naam sprint. Blijkbaar lever je software in sprints op. Een zin zoals dit is ondertussen normale taal geworden binnen de IT, zelf dacht ik er ook nauwelijks over na. Maar zodra je er beter over gaat nadenken, is dit volstrekt belachelijk. Want Scrum is ook een framework dat zich richt op iteratief, kleine stukjes software opleveren. Want software is tenslotte nooit af, er kan altijd wel iets verbeterd worden. Daarom is het belangrijk dat je zo snel mogelijk een minimale versie van de software oplevert, en deze daarna stap voor stap verbeterd. Op basis van de wensen van de markt. Want zo zorg je ervoor dat je waardevolle software maakt. Door continu kleine stukjes op te leveren en te controleren of iedere aanpassing voldoet aan de wensen van de markt.

Maar hiermee zeggen wij dus eigenlijk, dat software onderhouden nooit af is, en vergelijken zou zijn met een marathan. Maar alsnog werken wij in ‘sprints’ om software te schrijven. Onderbewust ontstaat hierdoor de misopvatting: dat wij continu een marathon aan het sprinten zijn.

Dat kunnen wij niet. Dat kan niemand. En dat is voor een deel het probleem waar veel IT organisaties tegenaan lopen. Zij verwachten echt dat developers de marathon blijven sprinten.

Laat ik maar even met het verlossende woord komen:

Als je over een lange periode je software wilt blijven onderhouden, moet je niet te sprinten!

Dus hierbij nog een oproep naar alle developers: stop met sprinten! Kijk naar de toekomst en doe het eens rustig aan! Want anders ben jij de volgende met een burn-out!

Agile draait niet om snelheid

Binnen IT wordt Agile als methode vaak ingezet voor ‘Maximizing Value’. Mijn theorie is dat dit een gevolg is van de volgende agile principe:

Working software is the primary measure of progress.

Naar mijn mening is dit principe verkeerd. Het gaat namelijk niet om werkende software! Het gaat om waarde leveren!

Voorbeeld van waarde toevoegen

Ik kan me nog goed een IT project herinneren waar wij als team gevraagd werden om een kleine aanpassing te maken in een complex scherm. Nadat wij naar de code hadden gekeken en enkele testen hadden uitgevoerd kwamen wij tot de conclusie dat het huidige scherm onwerkbaar was geworden. Dit scherm werd vervolgens omgedoopt tot ‘de draak’ van de applicatie. Met name omdat dit scherm een ongelofelijk zwaar en groot monster was geworden, waar je niet aan wilt komen. Want dat zal zomaar je leven kunnen kosten.

Als reactie gaven wij aan dat wij de aanpassing konden maken, mits wij daar 3 sprints de tijd voor zouden krijgen, om het scherm te refactoren (op te schonen). Met een beetje moeite ging de business gelukkig hiermee akkoord. Het heeft ons 3 sprints gekost om de aanpassing door te voeren, maar het is ons gelukt. We hadden de minimale aanpassing eindelijk opgeleverd.

Stukje context: dit scherm werd eenmaal per jaar gebruikt om berekeningen te kunnen maken, en ieder jaar resulteerde dit gebruik in vele duizenden klachten en vele uren extra werk voor de medewerkers die dit scherm bedienden.

Nadat wij de aanpassing hadden opgeleverd, en het scherm nogmaals werd gebruikt, kregen wij als team feedback hierover… Door de extra tijd die wij hierin hadden gestopt, was het aantal klachten en de extra uren die hierin gestopt moesten worden, verlaagd met ongeveer 90%!

Dit was niet het doel van de user story, maar is bereikt enkel en alleen maar vanwege het daadkrachtige optreden van het team. Dit is waarde toevoegen!

Om nogmaals de slogan van m’n blog te herhalen: ‘Screw efficiency, let’s focus on what really matters!’.

Het gaat niet om snel software op te leveren, het gaat om waarde toe te voegen!

Agile werken gaat namelijk niet om zo snel mogelijk user stories opleveren! Het gaat om waarde toevoegen! En één goed uitgewerkte user story, kan in veel gevallen meer waarde toevoegen dan vier redelijk uitgewerkte user stories!

Deze fout wordt nog steeds door veel teams gemaakt. Met name omdat de meest gebruikte meetinstrumenten worden ingezet om het aantal user stories bij te houden! Het is namelijk veel moeilijker om echte waarde bij te houden!

Het framework Scrum gebruikt velocity als voornaamste meetinstrument. Velocity is de hoeveelheid werk dat het team verzet. Maar naar mijn mening is dit een volstrekt nutteloze metric. Dit pusht mensen om zoveel mogelijk troep naar productie op te leveren, in plaats van waardevolle veranderingen.

Sorry, maar naar mijn mening zijn meetinstrumenten zoals velocity  complete troep.

Hoe dan wel?

Om deze blogpost toch even met een duw in de juiste richting af te sluiten, geef ik ook nog wel een tip om het wel goed te doen.

Het meetinstrument dat jij zichtbaar gebruikt binnen je team, wordt vanzelf hetgeen waar het team zich op zal richten en op afgerekend zal worden. Simpelweg omdat het zichtbaar is.

  • Als het aantal gebruikers per dag dagelijks op een dashboard wordt weergegeven, zal het team zich vanzelf gaan richten om dat aantal te verhogen.
  • Als jij metrics op het dashboard toont van het aantal foutmeldingen in productie, zal het team zich gaan richten om dat aantal te verlagen.

Als je waarde wilt toevoegen, moet je ‘waarde’ concreet maken en ervoor zorgen dat dit zichtbaar gemeten wordt. Dan zal het team zich hier vanzelf mee bezig houden.

Space-map

Dit is de Space-map: een ‘map’ om motivatie problemen binnen een organisatie te pinpointen en te kunnen bespreken. De map bestaat uit generieke ‘work factors’ die nodig zijn om voor een motiverende werkomgeving te zorgen.

Hierdoor heb je het niet meer over vage motivatie problemen, maar over een probleem met autonomy.

De space-map heb ik ontwikkeld in mijn tijd bij Xebia, samen met een paar collega’s.

Het onderscheid tussen Motivatie en hygiene zou je als volgt kunnen vertalen:

Zie een motiverende omgeving als een auto, dan is de motivatie de motor en hygiene zijn de banden.
Het heeft geen zin om de motor te verbeteren, zolang de banden nog niet rond zijn.

Waar de space-map zich NIET op richt
  • Gebrek aan specialistische kennis (hoe kunnen wij performance testen?).
  • Een onjuiste balans in het team (5 frontend developers die een nieuwe api gaan ontwikkelen).
  • Persoonlijke problemen (sommige mensen worstelen met grote problemen in een thuissituatie en zijn daarom niet in staat om zich in te zetten voor een grotere ‘purpose’).

Hygiene

De Hygiene factoren zijn factoren die niet direct helpen bij de motivatie, deze werken je alleen maar tegen. Dit zijn factoren die met name opvallen als ze er niet zijn. In het begin zullen mensen hier vooral over klagen, maar na verloop van tijd kan dit ook leiden tot verhoog in ziektes, en in meer mensen die ontslag nemen.

Psychological Safety

Sinds het onderzoek van google is hier op internet onzettend veel over te vinden. Dus ik zal het hier houden op de minimale beschrijving: Het creëren van een positieve werksfeer.

Zie ook:

Assurance

Mensen hebben ook zekerheid en duidelijkheid nodig. Zekerheid van hun baan. Maar dit houdt ook in dat verwachtingen op de werkvloer duidelijk zijn. Als verwachtingen op de werkvloer niet duidelijk zijn, geeft dit minder zekerheid over het werk dat je doet. Doe jij je werk wel goed? Durf jij daar gemakkelijk ‘ja’ op te zeggen? Daarnaast gaat dit ook over de zekerheid van jouw functie in de markt. Heb jij een gezonde dosis aan competenties en skills, zodat jij zelfs bij ontslag vrij gemakkelijk aan een nieuwe baan kan komen? Dan zal de zekerheid of jij je baan bij je huidige werkgever kan houden, minder relevant worden.

Compensation

Het gaat hierbij of mensen eerlijk worden gecompenseerd. Verdien jij genoeg voor het werk dat je doet? En krijg je ook de juiste verantwoordelijkheid? Dit wordt met name een gevoelige kwestie als je met mensen samenwerkt die meer verdienen, maar minder werk verrichten. Of mensen die een hogere functie dan jou bekleden, terwijl zij er nauwelijks verstand van hebben. Maar je kunt ook mensen spreken op feestjes en conferenties die hetzelfde werk doen als jij, maar hier 1000,- bruto meer verdienen per maand. Dit zal ook meespelen in het gevoel of jij wel voldoende betaald krijgt.

Environment

Beschik jij over de juiste middelen om je werk goed te doen? Heb jij een eigen werkplek, of moet jij iedere ochtend vroeg in de file staan om een plek te bemachtigen, omdat jou organisatie weer wat leuks heeft gehoord over ‘flexwerken’? Het gaat hier met name over zaken die direct met het werk dat jij doet te maken hebt, zoals of jij toegang hebt tot de juiste software en goeie pc’s / laptops met mooie schermen? Maar daarnaast ook de simpelere zaken zoals printers, koffie, overlegruimtes en whiteboards met markers.

Alles dat je ooit nodig zou kunnen hebben om je werk zo goed mogelijk te kunnen doen, speelt hier een rol.

Motivatie

In tegendeel tot hygiene, helpen Motivatie factoren mensen vooruit. Als deze factoren er niet zijn, zul je hier weinig mensen over horen klagen. Als hier echter wel tijd in wordt gestopt, zul je zien dat dit impact heeft op de productiviteit van mensen. Maar nog belangrijker, de zelfstandigheid van mensen. Dit zijn namelijk ook de factoren van Intrinsieke Motivatie, die voor zelfstandig gedrag zorgen (lees Self Determination Theory).

Mastery

Om anderen goed te kunnen helpen, is het belangrijk (en fijn) om je eigen individuele set aan competenties en skills te hebben, en deze ook continu te verbeteren, waardoor je anderen ook steeds beter kunt helpen. Het is juist jou unieke combinatie aan competenties en skills die jou bijdrage zo waardevol maakt!

Autonomy

Voor veel mensen is ‘Ja’ zeggen vrij makkelijk. Maar niet altijd het juiste antwoord. Autonomy draait om het juiste doen. Als expert van jou vak, weet je vaak beter hoe jij je werk kan doen, dan je managers. Daarom is het belangrijk dat jij zelf bepaalt hoe jij je werk doet. Maar dit houdt ook in dat je soms tegen anderen in moet gaan, om uiteindelijk voor het beste resultaat te zorgen. Veel mensen zullen jij uiteindelijk respecteren hiervoor, en je meer vertrouwen en ruimte geven in het vervolg. Maar je moet dit wel durven.

Als je volgens Agile werkt in de IT wereld, is het team verantwoordelijk voor de kwaliteit. Veel mensen zullen druk leggen om zoveel mogelijk functionaliteit op te leveren, maar het is belangrijk dat het team regelmatig ‘nee’ zegt, om voor de juiste kwaliteit van de software te kunnen zorgen. Autonomy draait erom dat wij de juiste keuzes willen maken, en dat wij daar soms harde keuzes voor moeten maken. Het is de vrijheid om het juiste te doen.

Purpose

Om anderen te kunnen helpen, moet je ook weten hoe je ze kan helpen. Je hebt richting nodig. Deze richting moet gegeven worden door iemand met een visie, zodat wij ons hierachter kunnen schuilen. Niet zozeer omdat wij zelf geen visie kunnen bedenken, maar omdat wij een eenduidige visie nodig hebben waar wij als team achter kunnen staan. Een eenduidige visie waar wij voor ons bed uit willen komen. Alleen dan kunnen we ervoor zorgen dat alles dat wij doen ook daadwerkelijk bijdraagt aan het product.

De Mastery Curve – hoe wij onszelf ontwikkelen

In de game industrie wordt de ‘Mastery Curve’ gebruikt om de leercurve van spelers aan te duiden. Binnen deze industrie is het namelijk ontzettend belangrijk om te beseffen hoe spelers groeien. Want anders raak je spelers kwijt tijdens het spelen. Een beginnende speler heeft namelijk heel andere stimuli nodig dan iemand die al meer dan 100 uur in het spel heeft zitten.

Deze industrie heeft daarom veel grip op deze vorm van motivatie. Vandaar dat ik ook deze theorie hier wil behandelen.

De Mastery Curve leert ons twee dingen:

  1. Wij groeien niet constant. Af en toe krijgen wij ingevingen waardoor wij onszelf razendsnel iets nieuws aanleren, maar los daarvan groeien wij tergend langzaam, en vaak voor lange periodes helemaal niet.
  2. Ons leerproces is een exponentiele curve. Hoe beter wij worden, des te trager zal ons groeiproces gaan. Uiteindelijk is het onmogelijk om iets voor ‘100% te masteren’.

Zoals je in de onderste grafiek ziet, kan je voor een lange tijd (maandenlang) het gevoel hebben dat je niet verder groeit, maar dat hoort erbij! Zolang je niet opgeeft zul je uiteindelijk weer verder groeien.

En zodra je over die eerste paar drempels heen weet te komen, zal je kennis op een gegeven moment een enorme groeispurt maken. Dit is omdat: hoe minder je weet, des te meer je nog kunt leren. De andere kant is daarom ook waar: als je al behoorlijk bedreven bent in een bepaald onderwerp, zul je ook merken dat het moeilijker wordt om nieuwe dingen te leren. Simpelweg omdat er minder te leren valt.

Hierdoor wordt het ook belangrijk dat je iets leuk vindt om te doen. Of je er nou iets van leert of niet. Ik ben zelf jaren geleden begonnen met gitaar spelen. Destijds vond het ik het leuk, ik leerde continu nieuwe technieken en het begon steeds meer ergens op te lijken. Maar tegenwoordig leer ik steeds minder nieuws en wordt ik toch met de neus op de feiten gedrukt: gitaar spelen zonder dat ik iets leer, vind ik niet leuk! En daarom doe ik het bijna niet meer tegenwoordig.

Maar dit kun je ook als iets inspirerends zien. Niemand kan ooit iets voor 100% masteren. Zodra ik afgestudeerd was keek ik enorm op tegen sprekers die op grote conferenties hun verhaal mochten doen. En twee jaar later werd ik uitgenodigd op een conferentie. Simpelweg omdat ik niet opgaf en doorgroeide, en nog belangrijker: omdat ik het leuk vond om presentaties en workshops te geven!

Flow – de beste manier om jezelf te ontwikkelen

Csikszentmihalyi schrijft in zijn boek over de staat van ‘flow’. Als iemand in deze ‘state of flow’ zit, gaat hij volledig in zijn eigen bezigheden op.

Als je hierin zit, kan je zonder klachten door blijven groeien. En nog belangrijker, het voelt goed!

Deze ‘state’ bereik je door de juiste balans te vinden tussen de uitdaging van het werk dat je doet, ten opzichte van jou eigen skill niveau.

Zodra je niet in flow bent, zal het werk vaak voor problemen zorgen.

  • Anxiety. Als je bijvoorbeeld aan iets werkt waarbij de uitdaging te hoog ligt voor jou huidige skill niveau, zul je angstig worden. In deze situatie zal je onder druk komen te staan en stress ervaren. Als je dit lang probeert vol te houden, kan dit tot fysieke klachten leiden zoals overspannen of zelfs een burnout.
  • Boredom. Maar als je aan een taak werkt die te makkelijk voor jou is, raak je verveeld. Het meest directe gevolg hiervan is dat mensen vaker fouten gaan maken, simpelweg omdat het werk niet serieus genoeg genomen wordt. Maar dit kan ook tot demotivatie leiden over een langere periode, met name omdat je niet meer groeit en geen nieuwe dingen meer leert.

De beste manier om jezelf te ontwikkelen, is door in een ‘state of flow’ te verblijven

Mastery – De beste versie van jezelf worden

Ik was 21 jaar oud. Ik had net mijn MBO papiertjes binnen, het was nacht en ik was met een paar vrienden de stad aan het verkennen. We waren aan het vieren dat we net afgestudeerd waren en hadden geen zin om naar huis te gaan. Na een paar uurtjes verdwalen kwamen we uit op dit groot spook huis. We zagen een slank figuur bij de poort staan. Hij keek ons direct aan en vroeg uitnodigend “Would you like a tour?”. Ik keek naar mijn vrienden, maar toen nam mijn nieuwsgierigheid het over en ik liep achter de man aan, het spookhuis in. Zonder te weten wat hier zou kunnen gebeuren.

Ik heb verschillende domme dingen in mijn leven gedaan, zoals het voorbeeld hierboven. Op het moment zelf wist ik maar al te goed wat ik deed, maar mijn nieuwsgierigheid nam simpelweg over. Ik wilde iets ontdekken, het liefst door hier een spannend verhaal aan over te houden.

Maar of je nou houdt van risico’s nemen en van domme dingen doen, of liever rustig een boek pakt om kennis te vergaren, we hebben allemaal diezelfde drijving om te leren, om te groeien. Om te beste versie van jezelf te worden. Dit noemen we ‘Mastery’ en is het onderwerp van deze blog post.

Mastery of Competence

De term ‘Mastery’ voor motivatie is in het leven geroepen door Dan Pink, met zijn boek Drive. De oorspronkelijke motivatie theorie (Self Determination Theory) gebruikt echter een andere term: compentece. Met beide woorden wordt hetzelfde bedoelt, maar:

  • Mastery legt de nadruk op de beste zijn (be the master).
  • Competence legt de nadruk dat je skills relevant moeten zijn (je bent competent in je omgeving).

Zoals altijd ligt de waarheid hier in het midden. We zijn allemaal gemotiveerd om beter te worden, het liefste de beste. Maar dan wel met skills die relevant zijn in jou omgeving.

Voorbeeld: Als ik een presentatie geef over noodles maken bij mijn IT klant, verwacht ik een lage opkomst. Maar als ik vertel over hoe noodles mij inzicht hebben gegeven in software code, kan ik een hogere opkomst verwacht. Mensen zullen een hogere motivatie hebben, omdat zij verwachten dat zij hier iets van leren dat relevant is voor hun werk.

Photo by Rita Morais on Unsplash
Photo by Rita Morais on Unsplash

Organiseer een motiverende omgeving gebaseerd op mastery

Het belangrijkste ingredient voor een motiverende omgeving, gebaseerd op mastery, is het creëren van een platform waar mensen kunnen leren. Belangrijk hierbij is om deelnemers een X hoeveelheid tijd vrij te laten maken om op locatie Y af te spreken, met het doel om kennis op te doen en te delen. De meest effectieve manier is door een structureel vast moment te plannen voor dit platform. Enkele voorbeelden zijn:

  • Innovation Days. Eén dag in de 6 weken, waar werknemers zelf bepalen waar zij aan werken. Zolang ze hun opgedane kennis aan het eind van de dag delen aan de rest van de groep.
  • Lunch Sessies. Het houden van presentaties of brainstorms tijdens lunch. Deelnemers kunnen belangrijke onderwerpen aandragen, of filmpjes voorstellen om naar te kijken.
  • Morning Study. Waarbij alle werknemers iedere ochtend een uur de tijd hebben om vakgerelateerde literatuur te lezen, TED filmpjes te kijken, of te discussieren over nieuwe best practises.

Wat kan jij zelf doen?

Ieder individu kan een verschil maken. Met de volgende simpele tricks kan jij meehelpen met het creëren van een motiverende omgeving gebaseerd op mastery, zonder een heel platform te hoeven organiseren.

  • Vraag om en geef feedback. Feedback is de belangrijkste techniek om erachter te komen of kennis relevant is voor jou omgeving. Door feedback te geven, motiveer jij anderen om meer te leren, of juist een nieuw onderwerp op te pakken. En door feedback te ontvangen leer jij hoe je jou kennis beter kunt gebruiken binnen je omgeving.
  • Doe, faal en leer. Experimenteren (en fouten maken) is de beste manier om te groeien en nieuwe dingen te leren. Daarnaast is het een feit dat wij allemaal fouten maken. De slechtste manier om hier mee om te gaan is door deze fouten te negeren. Als jij alleen de snelste manier naar de bushalte kent, heb je weinig kennis van de omgeving. Wellicht mis jij een adembenemend uitzicht in je buurt.

Dus wat jou rol binnen het bedrijf ook is, ook jij kan meehelpen om een motiverende omgeving op te zetten, gebaseerd op mastery. Simpelweg door feedback te vragen en te geven, en door te experimenteren.

En wat betreft het spookhuis… Onze gids was ons de hele tijd voor de gek aan het houden en ons bang te maken. Maar wij deden mee tot het einde van de tour, en tot slot keken wij nog samen naar een Phil Collins DVD. Het spookhuis was prachtig en we hebben veel nieuwe geschiedenis lessen gekregen over de VOC tijd.

Autonomy – zelf aan het stuur staan

Ik weet nog dat de Product Owner onze kamer in stapte met een nieuwe user story. He vroeg of we een kleine aanpassing in één van onze schermen konden maken. Wat hij nog niet wist was dat niemand van ons de code begreep, of de stoffige documentatie die hierover geschreven was. Nadat wij een paar testen hadden uitgevoerd kwamen wij er zelfs achter dat de helft van de features op deze pagina niet werkten. We stelden het volgende voor: wij implementeren deze user story als wij drie extra weken krijgen om dit scherm te herbouwen en de documentatie te herschrijven. Gelukkig toonde onze awesome Product Owner begrip voor onze situatie en we kregen deze extra weken.

Dit type motivatie noemen we ‘autonomie’ en is het onderwerp van deze blog post. Autonomie is de behoefte om zelfstandig besluiten te nemen, de vrijheid om zelf te bepalen hoe wij dingen doen. Op werk kan dit gezien worden als het juiste willen doen, in plaats van wat er van ons verwacht wordt.

Autonomie is afhankelijk van de andere twee type motivatie factoren: Mastery and Purpose. Naar mate wij competenter (mastery) worden en erachter komen wat onze omgeving wilt bereiken (purpose), zijn wij beter in staat om te bepalen wat de grootste problemen zijn in onze omgeving en hoe wij deze willen oplossen. En dat is waar autonomie uiteindelijk om draait: de behoefte om het juiste te doen, op de juiste manier.

Vergeet verantwoordelijkheid niet

Autonomie gaat niet alleen om de vrijheid om dingen op de juiste manier te doen. Want met vrijheid krijgen wij de macht om onze omgeving te veranderen. We moeten nooit de wijze woorden vergeten van oom Ben: “Met grote kracht komt grote verantwoordelijkheid”. En met de macht van vrijheid, komt ook verantwoordelijkheid.

Dit is een veel voorkomend probleem binnen IT organisaties. Met de opkomst van Agile, willen veel organisaties hun teams meer vrijheid geven met de verwachting dat hier betere software uit komt. Maar als teams geen verantwoordelijke beslissingen maken of niet voldoen aan verwachtingen van stakeholders, raken zij langzamerhand het vertrouwen kwijt van deze stakeholders en de organisatie zelf.

Hoe motiveer je op basis van autonomie

Autonomie is de meest complexe factor in het creëren van een motiverende werkomgeving. Met name omdat de behoefte aan autonomie wordt beinvloed door de andere factoren: mastery en purpose van de werknemer. Hierdoor verschilt de behoefte aan autonomie per persoon, maar varieert deze ook over tijd. En tot slot is het persoon die autonomie geeft, nooit dezelfde als degene die autonomie nodig heeft. In de meeste gevallen moeten managers autonomie geven aan hun werknemers.

Maar vanwege de complexiteit hiervan, is dat ook niet zo makkelijk. Om te begrijpen hoe je dit effectief doet, neem de ‘Autonomy Slider’:

The Autonomy Slider

an example of the autonomy slider with 3 autonomy levels filled in.
Autonomy Slider met voorbeeld content in niveaus 1, 2, 4, met de slider niveau 2.

Het idee achter de Autonomy Slider is als volgt:

  1. Je geeft mensen geen volledige autonomie, maar je geeft ze steeds meer autonomie op basis van wat zij aankunnen. Iedere keer dat werknemers laten zien dat zij hun autonomie aankunnen en meer willen, verhoog je het niveau aan autonomie door de slider aan te passen.
  2. Je specificeert welke verantwoordelijkheden bij vrijheid komen. Zorg ervoor dat werknemers begrijpen hoe zij aan deze verantwoordelijkheden voldoen (teams moeten begrijpen wat je bedoeld met termen zoals ‘predictable’.
  3. Als een werknemer, kan jij ook het initiatief nemen door de discussie aan te gaan met je manager, zolang jij de verantwoordelijkheden wilt accepteren. Dat is precies wat wij in het voorbeeld in de introtekst van deze blog post hebben gedaan.

 

Richtlijnen:

  • Maak het visueel. Of je de Autonomy Slider nou voor werknemers of voor volledige teams gebruikt, zorg ervoor dat de vrijheid en verantwoordelijkheden zichtbaar zijn voor hen.
  • Managerment faciliteert. Met de verhoging van autonomie wordt de management rol meer faciliterend dan dirigerend. De tijd dat jij je werknemers vertelt wat zij moeten doen is voorbij. Faciliteren gaat om het neerzetten van een shared understanding over wat we willen bereiken en teams zelf hun eigen weg laten vinden om daar te komen.
  • Mensen maken fouten. Altijd als mensen nieuwe dingen uitproberen zullen zij fouten maken. Dus als mensen nieuwe verantwoordelijkheden op zich nemen, kan je verwachten dat zij fouten gaan maken. Probeer deze fouten vooral niet te voorkomen, want daar leren zij niet van. Moedig werknemers aan om fouten te maken en hiervan te leren.

Onthoud dat autonomie iets is dat je opschaalt of afschaalt, op basis van de behoefte van de werknemer. En autonomie bestaat altijd uit zowel vrijheid en verantwoordelijkheid.

Autonomie is de behoefte om het juiste te doen, op de juiste manier. De behoefte om zelf te bepalen hij jij leeft.

En voor wie zich afvraagt wat er is gebeurd met het scherm dat ons team had herbouwt? Twee maanden later had onze Product Owner verteld dat het herbouwen van dit scherm het aantal klachten via de customer service had verlaagt met 90%! Normale user stories kunnen dit soort percentages niet realiseren, dit soort verbeteringen komen alleen door op te komen voor wat juist is. Dus als jij de volgende keer een kans zoals dit ziet in je team, durf te vechten voor wat het juiste is!

Purpose – Waarom zijn we hier mee bezig?

Waar zijn wij nou helemaal mee bezig? Wat gaat deze user story uberhaupt toevoegen? En nog erger, wat is de betekenis van deze user story in het grote plaatje? Is er uberhaupt een groter plaatje?

Allemaal vragen die naar mijn mening te weinig worden gesteld. Meestal, omdat er vaak niet eens antwoorden op deze vragen zijn.

Dit houdt dus in dat…

Omdat wij niet weten waarom wij ons werk doen, stellen wij de vragen ook niet meer…

Als je niet weet waar je voor werkt, wordt je vanzelf responsief op werk

Het gevaar als je deze vragen niet stelt, is dat dit ook nooit opgelost zal worden. En zolang dit niet opgelost wordt, zal de motivatie van iedere werknemer langzamerhand afnemen.

Binnen de IT, is ieder lid van een development team vanuit zichzelf intrinsiek gemotiveerd om aan het product te werken en het product gaaf te maken. Zo gaaf mogelijk! Want anders zou je daar niet willen werken.

Maar zolang het voor developers niet duidelijk is hoe hun contributie meehelpt aan het bereiken van een bepaalt doel, of het nastreven van een visie, zal die intrinsieke motivatie langzamerhand afnemen.

Lees hier meer over in mijn internalisatie blogpost (### Link naar internalisatie blogpost).

Als dit probleem voor een langere periode (een jaar) blijft bestaan, zal je langzamerhand signalen zien opkomen dat developers zich meer responsief en passief gaan opstellen richting het product. Bugs die niet op tijd worden opgelost, oude legacy code die niet wordt aangepakt, noem het maar op. Developers zullen zich minder hard inzetten om het product te verbeteren.

Mensen willen het product helpen, maar hebben daarvoor richting nodig

Zoals ik in mijn blog over mensen aangeef, wilt uiteindelijk iedereen elkaar helpen, gebruikmakend van zijn of haar eigen skills. Ook het product. Developers zijn gewoon intrinsiek gemotiveerd om het product gaaf te maken. Maar daarvoor moeten zij wel weten hoe zij dat kunnen doen.

Developers hebben richting nodig.

Hoe geeft je richting aan developers?

Richting geef je door mensen te laten begrijpen waarom iets belangrijk is.

NIET ALS: beste developer, voor de volgende user story moeten jullie de knop op de inlogpagina groter maken.

WEL ALS: Met dit product willen we mensen helpen om hun to-do lijstjes te ordenen, op dit moment maken meer dan 100.000 mensen hier al gebruik van. Wel hebben zij aangegeven dat zij de huidige manier van inloggen verwarrend vinden, vanwege reden X.

Het eerste voorbeeld is een klassiek voorbeeld van hoe het niet moet, en hoe hij bij de meeste organisaties nog steeds wordt gedaan (!). Dit leidt tot responsief gedrag en zou naar mijn mening verboden moeten worden.

Het tweede voorbeeld geeft richting aan een developer, door uit te leggen waarom dit product belangrijk is, en geeft de ruimte aan een developer om zelf na te denken over een mogelijke oplossing (want als hij hier zelf over gaat nadenken, gaat hij zich inleven in het probleem).

Zorg voor een shared vision over het product

Om nou bij iedere user story de context uit te leggen om developers te motiveren, is veel te vermoeiend. Dus dat raad ik af. Een effectievere methode is om een shared vision uit te werken van het product en deze op te hangen in de kamer van het development team. Met ‘shared’ bedoel ik dat deze door het hele team begrepen wordt en dat het hele team hier ook achter staat.

Er zijn verschillende technieken om de visie van een product uit te werken. Regelmatig zie ik het agile vision board langs komen. Maar het Agile Inception Deck spreekt mij iets meer aan.

Wat je ook gebruikt om tot een visie te komen. Het gaat er uiteindelijk om dat het hele development team de visie begrijpt en erachter staat. Want een goeie visie wordt regelmatig door developers gebruikt om uit te leggen waarom een bepaalde oplossing van een user story goed of juist slecht is. Dat is een mooie controle of je visie sterk genoeg is.

SLECHTE VISIE: “Ons product kan bijna hetzelfde als onze concurrenten”.
Een visie moet uitleggen waarom de developers dagelijks 8 uur aan dit product besteden, en dus niet morgen opstappen en bij de concurrent gaan werken.

SLECHTE VISIE: “Ons product gaat voor wereldvrede zorgen.”
Een visie moet ook acceptabel zijn, zodat de developers hier ook serieus achter durven te staan.

GOEDE VISIE: “Ons product gaat mensen helpen om kwaliteit van software inzichtelijk te maken.”
Dit spreekt aan en kan gebruikt worden om bepaalde user stories af te wijzen of op te pakken.

Met een shared vision, geef je teams richting op conceptueel niveau.

Maak belangrijke metrieken zichtbaar

Een Shared Vision geeft richting aan de user stories die door teams opgepakt worden. Maar zodra hieraan gewerkt wordt, zal deze visie een mindere rol gaan spelen. Dit omdat een visie bedoeld is om op conceptueel niveau keuzes te maken. Zodra code geschreven moet worden, werken dit soort conceptuele ideeën niet meer. Wat je dan nodig hebt, zijn concrete metrieken.

Met name zichtbare, metrieken spelen een grote rol in het werk dat teams doen. Veel mensen maken met Scrum de fout door de Velocity (het aantal user stories dat opgeleverd wordt) zichtbaar op te hangen in de teamkamers. Wat je dan ziet is dat het team zich zal richten op het verhogen van het aantal user stories dat opgeleverd wordt. Simpelweg omdat het zichtbaar wordt gemaakt. Vaak neemt de kwaliteit dan af en wordt de software vanzelf een rommeltje.

Wat je eigenlijk wilt doen is een lijst met *belangrijke* metrieken gebruiken, en deze zichtbaar maken.

Stel je visie is: “Ieder persoon op aarde te leren rekenen”.

Dan zou je de volgende metrieken zichtbaar willen maken voor het team (het liefst automatisch bijgehouden op een dashboard):

  • Het aantal unieke gebruikers van het systeem.
  • Het huidige rekenniveau van de gebruikers.

Opeens is het aantal user stories niet meer van belang, maar de impact die je daarmee maakt. En teams zullen zich daarop inzetten!

Door de belangrijkste metrieken zichtbaar te maken, geef je teams richting op taak niveau.

Zorg voor een shared vision over de organisatie

Als je het helemaal goed wil doen, zorg dan ook voor een shared vision over de organisatie zelf. Deze visie zou namelijk de reden moeten zijn waarom het product bestaat, en bepaalt voor een groot deel de cultuur van de organisatie.

Een duidelijke visie van de organisatie krijgen zou makkelijk moeten zijn. In praktijk lijkt dit helaas een stuk moeilijker te zijn, met name omdat het antwoord vaak varieert op basis van wie je het vraagt.

Mijn advies: maak het jezelf vooral niet te moeilijk. Vraag je Product Owner of manager om een visie van het bedrijf en gebruik deze. Als ze helemaal niets hebben, mag je hier best een impediment voor inschieten. Je zou het filmpje van Simon Sinek kunnen delen om ze uit te leggen waarom dit belangrijk is.

Nog even in het kort

Zelfsturend gedrag is niet een persoonlijkheids trek. Dit is gedrag dat voortkomt uit het niet hebben van een duidelijke visie voor het product en voor de organisatie. Want om zelfsturend te zijn, hebben mensen richting nodig. Zorg ervoor dat deze richting duidelijk is.