Door: Gerben de la Rambelje
Auteur: Nathalie Rooseboom de Vries – van Delft ● funtestic.fanatic@gmail.com
‘I put my heart and my soul into my work, and have lost my mind in the process.’ ~Vincent van Gogh
Volgens een onderzoek van het Centraal Bureau voor de Statistiek en kennisinstituut TNO is het percentage ICT’ers dat genekt wordt door een burn-out 17,2 procent[i]. Dat is 3,2 procentpunt hoger dan het landelijk gemiddelde. Volgens het onderzoek zijn de oorzaken te vinden in onder andere een hogere werkdruk en een hoge mate van emotionele betrokkenheid bij het werk.
Tijdens een workshop over verzuim die ik niet zo lang geleden had bijgewoond, kwam de burn-out ook ter sprake. Uit één van de discussies die ontstonden, kwam naar voren dat het erop leek dat het verzuim vanwege burn-out steeds meer bij een jongere populatie voorkomt. We filosofeerden verder over wat de oorzaak zou kunnen zijn. Was het de hoge werkdruk? Was het de hoge mate van emotionele betrokkenheid? Wij dachten dat dit niet het grootste pijnpunt was. We legden de link met de toenemende mate van Agile werken.
Agile werken, en we focusten hier met name op Scrum, is een vorm van werken waar een hoge mate van eigen (team)verantwoordelijkheid wordt verwacht. Het team is als geheel verantwoordelijk voor het resultaat van het werk, want men voelt zich daardoor meer betrokken. Dat maakt het werken in een Scrum-team uitdagend en het geeft een hoge mate van autonomie. Die autonomie is een belangrijke factor bij het motiveren van medewerkers, zo blijkt ook uit onderzoeken[ii]. Tot zo ver lijkt er geen vuiltje aan de lucht en kan gesteld worden dat het werken in een Scrum-team juist motiverend en stimulerend is. De meesten zullen dat ook wellicht zo ervaren, daar ben ik van overtuigd.
Toch kan al dat stimuleren en presteren ook een nadeel hebben. Voornamelijk, maar niet uitsluitend, in de jonge populatie. Daar waar in de ‘traditionele project-wereld’ een ‘jonkie’ langzaamaan werd geïntroduceerd aan het IT-wereldje met een testmanager en/of – coördinator of mentor, wordt deze nu in een Scrum-team geplaatst waar per direct een resultaatverantwoordelijkheid geldt. Ook ‘oudjes’ ervaren die last in een aantal gevallen, zeker als deze altijd in een gemicromanagede omgeving hebben gewerkt. Verantwoordelijkheid is geen vanzelfsprekendheid, verantwoordelijkheid moet je durven nemen, maar ook soms leren nemen.
Uiteraard is men in Scrum niet als individu maar als team verantwoordelijk. Maar laten we eerlijk zijn, veel teams zien een nieuwe toevoeging toch als een vermindering van hun velocity en deze moet zo snel mogelijk weer op peil zijn. Daarmee ligt dan toch weer een verwachting bij de nieuweling die in alle enthousiasme en ‘will to please’ toch de ‘uitdaging’ aangaat, men wil het team niet teleurstellen. Er is immers een schaap met vijf poten gevraagd, pardon, duizendpoot[iii] natuurlijk en dat wil men ook leveren. Dat kan goed gaan, maar ook niet. In het laatste geval zal op termijn de medewerker opbranden met uitval tot gevolg. Hij of zij legt ziel en zaligheid in het werk, maar verliest zijn verstand in het proces. Toen Vincent van Gogh dat zei, was dat dus zo gek nog niet.
De ‘aha-erlebnis’ voor dit artikel had ik echter niet door de burn-out discussie tijdens die verzuimsessie, maar afgelopen week tijdens een cursus over het Scaled Agile Framework. Op een gegeven moment werd daar veel gerefereerd aan LEAN, KANBAN, Kaizens, GEMBA en wat diens meer zij. Eigenlijk legde ik de link met ‘oosters’ en ik bedacht me dat – hoewel Scrum niet zo zeer oosters is- veel Agile aanpakken op een oosterse leest geschoeid zijn. Ineens herinnerde ik me de burn-out discussie, de (al dan niet bestaande) relatie met Scrum en legde een verband.
Een bekend concept uit de oosterse wereld is: ‘Yin en Yang[iv]’. Het zijn Chinese begrippen die verwijzen naar tegengestelde principes of krachten waarvan alle aspecten van het leven het universum doordrongen zijn. Daar in de Oriënt (ja, ik ga nu lekker generaliseren! ;-)) is men veel meer bezig met de juiste balans en hier in ‘de West’ zijn dergelijke concepten vaak aangeduid als zweverige nonsens. Er zijn (nagenoeg) geen betrouwbare cijfers over burn-out in het Verre Oosten, maar als je zoekt naar onderzoeken, komt het meest naar voren over verwesterde landen.
Mijn redenatie: bij het ontwikkelen van een aanpak met oosterse origine in een westers georiënteerd land is de kans op een burn-out groter dan in een oosterse georiënteerd land omdat er blijkbaar wat anders wordt gedaan dat het ontstaan van een burn-out verkleint.
Wat is dat ‘ánders’? Wat doet men écht niet in het Westen wat men in de Oriënt wel doet? Ik denk dat het ligt aan het beleven van die eerdergenoemde Yin en Yang en het bewust omgaan met de balans tussen de twee. Wanneer je door een gemiddelde stad in Azië loopt langs een park of een plein, dan zie je er hele groepen mensen mystiek bewegen. Men laadt zichzelf op als men moe is, men komt tot rust als men druk is. Men beoefent Tai chi! dat verwijst naar een filosofie wat het ene uiterste (ultieme) en het andere uiterste (beste) betekent en daarmee verwijst naar de filosofie van Yin en Yang.
Er zit dus niks anders op dan een extra ceremonie te introduceren in het Scrum-proces ter voorkoming van onbalans en burn-out bij de medewerkers: de Tai chi spective (combinatie van Tai-chi beoefenen en het woord retrospective). Ik kom graag bij de teams observeren en onderzoeken wat het uiteindelijke effect is!
[i] https://www.computable.nl/artikel/nieuws/loopbaan/5649273/250449/burn-out-nekt-172-procent-van-de-icters.html
[ii] Een voorbeeld: Zelfsturende teams Een kwalitatief onderzoek naar de betekenisgeving van zelfsturing en de gevolgen voor effectiviteit en medewerker tevredenheid. Axelle Schmit, masterscriptie
[iii] https://www.testnet.org/vak/het-schaap-met-vijf-poten-is-dood-leve-de-duizendpoot/
[iv] https://nl.wikipedia.org/wiki/Yin_en_yang
Er zit wel wat in, scrum zorgt voor een continue druk, voor alle teamleden, maar waarschijnlijk sterker voor starters die eigenlijk rustig ‘op stoom’ moeten komen. Wat ook kan meespelen is dat -in mijn ervaring althans- veel aanwezigheid op de werkvloer wordt verwacht in het kader van de ‘korte lijntjes’. Alleen op de vrijdag wordt thuiswerken geaccepteerd, de rest van de week is het jongleren om buiten-werk-verplichtingen te combineren met lange reistijd, vroeg opstaan en laat thuiskomen.
Als er burn-outs voorkomen uit een Agile / Scrum manier van werken, is het niet echt Agile! Zie de principles:
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Voorkomen dat mensen overbelast worden en een burn-out krijgen is dus gewoon onderdeel van Agile development (want burn-out != maintain a constant pace indefinitely). Als je hier geen aandacht aan geeft als team / organisatie, ben je niet Agile bezig.
Gezien de Amerikaanse oorsprong van Agile developement is wat mij betreft een westerse manier van hiermee omgaan ook een prima optie: een ‘people manager / coach’ die de sponsors, developers en users helpt hun weg te vinden in het Agile proces zonder daarbij overwerkt te raken kan ook goed werken….Tai-Chi is optioneel =)
Hallo Robin,
Dank je wel voor de reactie. Wat ik uit je reactie opmaak is wat mij betreft best een raak punt. Dat is namelijk hoe het hoort -bedoeld is- en hoe men er mee omgaat in veel situaties.
My two cents:
1. De interpretatie van de betreffende persoon van het principe: “Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”, is niet zoals het bedoeld is.
Scrum bedoeld dit ongetwijfeld als vanuit de persoon en zijn werkomgeving (factoren) gezien. Het betekent een goed ‘herderschap’ van de mensen; zorgen dat ze goed in hun vel zitten en niet gestressed raken zodat ze die pace inderdaad vast kunnen houden.
Als je het van de minder goede kant ziet, zoals SCRUM het ongetwijfeld *niet* bedoeld heeft, kun je het ook anders interpreteren. Denk aan bijvoorbeeld de veeleisende klant of manager, dat het team er maar voor moet zorgen dat er een constante stroom van werk moet worden opgeleverd er staat immers in de principes dat ze dat moeten kunnen doen.
Oftewel; de bedoeling van het principe om een houdbare, gezonde omgeving te hebben zodat men continue ritme kan aanhouden OF de perverse interpretatie dat het team -ongeacht hoe men dit voorelkaar bokst, continue ritme MOET houden. Als het team het laatste ook zo gaat voelen (door bijvoorbeeld onvoldoende coaching of halfzachte implementatie van SCRUM) dan is het hek van de dam: dan legt men druk op de leden om maar op te leveren in een continue (moordend) tempo.
2. Vaak is er geen (essentiële) aanwezigheid van iemand (coach of people manager) die er voor zorgt dat sponsors, developers en users het Agile proces zoals het bedoeld is invoeren en volgen. De persoon die uitlegt, coacht en de oh-zo-belangrijke veilige omgeving in de retrospective helpt ontwikkelen zodat mensen kunnen uiten dat de druk op hun schouders (te) hoog is. Deze rol wordt veelal (niet altijd gelukkig!) als ballast gezien: er is immers een development team, een scrummaster (sommige zouden dit overigens best goed kunnen overigens!) en een P.O.; wat heb je dan nog meer nodig; een ‘people manager/ coach’ levert immers – als je niet verder kijkt dan je neus lang is- geen businessvalue op.
Ik denk dat op dit moment te euforisch over SCRUM/ Agile wordt gedaan; het is een verhaal waar geen vuiltje aan de lucht is. Het is bijna hippie-achtig: samen creëren we de mooiste dingen en we zijn baas over eigen lijf en leden. Een roze wolk.
Begrijp me niet verkeerd; ik ben een voorstander van iteratief en kortcyclisch ontwikkelen volgens Agile methodieken (geen tegenstander van SCRUM voor de duidelijkheid!). Ik denk alleen dat in de huidige tijd veel SCRUM/ Agile is gehyped (of wat te denken van DevOps of Spotify-model), er veel te lichtzinnig over is nagedacht en dat men veel niet helemaal toepast zoals het bedoeld is, al dan niet omwille van “wel de lusten, niet de lasten”. Er zijn voorbeelden te over waar men SINO of DINO toepast; en met name die zijn meestal voor de gezondheid van de medewerker in het nadeel ingericht…
Hopelijk iets om over na te denken of in het achterhoofd te houden 🙂
Hoi Nathalie, leuk stukje met een harde kern van waarheid. De Taichispective is een leuke variant van de retrospective, die wellicht gebruikt kan worden om een gevoelig onderwerp als werkstress (PSA) ter sprake te brengen. Want scrum zorgt gewoon voor een constante werkdruk (de zogeheten velocity), het is de blauwdruk voor een worstmachine die met een constante snelheid worst produceert. Grootste probleem is dat een team in praktijk niet zelfsturend zijn, scrum masters zijn semi managers, product owners denken in business termen (release dates etc.). Daarnaast is er de utopische visie dat een teamleden alleskunners/generalisten moeten zijn. Taken moeten uitgevoerd worden, ongeacht de in het team aanwezige skills en persoonlijkheden. Team/peer pressure speelt hierbij een grote rol, hoe kleiner het team, des te groter dit probleem wordt. Teamleden werken buiten hun comfortzone, continue gemonitored door andere teamleden, met de hete adem van de sprint cycle in hun nek. Ondanks de mooie paradigma’s van zelfsturing, fail fast, en teamverantwoordelijkheid kan deze cocktail lelijk uitpakken voor teamleden die teveel hooi op de vork nemen, of door omstandigheden buiten de controle van het team in de problemen komen. Zelf ben ik meer voortander van samenstellen van teams op basis van skills en Belkin rollen, zodat een ieder in zijn comfort-zoen maximaal aan het team kan bijdragen. Want hoe je het ook wendt of keert, het blijft mensenwerk.
Groeten, Cees Jan