Category: Effectief zijn in een team

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

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!

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

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.

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.

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

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!

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.

Zoals ik in mijn perspectieven blog beschreef, zijn er naar mijn mening geen waarheden, alleen perspectieven (een soort persoonlijke waarheid). En of je het nou met me eens bent of niet, binnen de IT ontstaan vaak communicatie problemen vanwege aannames. Aannames die gemaakt worden omdat wat jij in je hoofd hebt, natuurlijk een ‘waarheid’ is voor iedereen. Dus uiteraard hoef jij dit niet uit te spreken, want duuhh… iedereen weet dit allang.

Naar mijn mening zijn aannames prima, ZOLANG je ze bespreekt met de mensen om je heen. Aannames die je voor jezelf houdt, zorgen bijna altijd voor problemen. Meestal ook voor problemen in de software.

Maar hoe ga je daar nou mee om? Het is lastig om te weten welke aannames je dagelijks maakt. Want het zijn er nogal wat. Uiteindelijk gaat het om het volgende:

Maak de perspectieven van het team concreet

Vraag jezelf hier altijd bij af: “Mag ik er zomaar vanuit gaan dat iedereen hier op dezelfde manier over denkt als ik?”. Let met name op het stukje ‘Mag‘. Want het gaat uiteindelijk om risico’s. Wat is het risico als deze aanname onuitgesproken blijft?

Het ontwikkelframework ‘Scrum’ gebruikt de ‘Definition of Done’ en ‘Definition of Ready’, om concreet te maken wanneer software klaar is om aan te werken, en wanneer software klaar is om op te leveren.

Maar voor veel teams houdt het hierbij op, en dan zie je alsnog dat er (met name bij nieuwe teams) verschillende problemen ontstaan. Ik noem hieronder een paar voorbeelden van onderwerpen die je als team concreet zou willen maken om gevaarlijke aannames te voorkomen:

• DoD / DoR. Zoals hierboven al kort genoemd, Definition of Done en Definition of Done gebruik je om concreet te maken wanneer software klaar is om aan te werken en wanneer software klaar is om op te leveren.
• Werkafspraken. Hoe houden wij ons werk bij? Gebruiken wij een digitaal platform of een fysiek bord? En hoe houden wij deze bij?
• Kwaliteit. Als je op google de term opzoekt, lees je: “de mate waarin datgene goed is of aan bepaalde normen voldoet”. Dit geeft al aan dat het voor ieder team belangrijk is om te bepalen om welke normen dit gaat. Want anders kan ik je garanderen dat iedereen in het team een ander beeld zal hebben van kwaliteit.
• Waarde. Binnen de context van Agile wordt er regelmatig over waarde gesproken. Ook weer zo’n ambigue term. Naar mijn mening is ‘zoveel mogelijk software opleveren’ niet gelijk aan waarde. Toch lijken veel teams daarop te sturen. Scrum helpt daar ook heerlijk mee met velocity charts enzo…
• Development strategie. Design patterns die gebruikt worden? Wat is de test strategie van het team? Wat is de branching strategie en hoe gebruiken we onze pipeline?
• Individuele skills. Waar is ieder individu binnen het team goed in? En wat vinden zij leuk? Dat iemand ‘Senior developer’ is, zegt vrij weinig over zijn specifieke competenties.

En er zijn er waarschijnlijk nog veel meer. Maar het is verstandig om aandacht te besteden aan ieder onderwerp, omdat je anders het risico houdt dat hierover aannames onuitgesproken blijven.

Het beste uiteindelijk is om iets visueels uit te werken dat je kunt ophangen in je eigen teamkamer (zorg voor een teamkamer als je die nog niet hebt). Hierdoor gaan de keuzes en afspraken die hierbij gemaakt zijn meer leven in het team, en kunnen collega’s elkaar beter wijzen op afspraken die niet nagekomen worden.

Eén van de belangrijkste concepten waar ik mij als romanticus mee bezig hou, is betekenis. Een term die met woorden moeilijk te beschrijven valt. Maar ondanks dat ongelofelijk belangrijk is op de werkvloer. Een baan die weinig betekenis heeft, is voor veel mensen demotiverend. Een baan met veel betekenis geeft de energie om je bed uit te komen en weer aan de slag te gaan.

Als jij, net als mij, het belangrijk vindt om voor een leuke werkomgeving te zorgen, is het belangrijk om voor betekenis te zorgen (voor jezelf en voor anderen).

In mijn ervaring is er één simpele manier om ergens betekenis aan te geven, namelijk:

Betekenis ontstaat doordat je ergens energie en tijd in hebt gestopt.

Dingen en mensen kunnen dus niet spontaan betekenis krijgen, jij geeft ze betekenis door er tijd en energie in te stoppen.

Een paar simpele voorbeelden:

• Een huisdier waar jij tegen praat en waar jij veel mee ligt te knuffelen, krijgt veel betekenis voor jou.
• Als jij in je vrije tijd koekjes bakt voor werk, krijgt werk meer betekenis voor jou. Leuk is dat dit ook je collega’s hier betekenis aan geven zodra ze zich loskoppelen van werk om je koekje te verorberen.
• Een taak die jij zo effectief en zo efficient mogelijk afrond, heeft weinig tot geen betekenis.
• Als jij op je eerste dag voor een grand-entree zorgt op werk, beteken jij iets voor iedereen die hier bij was en zullen deze mensen jou nog lang blijven herinneren.
• Als jij iedere dag een half uur de tijd neemt om met collega’s bij te kletsen, zorg je daarmee voor een betekenisvolle band met deze collega’s.

Helaas neemt betekenis af met tijd. Het is daarom belangrijk om regelmatig voor betekenis te zorgen voor jezelf en mensen om je heen.

Positieve betekenis

Betekenis an sich is vrij makkelijk op te bouwen, zoals hierboven is uitgelegd. Maar als romanticus heb ik (onder andere in de liefde) geleerd dat betekenis zelf niet genoeg is. Betekenis zorgt uiteindelijk alleen voor gewicht. Als jij een slechte band onderhoud met iemand, en daar vervolgens meer tijd en energie in stopt, wordt deze slechte band alleen maar sterker. En als jij meer tijd en energie stopt in een slechte date, zal deze date alleen maar slechter worden.

De truc is om leuke, positieve dingen meer betekenis te geven. Zorg daarom dat jij voor betekenis zorgt op manieren die jij leuk vindt:

• Hou je van bakken? Uit ervaring kan ik zeggen dat ieder team het geweldig vindt als jij een keer een zelf gebakken taart meeneemt.
• Hou je van borrelen? Organiseer af en toe een borrel na werktijd om lekker met collega’s te kletsen.
• Hou je van sporten? Nodig eens een keer een collega uit om samen te gaan squashen of zoiets.

Die 8 uur per dag die je iedere dag maakt hoeft echt niet aan te voelen als ‘werk’. Neem de tijd en energie om af en toe wat leuks te doen tijdens of na werk, met collega’s. Dit is de beste manier om voor positieve betekenis te zorgen. Voor jezelf en voor je collega’s.