Burn-out bij softwaretesters: 6 oorzaken & hoe je dit oplost

Ik ben dieper in het probleem van burn-outs bij softwaretesten gedoken en heb gevraagd:

• Hoe ziet een burn-out er in deze sector uit?
• Hoe groot is het probleem?
• Wat creëert systemen waarin softwaretesters een burn-out krijgen?
• Hoe kunnen we het probleem van burn-outs ontleden—en oplossen?

De antwoorden—of in ieder geval het begin ervan—vind je in dit artikel.

Burn-outs onder professionals in softwaretesten in de IT 

Werkgerelateerde stress is iets wat velen van ons in de IT-sector ervaren. Ik weet zeker dat jij ook jouw deel van de stress ervaart. In mijn context is een burn-out helaas de afgelopen jaren een steeds prominenter onderwerp geworden.

Is een burn-out een probleem?

Toen ik Jonathon Wright vroeg: “Hoe groot denk je dat het probleem van burn-outs onder QA-professionals is?”, antwoordde hij het volgende:

“Het is een enorm probleem. Beroemde woorden: Je kunt niet voortdurend sprinten.”

Jonathon Wright, presentator van The QA Lead Podcast

Hij legde verder uit:

“Methodologieën zoals Agile en DevOps moedigen het idee aan om alles zelfs ‘sneller’ te doen. Hoe levert een QA-professional meetbare waarde in de fail-fast-leer-snel-omgeving?

In een recente podcast op QALead kwam de term ‘vertragen om te versnellen’ ter sprake. Tenzij bedrijven mislukkingen vieren (wat maar heel weinig bedrijven doen), help je het teamtempo niet vooruit wanneer je faalt. 

De aanwijzing zit in de titel van het veel te vaak gebruikte burndowndiagram. Het gamificeren van het vastleggen van een aantal story points creëert ongezonde concurrentie.

"Je wordt gedwongen om meer te doen met minder, terwijl je werkt volgens de onrealistische verwachting dat werk in sprints van twee weken kan worden opgeleverd."

Jonathon Wright, presentator van The QA Lead Podcast

Hoe ziet een burn-out in QA eruit?

Een burn-out is geen geïsoleerd geval in de softwaresector—maar hoe ziet het eruit?

Hier volgen reacties van professionals in softwaretesten die laten zien op welke manieren een burn-out zich in QA manifesteert.

“We moeten onze waarde bewijzen. Teams vertellen me dat ze agile zijn en geen testers nodig hebben.”

“Angst. Het is voor QA-professionals moeilijk om zich geen zorgen te maken in aanloop naar een grote release of zich verantwoordelijk te voelen voor de resultaten.”

“Tijdsdruk. Testers zijn altijd de laatsten. En ik krijg nooit de tijd die ik nodig heb. Die tijd wordt gehalveerd omdat ontwikkelaars uitlopen.”

“Onrealistische verwachtingen. Ik zou voor altijd kunnen testen en zou niet alles kunnen testen. Vertel dat maar aan een projectleider. Wat heb je aan een tester die de bugs niet vindt?!”

“Uit backlogitems bepalen wat je moet testen is bijna onmogelijk. En niemand noemt randgevallen.”

“De verspilling is frustrerend. Ontwikkelaars kunnen een bug niet reproduceren, het backlogitem is verouderd of ze hebben het probleem al opgelost.”

“Veel mensen willen geen eerlijk rapport, en al helemaal geen slecht nieuws. Als je erop aandringt, kan het persoonlijk worden.”

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Get Free Access

Have an account? Log In

Waarom ontstaat een burn-out?

In de literatuur worden veel factoren genoemd die stress veroorzaken en de kans op een burn-out vergroten. Er zijn individuele factoren, bijvoorbeeld persoonlijke drijfveren zoals perfect willen zijn, opschieten, je uiterste best doen, sterk zijn of anderen tevredenstellen. Raadpleeg de transactionele analyse voor meer details. 

