Hoezo gevoelens in IT-projecten?

De essentie in de retrospective. Inclusief 4 tips voor succesvollere projecten.

Ralph deguelle

Geschreven door Ralph Deguelle op 2-8-2016
5 minuten leestijd

Ken je een project dat anders is gelopen dan je wilde?
Waarvan je er later achter kwam dat een aantal mensen dit al ‘aan voelden komen’? Of waarvan je zelf al een hele tijd het gevoel had ‘ik hoop dat dit maar goed gaat’?

Dit komt het meest voor bij projecten die iets creëren dat nog niet is gedaan.
Denk aan het ontwikkelen van maatwerk software. Of een andere vorm waar creativiteit met vakmanschap moet worden gecombineerd.

Aan het eind van deze korte blogpost weet je hoe projecten beter, succesvoller en met meer vreugde, en dus minder frustratie, worden uitgevoerd.
Ja… zelfs bij ‘agile’ projecten.

Vind je het niet raar dat zelfs ‘lean’, of ‘agile scrum’ projecten met regelmaat anders uitpakken? Dit zijn methodieken die zelfs in hun, al is het eenvoudig, proces ingebouwd hebben om continu te verbeteren en van elkaar te leren. Waarom komen sommige zaken — lees: verschillende verwachtingen — dan toch zo laat aan het licht?

Als er iets ‘mis’ gaat is er altijd sprake van andere verwachtingen tussen mensen.
Als deze verschillende verwachtingen lang blijven bestaan leiden ze tot onbegrip en later nog tot frustratie. Frustratie in een project: dan weet je “ik heb de poppen aan het dansen”.
Dat wil je niet.

NB: Lees níet verder als je wél van dansende poppen houdt.

Bij mensen die samenwerken is altijd sprake van emotie of gevoel.
Wat zou er nu gebeuren als je dit gevoel -over het project of taak die te gebeuren staat- zou kunnen delen met iedereen in het project?

Ik hoor een aantal al denken: “Nou ja, dat zal wel zo zijn, maar om aan te geven hoe het project gaat is toch eigenlijk de verantwoordelijkheid van … PM/PL/PO/SM “ (..of een andere afkorting waar je de verantwoordelijkheid naartoe zou kunnen schuiven).

Vind je dat?
Echt?

In de huidige projecten, zeker bij het ontwikkelen van software, zijn we toch allemaal professionals, of niet?
Naast het ontwikkelen van software gaat het in de moderne tijd toch vooral over het adviseren van klanten en collega’s. Bij dit adviseren hoort dus ook je mening geven en zaken benoemen die niet altijd voor de hand liggen, zoals je gevoel over het project.
Hierbij moet je je inderdaad kwetsbaar opstellen.
Dat klopt.
Iets vanuit je gevoel benoemen heeft altijd het risico op ‘fouten’.

Even wat hulp:
Patrick Lencioni bespreekt in zijn boek ‘Naked Consultancy’ de waarde van kwetsbaarheid (vulnerability).
Hier beschrijft hij o.a. 3 angsten waardoor mensen het moeilijk vinden om zich kwetsbaar op te stellen:

  1. Fear of losing the business
  2. Fear of being embarrassed
  3. Fear of feeling inferior

Bovendien: Het niet kwetsbaar durven opstellen vormt het grootste onderdeel in zijn andere boek ‘5 frustraties van teamwork’ Herkenbaar?

We vinden het kwetsbaar durven opstellen dus vaak moeilijk.

Nog meer hulp:
Een van de best bekeken TED presentaties …ever… is die van Brené Brown: ‘The Power of Vulnerability’.

Ok, nu we overtuigd zijn, dat er in kwetsbaar opstellen een grote kracht zit, hoe zorgen we dan dat we dit meer doen? Kunnen we mensen in een team uitnodigen of verleiden om zich kwetsbaar op te stellen?

En nu concreet

Even een context als voorbeeld: Een software project, met de methodiek agile scrum.

Hier is één van de ‘ceremonies’ in een sprint, de zogenaamde retrospective. Dit is de belangrijkste bijeenkomst die borgt dat het hele team blijft verbeteren en leren. De scrum guide is redelijk karig over deze bijeenkomst.
Deze zegt:

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements;
and, Create a plan for implementing improvements to the way the Scrum Team does its work

