Burn-out bij softwaretesten: 6 oorzaken & hoe je het oplost
Is het mogelijk om een situatie te creëren in een softwareontwikkelingsteam waarin de kans zeer groot is dat een tester een burn-out krijgt?
Zo ja, wat kunnen testers leren van dit gedachte-experiment?
Het blijkt dat een burn-out onder professionals in softwaretesten niet alleen een gedachte-experiment is in de softwaretestindustrie — het is een echt en wijdverbreid probleem dat veel ontwikkelaars, engineers en testers treft.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ik ben dieper ingegaan op het probleem van burn-outs bij softwaretesten en heb daarbij de volgende vragen gesteld:
- Hoe ziet een burn-out er in deze sector uit?
- Hoe groot is dit probleem?
- Waardoor ontstaan systemen waarin softwaretesters een burn-out krijgen?
- Hoe kunnen we het probleem van burn-outs ontrafelen — 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 waar velen van ons in de IT-sector mee te maken hebben. Ik weet zeker dat jij ook jouw deel van de stress ervaart. In mijn situatie is een burn-out de afgelopen jaren helaas een steeds prominenter onderwerp geworden.
Is een burn-out een probleem?
Toen ik Jonathon Wright vroeg: “Hoe groot denkt u dat het probleem van burn-outs onder QA-professionals is?”, was dit zijn antwoord:
“Het is een enorm probleem. Beroemde woorden: Je kunt niet voortdurend sprinten.”
Jonathon Wright, presentator van de podcast The QA Lead
Hij legde verder uit:
“Methodologieën zoals Agile en DevOps moedigen het idee aan om alles nog ‘sneller’ te doen. Hoe levert een QA-professional meetbare waarde in een omgeving waarin je snel faalt en snel leert?
In een recente podcast van QALead kwam de term ‘vertragen om te versnellen’ ter sprake. Tenzij bedrijven falen vieren (wat maar heel weinig bedrijven doen), help je het teamtempo niet vooruit wanneer je faalt.
De aanwijzing zit in de titel van de veel te vaak gebruikte Burndown-grafiek. De gamificatie van het toezeggen van een aantal story points creëert ongezonde concurrentie.
"Je wordt gedwongen om met minder meer te doen, waarbij je werkt volgens de onrealistische verwachting dat werk in sprints van twee weken kan worden opgeleverd."
Jonathon Wright, presentator van de podcast The QA Lead
Hoe ziet een burn-out bij QA eruit?
Een burn-out is geen op zichzelf staand geval in de softwaresector — maar hoe ziet het eruit?
Hier volgen reacties van professionals in softwaretesten die laten zien op welke manieren burn-outs binnen QA de kop opsteken.
“We moeten onze waarde bewijzen. Teams vertellen me dat ze agile zijn en geen testers nodig hebben.”
“Angst. Het is moeilijk voor QA-professionals om zich niet voorafgaand aan een grote release zorgen te maken of zich verantwoordelijk te voelen voor welke uitkomsten dan ook.”
“Tijdsdruk. Testers zijn altijd de laatsten. En ik krijg nooit de tijd die ik nodig heb. Bovendien wordt die gehalveerd omdat ontwikkelaars uitlopen.”
“Onrealistische verwachtingen. Ik zou eindeloos kunnen testen en nog steeds 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 blijft aandringen, kan het persoonlijk worden.”
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 moeten zijn, opschieten, jezelf overmatig inspannen, sterk moeten zijn of anderen tevreden willen stellen. Raadpleeg transactionele analyse voor meer informatie.
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 nog veel meer. We kennen ze.
Enige tijd geleden begon ik burn-out vanuit een systemisch perspectief te bekijken en creëerde ik een simulatiespel waarin spelers invloed kunnen uitoefenen op het lot van een softwareontwikkelingsteam. 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, dat wil zeggen een systeem dat zo is opgezet dat sommige leden van een team uiteindelijk een burn-out krijgen. Je kunt op mijn blog een glimp van het spel opvangen.
Deze systemische aanpak werkt ook voor verschillende rollen binnen een team. Ik heb dit gedaan voor professionals op het gebied van gebruikerservaring en was verrast door 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 om een extra strijd aan te gaan en eraan onderdoor te gaan.
Hieronder duik ik in 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 fabriceren, wil ik jullie kennis laten maken met Alan en zijn verhaal.
Alan heeft bijna tien jaar ervaring met softwaretesten, en dan vooral met prestatietesten. Hij staat op het punt zich bij een ontwikkelingsteam aan te sluiten. Het team heeft tien sprints achter de rug en nog vier te gaan tot een eerste release.
Hoe was Alans eerste dag in het project?
Alan: Er is veel voor mij te doen. De software is van lage kwaliteit. Ik verwacht veel onopgemerkte bugs en ben bang voor 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 onder het grote publiek uitrollen. Het team staat te popelen om daar van mijn expertise te profiteren.
Tot nu toe is Alan tamelijk 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 vol. Ik had ook veel meer tijd nodig dan verwacht om de software te leren kennen en de bugs die ik vond te rapporteren.
Markus: Kon je de nieuwe verhalen testen die door het team waren 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 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 óf onbelangrijk óf helemaal geen bugs. Laten we ze eerst zorgvuldig beoordelen voordat we conclusies trekken.
Alan: Het was voor mij moeilijk om uit de backlogitems te begrijpen wat de software zou moeten doen. Een specificatie zou echt helpen.
Ontwikkelaar: Over mijn lijk! We willen geen Watervalmodel. Het is grotendeels een kwestie van gezond verstand. Kom gewoon naar ons toe en vraag het. Hoe gaat het met de prestatietests?
Alan: Ik zit vast. Ik krijg de tool niet tegen de servicelaag aan de praat vanwege 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 na sprint dertien, met nog één sprint te gaan, steeds duidelijker. Dit zijn de besluiten uit deze retrospectieve:
- Veel bugs zijn 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 konden niet worden afgerond. We hebben twee dagen verloren aan het weggooien van nutteloze bugrapporten. Alan markeert elke bug op relevantie. Vraag het bij twijfel aan de producteigenaar.
Heb je het gezien? Het team heeft twee userstories niet afgerond en wist Alan de schuld te geven!
Stel je de volgende sprint voor, waarin userstories 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 producteigenaar! En ze hebben de prestatietests ook nog weggehaald. Dat was juist de reden dat ik überhaupt aan dit project begon. Mijn baas is ontevreden. Hij wilde dat ik het voorbeeld gaf van hoe je testers in agile teams opneemt. Ik zal er toch voor moeten vechten, 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
- Erkend worden als expert op het gebied van prestatietesten: mislukt
- Nieuw ontwikkelde functionaliteit grondig kunnen testen: mislukt
- De al gebouwde functionaliteit grondig opnieuw kunnen 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
- Bang zijn om mijn baan te verliezen: behaald
- Een burn-out krijgen: er in volle vaart naartoe
Dit is een klassiek geval van een burn-outsysteem. Wat creëert dit systeem en hoe kunnen we ons ertegen wapenen?
Wat creëert een burn-outsysteem?
Voor Alan is het vanaf het begin een hopeloze zaak, zou je kunnen zeggen. En daarin zou je gelijk hebben. Alan bevindt zich in een burn-outsysteem dat al geruime tijd binnen het team actief is. Het burn-outsysteem isoleert Alan als een roofdier dat zijn prooi uitkiest. 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 een burn-out krijgen. 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.
- De angst om verantwoordelijk te zijn voor een mislukte release zorgt ervoor dat Alan op bugs jaagt.
- Iets zorgt ervoor dat teamleden boven alles functionaliteit bouwen.
Drijfveren veranderen de handelwijze. 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 stelt nooit de vraag of het bouwen van alle functionaliteit wel het juiste is om te doen. Alan vraagt zich evenmin af of het opsporen van bugs wel passend is.
Voor de meesten van ons is het moeilijk om ons ervan bewust te worden dat een drijfveer de controle heeft overgenomen. Gelukkig hebben psychologen ze bestudeerd. Begin voor persoonlijke drijfveren met transactionele analyse. Op teamniveau is groepsdenken een goed vertrekpunt. Je vindt daar volop advies.
Met betrekking tot angst voorafgaand aan een release adviseerde een ervaren QA-professional: “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 prestatietests opzetten. De hoogste prioriteiten zouden kunnen zijn dat het team de kritieke bugs verwijdert en over het algemeen een hogere kwaliteit levert. Een manier om de stress die met repetitieve taken gepaard gaat te verminderen, is door gebruik te maken van toonaangevende tools die zijn ontworpen voor softwaretesten.
2. Conflicten laaien op en worden persoonlijk
Samen met de drijfveren laaien er binnen het team conflicten op. 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 het lijf 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. Omdat Alan tien jaar als tester heeft gewerkt, is hij waarschijnlijk behoorlijk deskundig. Toch ziet het team hem als een zwakke schakel en gedraagt het zich ook zo. Hoe langer dit duurt, hoe dieper het wordt. Het raakt zelfs 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 als volgt beschrijft: “Tenzij bedrijven falen vieren, help je het team elke keer dat je faalt niet om sneller te worden”.
3. De teamstructuur beïnvloedt de teamdynamiek
Alans team 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 eenvoudigweg van uit dat Alan deze structuur volgt. 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. Backlogitems bieden weinig hulp bij hoe het precies zou moeten werken. Terwijl het team de details bespreekt van wat ze in de volgende sprint zullen doen, probeert Alan uit te zoeken wat hij uit deze sprint moet testen. Vervolgens stelt hij vragen vlak voordat de ontwikkelaars vertrekken en test hij in het weekend. Fijn dat het team bespreekt wat er moet worden vastgelegd. Alan kan dan testen zonder de ontwikkelaars lastig te vallen. Bingo.
De teamstructuur isoleert Alan steeds meer. 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 wendbaar 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 continu getest, niet alleen aan het einde van de sprint.
4. Negeer fundamentele regels en vraag om problemen
Alans team negeert fundamentele regels van software-engineering.
Hier zijn er vijf:
- Onverwachte dingen gebeuren. Als daar niet genoeg ruimte voor is, leidt dat op de lange termijn tot haast, kortere routes, domme fouten, hoogoplopende conflicten en daardoor tragere vooruitgang.
- Druk leidt tot vertraging. Druk zorgt ervoor dat er minder ruimte is voor onverwachte dingen.
- Kwaliteit ontstaat gaandeweg. Het team moet een kwaliteitscultuur hebben. Testen is slechts één stukje van de puzzel. En één teamlid dat alleen tegenover alle anderen staat, faalt meestal.
- 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 vertraagd project maakt het nog later.
- 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 telkens wanneer mensen ze negeren, worden de zaken erger. En dat gebeurde dus ook met Alan.
5. Een als krap ervaren situatie zet het in gang
Hoe komt het dat het team zulke fundamentele zaken negeert? Eenvoudig. Dit is typisch voor een krappe situatie waarin de gegeven omstandigheden (opleveringen, beschikbare tijd en het team) niet genoeg flexibiliteit bieden om met onverwachte dingen om te gaan. Bekend terrein, meegemaakt, een glasheldere casus. Burn-outsystemen benutten de enige variabele in een krappe constellatie: hoe hard het team werkt, oftewel hoeveel energie teamleden uit hun batterijen verbruiken.
De hamvraag: bevindt Alans team 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 bepaling zijn, een stimulans, een geweldige marktkans, sterke druk van een leidinggevende, een gedane belofte, een wens van een klant of een overheidsvoorschrift.
Alan verwacht massa's fouten en door angst jaagt hij erop. De hamvraag voor hem: is het vinden van de fouten in dit geval echt zo'n belangrijke stap? We kunnen alleen maar speculeren en dat deed Alan dus ook. Hij ging ervan uit dat dit zo was.
De perceptie van een krappe situatie is een belangrijke hefboom om een burn-outsysteem te doorbreken. Daarachter zit nog een fundamentele regel van software-engineering:
- Te hoge verwachtingen. Belanghebbenden - inclusief de ontwikkelaars zelf - hopen, verwachten of eisen meer dan een softwareteam realistisch 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 op het gebied van management van belanghebbenden en verwachtingen, conflictmanagement, requirements engineering, wendbaar werken en dergelijke te bestuderen.
In ieder geval moet je de precieze aard van het conflict begrijpen. Hoe sterk is het? Waardoor wordt het gedreven? 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 bij te dragen. Het kan vruchtbaarder zijn om de verwachtingen die persoonlijk aan hen worden gesteld, te managen. Een geïnterviewde vertelde me haar aanpak: “Het is onmogelijk om alles te testen. Bepaal het beste een tijdsvenster en de prioriteiten samen met de producteigenaar. De prioriteiten weerspiegelen het risico van niet testen. Ben je niet tevreden, heronderhandel dan het tijdsvenster en de prioriteiten.”
6. De valkuil van wendbaar werken
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 het vuur aan te wakkeren.
Het begint al bij de benamingen: sprint betekent snel, snelheid 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 met volle snelheid tackelen. Zo bevordert agile, zelfs tegen de eigen overtuiging in, snelheid boven kwaliteit. “Methodologieën zoals Agile en DevOps moedigen het idee aan 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 het verkeerde pad.
Ten eerste richt het de aandacht van het team op de werkvoorraad. Het is de taak van de producteigenaar om zaken aan de werkvoorraad 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 scrummaster om ervoor te zorgen dat dit sneller gebeurt. Vervolgens vereist agile voortgangscontrole kleine werkvoorraaditems die binnen enkele dagen uitvoerbaar zijn. Goeroes raden ook aan om vóór de sprint nauwkeurig uitgewerkte acceptatiecriteria te hebben. Teamleden krijgen precies gedefinieerde en kleine brokken werk om op te leveren. Ze melden dagelijks hoeveel tijd ze nog nodig hebben om het af te ronden. De snelheid 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 producteigenaar. Doet het ertoe of de acceptatiecriteria compleet zijn? Opnieuw de taak van de producteigenaar. Is het belangrijk dat het foutloos is? De taak van de tester, zodra de acceptatiecriteria zijn doorlopen. Wat doet er wel toe? Dat ik mijn werkvoorraaditem op tijd afrond. Zie je de positie van Alan? Scrum stuurt teams ertoe alle functies te bouwen. Kwaliteit is Alans taak. De fundamentele regel wordt overtreden, en de situatie verslechtert.
Alans team houdt zich ook aan de verplichting. Ze vullen de sprint met zoveel werkvoorraaditems als de snelheid aangeeft. Vervolgens zweren ze dat ze die zullen opleveren. De volgende fundamentele wet treft hen: er gebeuren onvoorziene dingen. In plaats van de eed te breken, neemt het team kortere wegen en laat het een paar onderdelen van het testen schieten. Op tijd klaar, goed gedaan! Een van de geïnterviewden verwoordde het heel duidelijk: “De gamificatie van het zich vastleggen op een aantal verhaalpunten creëert ongezonde concurrentie.”
Alans team is in de agilevalkuil gevallen. Ze passen Scrum toe zonder agile te zijn. Vergelijk de volgende twee afbeeldingen: de eerste gaat over Scrum, de tweede gaat over waar agile werkelijk om draait.
Scrum draait om het proces waarmee werkvoorraaditems worden omgezet 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 funest in een hiërarchische commandostructuur!
Belangrijkste punten
In de software-industrie is het belangrijk om beschermingsmechanismen te ontwikkelen tegen stress en burn-out onder professionals in 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 daardoor volgen we onze drijfveren, stoppen we met werken aan de conflicten en negeren we fundamentele regels.
De volgende tabel vat de tandwielen van een burn-outsysteem samen.
Belangrijkste elementen van een burn-outsysteem
- Ervaren benardheid is de kloof tussen wat wij als onze taak zien en wat wij 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 dat we verstandig handelen in een benarde situatie. Onze drijfveren ontdekken kan ons helpen minder energie te verbruiken en die verstandiger in te zetten.
- Conflicten wakkeren de situatie aan, 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 situatie zal verslechteren. We moeten handelen!
- Teamstructuur bestendigt goede en slechte praktijken. 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 uit de wisselwerking tussen de actoren in en rond het team en maken de situatie steeds erger. Kunnen we de vicieuze cirkels herkennen die ons in hun greep hebben? We moeten stoppen en ze oplossen!
- De agilevalkuil is het invoeren van agilekaders 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 werkvoorraaditems weg 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 gezien dat bedrijven of teams actie 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 werkethiek. Ik volgde mijn eerste verplichte mindfulnesscursus, 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-professionals 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. Het is voor QA-professionals moeilijk om zich geen zorgen te maken vóór een grote lancering van een nieuw product of zich verantwoordelijk te voelen voor de resultaten. Maar net als in Aflevering II met Parveen moet je soms gewoon ‘laat het los, laat het los’ en niet ‘cool blijven’.”
Jonathon Wright, presentator van de podcast De QA-leider
“Als iemand die gedurende mijn hele professionele carrière met angst heeft leren omgaan, heb ik de nodige valkuilen en uitdagingen ervaren, maar ik ben er altijd sterker en in een betere positie uitgekomen om mijn angst beter te beheersen—elke keer leerde ik meer over mezelf. De sector trekt inderdaad mensen aan die zich op verschillende punten 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, hebben echter aan psychische aandoeningen geleden. Daarom beschouw ik mijn psychische aandoening als een superkracht!”
Zoals Jonathon aangaf, kun je met een beetje geluk en de juiste instelling van een stressvolle baan een lonende baan maken. Ik moedig je aan het perspectief te omarmen dat het concept van een burn-outsyndroom 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.