Daarnaast zijn er stressfactoren vanuit de werkomgeving. Een hoge werkdruk, tijdsdruk, onhaalbare doelen en verwachtingen, gebrek aan controle, hoogoplopende conflicten, angst om een baan te verliezen, ontevredenheid over het werk, pesten en intimidatie, en meer. We kennen ze.

Enige tijd geleden ben ik vanuit een systemisch oogpunt naar burn-out gaan kijken en heb ik een simulatiespel gemaakt waarin spelers het lot van een softwareontwikkelingsteam kunnen beïnvloeden. Ze kunnen de teamleden een burn-out bezorgen of het meest lonende project ooit creëren. 

Het hart van de simulatie is een burn-outsysteem, oftewel een systeem dat zo is ingericht dat sommige teamleden uiteindelijk een burn-out krijgen. Je kunt op mijn blog een indruk van het spel krijgen.

Deze systemische aanpak werkt ook voor verschillende rollen in een team. Ik heb dit gedaan voor professionals op het gebied van gebruikerservaring en was verrast hoe gemakkelijk het is om deze mensen in de gevarenzone van een burn-outsysteem te duwen. Vooral wanneer ze voor gebruikers zorgen, zijn ze bereid een extra strijd aan te gaan en eraan onderdoor te gaan.

Hieronder ga ik dieper in op een verhaal van Alan, een QA-professional, om het probleem van burn-out in de software-industrie beter te begrijpen en te illustreren. 

Daarna bespreek ik hoe burn-outsystemen ontstaan en wat we kunnen doen om deze systemen te verbeteren.

Een persoonlijk verhaal over burn-out

Nu ik ervan overtuigd ben dat ik een burn-outsysteem voor QA-professionals kan maken, laat ik je kennismaken met Alan en zijn verhaal. 

Alan heeft bijna tien jaar ervaring met softwaretesten, en vooral met prestatietesten. Hij staat op het punt zich bij een ontwikkelingsteam aan te sluiten. Het team werkt al tien sprints aan het project en heeft nog vier sprints te gaan tot een eerste release. 

Hoe verliep Alans eerste dag in het project?

Alan: Er is veel voor mij te doen. De software is van lage kwaliteit. Ik verwacht veel onontdekte bugs en vrees problemen als ik ze niet vóór de release kan vinden.

Markus: Is het identificeren van de bugs dan je hoogste prioriteit om de kwaliteit te verbeteren?

Alan: Dat is één onderdeel. We verwachten ook veel gebruikers. De prestaties van de software zijn van het grootste belang zodra we deze uitrollen naar het grote publiek. Het team staat te popelen om daar van mijn expertise te profiteren.

Tot nu toe is Alan behoorlijk optimistisch dat de met het team afgesproken maatregelen de kwaliteit van de software zullen verbeteren. Helaas ziet Alan er één sprint later, met nog drie sprints te gaan, niet erg vrolijk uit. 

Wat is er aan de hand?

Alan: De twee weken waren intensief. Ik ben niet tevreden over mijn voortgang. Ik wilde een eerste, eenvoudige prestatietest, hebben, maar ik ben nog lang niet zover.

Markus: Wat houdt je tegen?

Alan: Ik heb ondersteuning van ontwikkelaars nodig, maar zij zitten volgepland. Ik had ook veel meer tijd nodig dan verwacht om de software te leren kennen en de bugs te rapporteren die ik had gevonden.

Markus: Kon je de nieuwe verhalen testen die het team had opgeleverd?

Alan: Niet echt, het team was druk bezig ze af te werken. Van de twee dagen die aan het einde van de sprint voor testen waren gereserveerd, bleef er slechts een halve dag over. Ik ben langer gebleven en heb zaterdag gewerkt, maar ik ben nog lang niet klaar.

Tijdens de retrospectieve van sprint twaalf, met nog slechts twee sprints te gaan, is testen het belangrijkste onderwerp: de producteigenaar klaagde over het aantal bugs dat Alan had gevonden.