Vaak wordt — via de beroemde geeltjes — opgeschreven en besproken wat ‘er goed ging’ en ‘wat er voor verbetering vatbaar is’. Hier komen vaak heel praktische acties uit om het project te verbeteren, maar dit zijn vaak de oppervlakkige, rationele zaken.
Bedenk daar nog bij dat dit vaak in een IT-team plaats vindt (lees: voornamelijk mannen met een hoog rationeel gehalte) en je voelt wel al aan dat hiermee de echte gevoelens nog niet boven komen.

Interessanter zijn vaak de vragen die uitnodigen om je gevoel te uiten en je dus kwetsbaar durven op te stellen. Een paar suggesties:

1. De methode ‘Mad Sad Glad’

Deze heeft qua naamgeving al meer gevoel.
Hierbij kijk je al meer naar het type emotie dat een team ervaren heeft.
De nuance zit hierbij in het verschil tussen Sad en Mad. Beide zijn negatief, maar halen wel verschillende onderwerpen uit een team.
Mooier is het nog als je deze methode uitbreidt met ‘Scared’. Dit is een kolom voor de geeltjes waar de ‘angsten’ van een team aan bod komen.
Een mooie uitnodiging om je gevoelens over het project uit te dragen, vind je niet?

(Ook de veelbesproken methodes ‘zeilboot’ of ‘het wiel’ hebben een vorm waar enige aandacht is voor emoties, maar de bovenstaande vind ik mooier).

2. De methode ‘5 vinger vragen’

Deze methode komt uit de coaching, maar kan ook goed in de retrospective worden gebruikt. Hierbij stel je vragen met de 5 vingers van je hand als leidraad:
Duim: Waar ben je trots op? Wat ging er goed?
Wijsvinger: Waar ligt je focus op: Wat is jouw doel voor de komende sprint?
Middelvinger: Wat ging er niet goed? Waar irriteerde je aan? Wat wil je wegnemen uit het sprint-proces?
Ringvinger: Waar ben je trouw aan? Waar geef jij commitment voor af, de volgende sprint?
Pink: Wat is jouw persoonlijke ‘zwakte’? Waar wil je beter in worden?

De kleine vinger is hierbij een krachtige vraag die de retrospective persoonlijk maakt. Ook in deze 5 vinger vragen ligt een mooie uitnodiging om je kwetsbaar op te stellen.

3. Voeg een touchy-feely grafiek toe

Maak aan het eind van de retrospective een grafiek met op de horizontale as ‘vertrouwen’ en op de verticale as de gemoedstoestand of happiness.

touchy-feely-grafiek

Ook hier weer een gelegenheid om in te pluggen op je gevoel en dit kenbaar te maken.

Als laatste nog een iets andere benadering:

4. Vraag de “Five Whys”

Als er een lijst met actiepunten is, bijvoorbeeld een hele praktische die niet is gebaseerd op gevoel: Vraag een paar keer door.
Een herhalend “Waarom?” brengt je al snel tot de kern van de vraag. Die op zoek gaat naar de root cause. En ervoor zorgt dat de juiste actie wordt voorgesteld.

Een oppervlakkige retrospective is géén retrospective — het moet doordringend en onderzoekend zijn.

Wedden dat je hiermee bij een aantal onderwerpen ook snel tot punten komt die met gevoelens te maken hebben? Die belangrijker zijn dan de praktische punten die je eerst had?

In het bovenstaande stuk een pleidooi om gevoelens een vaste plek te geven in projecten met een aantal suggesties hoe dit kan in het scrum proces.
De agile en scrum methodiek zijn erg krachtig en hebben bijeenkomsten in de methode om ervoor te zorgen dat projectteams iedere iteratie beter worden.

Het toepassen van bovenstaande tips zorgt voor diepgang.
Dus niet slechts een oppervlakkige ceremonie, maar de essentie voor betere relaties, structureel leren en continuous improvement.

Heb jij nog meer tips om mensen uit te nodigen om zich kwetsbaar op te laten stellen en daardoor projecten beter te laten gaan?
Laat het me weten!