Ontwikkelaar: De meeste bugs die Alan heeft gevonden zijn onbeduidend of helemaal geen bugs. Laten we ze eerst doornemen voordat we conclusies trekken.

Alan: Het was voor mij moeilijk om op basis van de backlogitems te begrijpen wat de software zou moeten doen. Een specificatie zou echt helpen.

Ontwikkelaar: Over mijn lijk! We willen geen Waterfall. Het is grotendeels een kwestie van gezond verstand. Kom gewoon naar ons toe en vraag het. Hoe gaat het met het testen van de prestaties?

Alan: Ik sta vast. Ik krijg de tool niet zover dat deze tegen de servicelaag draait met al die beveiliging. Ik heb hulp nodig.

Ontwikkelaar: We gebruikten in het vorige project een andere tool. Die werkte perfect. Ik stuur je de link.

Als gevolg daarvan organiseert de PO in de volgende sprint een korte vergadering van twee uur. Het doel is de bugs te beoordelen en te bespreken wat er in de backlogitems moet worden vastgelegd om het de nieuweling Alan gemakkelijker te maken. Voel je Alans frustratie toenemen?

Alans fatale positie als zondebok wordt nog duidelijker na sprint dertien, met nog één sprint te gaan. Dit zijn de besluiten uit deze retrospectieve:

• Veel bugs gevonden in verhalen die Alan de sprint ervoor had moeten testen. Geen enkel verhaal mag worden afgesloten zonder dat Alan het heeft getest.
• Nog steeds geen prestatietest. We laten er een expert naar kijken. Alan moet hem informeren.
• Twee verhalen niet kunnen afronden. We zijn twee dagen kwijtgeraakt aan het weggooien van nutteloze bugrapporten. Alan markeert elke bug met de relevantie ervan. Vraag bij twijfel de producteigenaar.

Heb je het gezien? Het team heeft twee verhalen niet afgemaakt en wist Alan de schuld in de schoenen te schuiven! 

Stel je de volgende sprint eens voor, waarin verhalen niet worden afgesloten omdat Alan geen tijd had om ze te testen! Geen wonder dat Alan er uitgeput uitziet.

Alan: Nog maar twee weken tot de release en de kwaliteit is een nachtmerrie. Zeg dat maar tegen de product owner! En ze hebben het prestatietesten ook nog bij me weggehaald. Daarvoor ben ik überhaupt aan dit project begonnen. Mijn baas is niet blij. Hij wilde dat ik het goede voorbeeld gaf over hoe je testers in agile teams opneemt. Ik zal dit toch moeten zien door te zetten, want mijn reputatie binnen het bedrijf staat op het spel.

Vier weken later, twee weken na de eerste release voor een geselecteerd publiek, is het burn-outsysteem volledig operationeel. 

Alans samenvatting van zijn prestaties tot nu toe:

• Prestatietesten: mislukt
• Erkenning als expert op het gebied van prestatietesten: mislukt
• In staat om nieuw gebouwde onderdelen grondig te testen: mislukt
• In staat om de al gebouwde onderdelen grondig opnieuw te testen: mislukt
• Testers opnemen in agile teams: mislukt
• Geen kritieke bugs in de release: mislukt
• Aanbevolen worden: mislukt
• Hard werken en de schuld krijgen: behaald
• Angst om mijn baan te verliezen: behaald
• Opbranden: met volle snelheid op weg

Dit is een klassiek geval van een burn-outsysteem. Dus wat creëert dit systeem en hoe kunnen we het tegengaan?

Wat creëert een burn-outsysteem?

Voor Alan is het vanaf het begin een hopeloze zaak, zou je kunnen zeggen. En daar zou je gelijk in hebben. Alan zit in een burn-outsysteem dat al geruime tijd binnen het team actief is. Het burn-outsysteem pikt Alan eruit als een roofdier zijn prooi. Maar wat is dit burn-outsysteem en hoe doet het dat?

Een burn-outsysteem is een constellatie van mensen, drijfveren en conflicten. Via een zichzelf versterkende cyclus creëert het een situatie die zo vol stressfactoren zit dat sommige mensen uiteindelijk zullen opbranden. Het is vooral krachtig wanneer het de overlevingslogica van mensen kan activeren.

1. Energie volgt de drijfveren

In Alans verhaal kunnen we enkele drijfveren herkennen:

• Ambitie en fascinatie voor het favoriete onderwerp prestatietesten zorgen ervoor dat Alan het wil doen.
• Angst om verantwoordelijk te zijn voor een mislukte release zorgt ervoor dat Alan op zoek gaat naar bugs.
• Iets zorgt ervoor dat teamleden vóór alles functionaliteiten bouwen.

Drijfveren veranderen het verloop van handelen. Mensen hebben er echt moeite mee om helder na te denken over wat ze moeten bereiken en hoe ze dat moeten bereiken. De energie die mensen investeren volgt de drijfveer, niet de plek waar die het hardst nodig is. Alans team vraagt zich nooit af of het bouwen van alle functionaliteiten wel het juiste is om te doen. Alan vraagt zich evenmin af of het zoeken naar bugs gepast is.

Het moeilijke voor de meesten van ons is om ons ervan bewust te worden dat een drijfveer de controle heeft overgenomen. Gelukkig voor ons hebben psychologen ze bestudeerd. Begin voor persoonlijke drijfveren met de transactionele analyse. Op teamniveau is groepsdenken een goed startpunt. Daar is veel advies over te vinden.

Met betrekking tot angst voor een release gaf een ervaren QA-professional het advies: “Je moet het gewoon loslaten en kalm blijven”. Met zo'n instelling vanaf het begin zou Alan waarschijnlijk een ander doel nastreven dan alle bugs opsporen en prestatietesten opzetten. De hoogste prioriteit zou kunnen zijn dat het team de kritieke bugs verwijdert en over het algemeen een hogere kwaliteit levert. Een manier om de stress die gepaard gaat met repetitieve taken te verminderen, is door gebruik te maken van hoogwaardige tools die zijn ontworpen voor softwaretests.

2. Conflicten laten de spanning oplopen en worden persoonlijk

Samen met de drijfveren laaien er conflicten op binnen het team. Alan heeft bijvoorbeeld meer tijd van de ontwikkelaars nodig dan zij bereid zijn vrij te maken. Het resultaat: Alan maakt veel lawaai en de ontwikkelaars proberen hem van zich af te houden. Omdat hij weinig hulp krijgt, kan Alan niet aan de verwachtingen voldoen. Hij vreest voor zijn reputatie, verdubbelt zijn inspanningen en veroorzaakt nog meer lawaai.

Het echt slechte is dat conflicten persoonlijk worden. Na tien jaar als tester te hebben gewerkt, is Alan waarschijnlijk een behoorlijke expert. Toch ziet het team hem als een lamme eend en gedraagt het zich ook zo. Hoe langer dit duurt, hoe dieper het wordt. Dit heeft zelfs invloed op Alan: hij begint aan zijn competentie te twijfelen.

Hoe vaak heb je iemand de schuld gegeven? Hoeveel mensen om je heen leveren geen goed werk? Elke dergelijke gedachte wijst op een conflict dat persoonlijk is geworden.

De meeste teams zijn niet in staat conflicten op te lossen. Dat gaat niet vanzelf. Conflictmanagement is het sleutelwoord om advies te vinden. De kernboodschap: teams hebben een cultuur nodig waarin ideeën openlijk kunnen worden uitgewisseld, afwijkende standpunten worden verwelkomd als kansen om nieuwe dingen te creëren en elkaar helpen wordt gewaardeerd. Een moeilijke opgave, als je dit vergelijkt met de snelheidscultuur die een geïnterviewde beschrijft: “Tenzij bedrijven falen vieren, help je het teamtempo niet telkens wanneer je faalt”.

3. De teamstructuur beïnvloedt de teamdynamiek

Het team van Alan reserveerde de laatste twee dagen van de sprint voor testen, het afsluiten van de sprint en het voorbereiden van de volgende sprint. Het team ging er simpelweg van uit dat Alan deze structuur volgde. Hij zou de nieuw geïmplementeerde functies aan het einde van de sprint testen en in de volgende sprint opnieuw testen, en het testen in het algemeen verbeteren. Klinkt niet slecht, toch?

De werkelijkheid vertelt een ander verhaal. De software is pas op de laatste dag van de sprint beschikbaar. Achterstandsonderdelen bieden weinig hulp bij de vraag hoe het precies zou moeten werken. Terwijl het team de details bespreekt van wat ze in de volgende sprint zullen doen, probeert Alan te bepalen wat hij uit deze sprint moet testen. Vervolgens stelt hij vragen vlak voordat de ontwikkelaars vertrekken en test hij in het weekend. Geweldig dat het team bespreekt wat ze moeten vastleggen. Alan kan dan testen zonder de ontwikkelaars lastig te vallen. Raak.

De teamstructuur isoleert Alan steeds verder. Het team ziet niet dat hij worstelt. Ze merken alleen domme vragen en late resultaten met weinig waarde op. Wat een stakker.

Specificatie aan de hand van voorbeelden laat heel mooi zien hoe testen en testers een integraal onderdeel van een agile team kunnen zijn. Testers nemen deel aan verfijningen, helpen een testbare specificatie op te stellen, richten de testinspanningen op waar ze ertoe doen, verbeteren teamprocessen, individuele vaardigheden en hulpmiddelen, en voeren zelfs een deel van de tests uit. Er wordt voortdurend getest, niet alleen aan het einde van de sprint.

4. Negeer fundamentele regels en vraag om problemen

Het team van Alan negeert fundamentele regels van software-engineering. 

Hier zijn er vijf:

1. Onverwachte dingen gebeuren. Als er geen ruimte voor is, leidt dat op de lange termijn tot haast, afkortingen, domme fouten, hoogoplopende conflicten en daardoor tragere vooruitgang.
2. Druk zorgt voor vertragingen. Druk leidt tot minder ruimte voor onverwachte dingen.
3. Kwaliteit ontstaat gaandeweg. Het team moet een kwaliteitscultuur hebben. Testen is slechts één stukje van de puzzel. En één teamlid alleen tegenover alle anderen faalt doorgaans.
4. Het veranderen van het team vertraagt. Vertrouwen opbouwen, processen aanpassen, meer conflicten oplossen: het team heeft tijd en energie nodig om nieuwe teamleden te integreren. Mensen toevoegen aan een laat project maakt het nog later.
5. Van defecten moet je leren. Wanneer een proces te veel defecten oplevert, stop het dan, herstel het en leer ervan. Geef niemand de schuld en, nog belangrijker, voer het proces niet sneller uit.

Er zijn meer van zulke regels en wanneer mensen ze negeren, wordt alles erger. En dat gebeurde dus ook bij Alan.

5. Een waargenomen krappe situatie zet het in gang

Hoe komt het dat het team zulke fundamentele zaken negeert? Een eenvoudige verklaring. Typisch voor een krappe situatie waarin de gegeven omstandigheden (opleveringen, beschikbare tijd en het team) niet genoeg flexibiliteit overlaten om onverwachte dingen op te vangen. Dat kennen we allemaal: een duidelijk geval. Systemen die tot een burn-out leiden, benutten de enige variabele in een krappe constellatie: hoe hard het team werkt, oftewel hoeveel energie teamleden uit hun batterijen verbruiken.

De hamvraag: bevindt het team van Alan zich echt in een krappe situatie en is het opleveren van alle functies de beste aanpak? We kunnen het alleen maar aannemen. Het team deed hetzelfde en haastte zich om alle functies te bouwen.

Het is de perceptie van krappe situaties die ertoe doet. De aanleiding voor zo'n perceptie kan een contractuele clausule zijn, een stimulans, een geweldige marktkans, een sterke vraag van een baas, een gedane belofte, een wens van een klant of een overheidsvoorschrift.

Alan verwacht massa's bugs en door angst gaat hij ernaar op zoek. De hamvraag voor hem: is het vinden van de bugs in dit geval echt zo'n belangrijke stap? We kunnen alleen maar speculeren, en dat deed Alan ook. Hij nam aan van wel.

De perceptie van een krappe situatie is een belangrijke hefboom om een systeem dat tot een burn-out leidt te doorbreken. Daarachter zit nog een fundamentele regel van software-engineering:

• Te hoge verwachtingen. Belanghebbenden - inclusief de ontwikkelaars zelf - hopen op, verwachten of eisen meer dan een softwareteam realistisch gezien kan opleveren.

Als ik terugkijk op de laatste 25 jaar van mijn projectervaring, kan ik me geen enkel project herinneren waarin dit niet het geval was. Het conflict tussen wat wordt verwacht en wat kan worden opgeleverd, is het brandpunt. Het succes van een project hangt af van hoe goed de betrokkenen dit conflict kunnen oplossen. Ik zou aanraden om goede werkwijzen te bestuderen op het gebied van stakeholder- en verwachtingsmanagement, conflictmanagement, requirements engineering, wendbaarheid en dergelijke.

In elk geval is het zaak om de precieze aard van het conflict te begrijpen. Hoe sterk is het? Wat drijft het? Met wie moet je samenwerken? Of, zoals een van de geïnterviewde QA-professionals het verwoordde: “Ik geloof dat elk bedrijf een bewuste beslissing moet nemen over kwaliteit, kosten en snelheid”. Elk bedrijf moet aan zijn verwachtingen werken.

QA-professionals bevinden zich meestal niet in de positie om deze discussie te leiden. Ze kunnen proberen een bijdrage te leveren. Het kan vruchtbaarder zijn om de verwachtingen waaraan zij persoonlijk worden blootgesteld te managen. Een geïnterviewde vertelde me haar aanpak: “Het is onmogelijk om alles te testen. Bepaal samen met de producteigenaar het beste een tijdsvenster en de prioriteiten. De prioriteiten weerspiegelen het risico van niet testen. Als je niet tevreden bent, onderhandel dan opnieuw over het tijdsvenster en de prioriteiten.”

More Articles

• Hoe je je voorbereidt op en beslissingen over uitbrengen of niet uitbrengen overleeft
• Hoe testvaardigheden mij een betere automatiseringsontwikkelaar maakten
• 6 hacks voor kwaliteitsengineering voor teams met externe ontwikkelaars
• Neem je eigen hulpmiddelen mee… maar denk eerst twee keer na
• 14 onmisbare artikelen over softwaretesten ter inspiratie

6. Agile valkuil

Een sterk team dat zich voortdurend aanpast aan veranderende behoeften, een niet-bureaucratische manier om met verandering om te gaan, eenvoudige middelen voor planning en voortgangscontrole: de agilebeweging heeft een schat aan innovaties voortgebracht waar ontwikkelingsteams verstandig aan doen om van te profiteren. Toch lijkt agile de druk steeds verder op te voeren.

Het begint al met de benamingen: sprint betekent snel, velocity betekent snel, men faalt snel. Agile principes stellen code voorop; vooruitdenken wordt gemakkelijk afgedaan als verspilling. Zelfs de term scrum komt uit rugby, een sport waarin atleten elkaar op volle snelheid tackelen. Daardoor bevordert agile, zelfs tegen de eigen overtuiging in, snelheid boven kwaliteit. “Methodologieën zoals Agile en DevOps stimuleren het idee om alles nog sneller te doen”, klaagde een QA-professional.

De werking van bijvoorbeeld scrum is nog erger dan de benamingen. Het is niet zo dat degenen die Scrum hebben gecreëerd een burn-out wilden bevorderen. Maar scrum leidt teams op een dwaalspoor.

Ten eerste richt het de aandacht van het team op de backlog. Het is de taak van de product owner om dingen aan de backlog toe te voegen. Het is de taak van een teamlid om ze op te pakken en één voor één uit te voeren. Het is de taak van de scrum master om ervoor te zorgen dat dit sneller gebeurt. Daarnaast vereist agile voortgangscontrole kleine backlogitems die in enkele dagen kunnen worden uitgevoerd. Experts adviseren ook om vóór de sprint nauwkeurig uitgewerkte acceptatiecriteria op te stellen. Teamleden krijgen nauwkeurig gedefinieerde en kleine brokken werk om op te leveren. Ze rapporteren dagelijks hoeveel tijd ze nog nodig hebben om het af te ronden. De velocity vertelt iedereen hoe goed ze presteren. Micromanagers juichen en controleren elke minuut: gebrek aan controle, geen creatieve ruimte, de druk om sneller te worden: een ratrace.

Gegeven dit alles, doet het er in een ogenschijnlijk benarde situatie toe of het product geweldig is voor gebruikers? Absoluut niet, dat is de taak van het UX-team. Doet het ertoe of het zinvol is? De taak van de product owner. Doet het ertoe of de acceptatiecriteria volledig zijn? Opnieuw de taak van de product owner. Is het belangrijk dat er geen bugs zijn? De taak van de tester, zodra de acceptatiecriteria zijn doorlopen. Wat doet er wel toe? Dat ik mijn backlogitem op tijd afrond. Zie je de positie van Alan? Scrum leidt teams ertoe alle functionaliteiten te bouwen. Kwaliteit is Alans taak. De fundamentele regel wordt overtreden, de zaken worden erger.

Alans team houdt zich ook aan de toezegging. Ze vullen de sprint met zoveel backlogitems als de velocity aangeeft. Vervolgens zweren ze die op te leveren. De volgende fundamentele wet treft hen: onvoorziene dingen gebeuren. In plaats van de eed te breken, neemt het team sluiproutes en schrapt het een paar onderdelen van het testen. Op tijd klaar, goed gedaan! Een van de geïnterviewden verwoordde het heel duidelijk: “Het spelelement van het toezeggen aan een aantal story points creëert ongezonde concurrentie.”

Alans team is in de agile valkuil gevallen. Ze passen Scrum toe zonder agile te zijn. Vergelijk de volgende twee afbeeldingen: de eerste gaat over waar Scrum om draait, de tweede over waar agile volledig om draait.

Scrum draait om het proces om backlogitems om te zetten in een product.

Agile draait om het creëren van impact met een product en om de interacties tussen de betrokken personen: degenen die een product bestellen, degenen die het gebruiken en degenen die het creëren.

Hoewel Scrum een geweldig hulpmiddel is voor intrinsiek gemotiveerde agile teams, is het fataal in een top-down commandostructuur!

Belangrijkste punten

In de software-industrie is het belangrijk om verdedigingsmechanismen te ontwikkelen tegen stress en burn-out onder professionals op het gebied van softwaretesten. In sommige bedrijven meer dan in andere. Sommige situaties zijn echt benard, andere worden met opzet benard gemaakt. Maar de meeste situaties lijken veel benarder dan ze zijn. En dit leidt ertoe dat we onze drijfveren volgen, niet langer aan de conflicten werken en fundamentele regels negeren. 

De volgende tabel vat de raderen van een burn-outsysteem samen.

Belangrijke elementen van een burn-outsysteem

• Ervaren benardheid is het verschil tussen wat wij als onze taak zien en wat we kunnen opleveren. Ontdekken wat werkelijk het beste is om te bereiken, kan het burn-outsysteem ontmantelen.
• Drijfveren bepalen waar de energie naartoe stroomt en verhinderen ons om verstandig te handelen in een benarde situatie. Onze drijfveren ontdekken kan ons helpen minder energie te besteden en die verstandiger te gebruiken.
• Conflicten voeren de druk op, maken een team minder effectief en putten energie uit. Laten we een teamcultuur creëren waarin we conflicten verwelkomen en elkaar helpen.
• Fundamentele regels worden gemakkelijk genegeerd. Ze genegeerd zien worden is een zeker teken dat de zaken erger zullen worden. We moeten handelen!
• Teamstructuren bevriezen goede en slechte werkwijzen. Het veranderen van teamstructuren kan fundamenteel veranderen wie wat doet en hoe mensen met elkaar omgaan. Het kan de spelregels volledig veranderen.
• Vicieuze cirkels ontstaan door de wisselwerking tussen de actoren in en rond het team en maken de situatie steeds erger. Kunnen we de vicieuze cirkels herkennen waarin we verstrikt zijn geraakt? We moeten ze stoppen en herstellen!
• De agile valkuil bestaat uit het invoeren van agile raamwerken zonder agile te zijn. Het resultaat is een ratrace. Laten we ons richten op gebruikers, het creëren van een geweldig product en de manier waarop we met elkaar omgaan, in plaats van backlogitems af te werken.

Als QA-professional ben je misschien niet in de positie om de algehele situatie ten goede te veranderen. Maar waarschijnlijk kun je wel wat stress verminderen. 

Ik vroeg Jonathon Wright: “Waar heb je bedrijven of teams actie zien ondernemen om de mentale gezondheid onder QA-professionals te bevorderen? Wat werkt?”

Hij antwoordde, 

“Nadat ik het afgelopen jaar de Britse regering had geholpen zich voor te bereiden op de brexit, was ik buitengewoon onder de indruk van de arbeidsethos. Ik volgde mijn eerste verplichte cursus mindfulness, die buitengewoon nuttig was. Er waren specialisten op het gebied van geestelijke gezondheid aanwezig en zelfs steungroepen die wekelijks bijeenkwamen.”

Hij wees er ook op dat QA's veel kunnen doen om hun stress en angst op persoonlijk niveau te beheersen:

“Het leven is te kort om je zorgen te maken over de kleine dingen. Voor QA-professionals is het moeilijk om zich geen zorgen te maken in aanloop naar de grote release van een nieuw product of om zich verantwoordelijk te voelen voor de uitkomsten. Maar net als in aflevering II met Parveen moet je soms gewoon ‘laat het los, laat het los’ en niet ‘blijf kalm’.”

Jonathon Wright, presentator van de podcast The QA Lead

“Als iemand die gedurende mijn hele professionele loopbaan met angst heeft leren omgaan, heb ik de nodige valkuilen en uitdagingen gekend, maar ik ben er altijd sterker en beter in staat uitgekomen om mijn angst beter te beheersen—waarbij ik elke keer meer over mezelf leerde. De sector trekt wel mensen aan die zich in verschillende gradaties van het spectrum bevinden (waar ik mezelf ook toe reken). De meest getalenteerde mensen met wie ik de kans heb gehad om samen te werken, leden echter aan een psychische aandoening. Daarom beschouw ik mijn psychische aandoening als een superkracht!”

Zoals Jonathon aangaf, kun je met een beetje geluk en de juiste instelling een stressvolle baan omvormen tot een lonende baan. Ik moedig je aan het perspectief te omarmen dat het concept van een burn-outsysteem biedt. Laat je angst los en blijf kalm. Kijk vervolgens verder dan voorschriften, processen en hulpmiddelen. Richt je op wat er echt toe doet: hoe jij en je teamgenoten elkaar helpen om geweldige producten te creëren.