Neuer Job, neues Projekt, neues Team – klingt aufregend und motivierend, nicht wahr?
Vor kurzem traf ich meine Freundin, Alice. Vielleicht kennt ihr sie: https://www.zuehlke.com/de/insights/alice-im-agile-land-eine-tester-geschichte.
Alice hat vor einigen Wochen in einem neuen Projekt gestartet, doch das lief alles andere als motivierend. Abgesehen von den schwerfälligen und verwirrenden Prozessen, um die nötigen Applikationen und Berechtigungen zu erhalten, stand Alices neues Team unter enormem Druck und hatte weder Zeit noch personelle Ressourcen um sich um ihre Einschulung zu kümmern. Erschwerend hinzu kommt, dass Alice als unverbesserliche Perfektionistin in den ersten Tagen immer schon alles wissen, können und produktiv sein will. Keine optimale Kombination, wie ihr euch denken könnt. Und so war Alice schnell demotiviert und begann an sich zu zweifeln.
An dieser Stelle möchte ich festhalten, dass natürlich nicht alle neuen Engagements schlecht oder holprig starten, aber es gibt gewisse Muster und Verhalten, die sich nach meiner Erfahrung bei suboptimalen Starts häufen. «Wie kann ich Alice also wieder motivieren?», habe ich mich gefragt.
Und hier ist mein Versuch, Alice und euch ein Lächeln ins Gesicht zu zaubern und mein Aufruf die Dinge etwas lockerer zu nehmen.
Die Hitliste der demotivierendsten Dinge, denen Alice als QA Spezialistin (a.k.a. QA, Tester:in, Test/QA Engineer:in, QA Spezialist:in etc.) begegnet ist (bis dato) und eine, nicht ganz ernst gemeinte, Anleitung wie ihr die neue QA-Person möglichst schnell wieder loswerdet.
Keine Zeit für die Einarbeitung Einschulung kostet nur Zeit und personelle Ressourcen, im schlimmsten Fall Development-Ressourcen! Für die Einarbeitung einer neuen QA-Person jemand aus dem Team abzustellen geht gar nicht. Der oder die Neue ist schliesslich im Qualitätsbereich tätig. Sie/er wird sich selbständig zurecht finden…das ist ja wohl das Mindeste. QAs wissen doch immer was richtig und falsch ist, ergo werden sie auch selbst herausfinden, was sie wissen müssen, um ihren Job machen zu können.
Veraltete und/oder verwirrende Dokumentation (vorzugsweise an den verschiedensten Ablageorten) QAs müssen sich selbst zurechtfinden können. Wenn sie gut sein wollen in der Qualitätssicherung, dann ist das Herausfinden welche Dokumentation gilt, eine leichte Übung und es muss kein anderes Teammitglied für persönliche Erläuterungen abgestellt werden.
Rollenbeschreibungen sind a) in Stein gemeisselt oder b) überflüssig a) Testing und QA ist dasselbe und Personen in diesen Rollen haben dieselben Aufgaben, nämlich Tests zu automatisieren und auszuführen. Ausserdem sind sie für die Qualität verantwortlich und haben dafür auch den Kopf hinzuhalten. b) Wieso sollte es eine Rollenbeschreibung für QA geben? Das weiss doch jeder; QA sind die Personen, die für die Qualität verantwortlich sind.
Aufgaben und Erwartungen sind implizit Am besten wird gar nicht über die konkreten Aufgaben und Erwartungen an QA-Personen gesprochen und wenn, dann vorzugsweise in Abwesenheit der Betroffenen. Auch Personen in anderen Rollen oder Disziplinen können sehr gut Auskunft geben über die Aufgaben einer QA-Person. Wie bereits oben angeführt ist die Rolle doch sonnenklar und bedarf keiner weiteren Diskussionen. Sollte es doch zu einer Diskussion über die Aufgaben kommen, sind die Ansichten der betroffenen Person vernachlässigbar.
Micromanagement QA-Spezialist:innen, überhaupt alle Mitarbeitenden, müssen unbedingt micro-gemanaged werden. Sonst läuft entweder nichts, viel zu langsam oder völlig falsch.
Druck, Druck und noch mehr Druck (vorzugsweise unbegründet) QAs sind es gewohnt unter Druck zu arbeiten. Sie brauchen das geradezu, um ihre Arbeit richtig zu machen. Am besten gibt man ihnen das direkt zu verstehen.
Selbständiges Denken ist unerwünscht Euer/eure QA denkt selbstständig? Das muss ganz schnell unterbunden werden. So weit kommt es noch, dass sie/er Bestehendes in Frage stellt oder noch schlimmer, Dinge verändern möchte.
Diese Rolle gibt es nicht im Team Agile/Scrum/SAFe…schreibt nichts von QAs im Team. D.h. diese Personen gehören nicht ins (Dev)Team. Sie sind keine Entwickler:innen und somit auch nicht Teil des Teams. Manche, die richtig nervigen, QAs argumentieren dann, dass alle im Team gemeinsam ein Produkt entwickeln, also jede:r Entwickler:in ist, und alle Skills vertreten sein sollen… das steht übrigens auch im Scrum Guide[1]…bla, bla, bla…sie sollen doch bitte einfach am Ende ihre Tests machen und auf grün setzen. Das kann doch nicht so schwer sein.
Testautomatisierung ist alles QAs die nicht automatisieren können sind überflüssig. So jemand kann man nicht brauchen. Wir sind agil und schnell. Manuelles Testing ist viel zu langsam. Am besten stellt man die Person vor die Wahl, sich entweder die entsprechenden Automatisierungs-Skills anzueignen oder sich anderweitig zu orientieren.
Der Mensch hinter der Rolle ist irrelevant Bloss keine Zeit damit verschwenden den Menschen hinter der QA-Rolle kennenlernen zu wollen! Das bringt nur Unruhe ins Team. Sie/er könnte Erfahrungen, Meinungen oder Skills mitbringen, die bestehende Prozesse verändern.
QAs sind so! QA-Personen sind alle gleich und das wird auch immer so sein. Sie mögen es anderer Leute Arbeit schlecht zu machen, mit dem Finger auf die Fehler anderer zu zeigen. Sie mögen es Gatekeeper zu sein und geniessen es, wenn sie etwas blockieren können. Äusserst unsympathische Leute sind das.
Development testet– wir brauchen keine/n QA Unsere Entwickler:innen schreiben ihre Tests selber und automatisieren sie direkt. Wir brauchen also keine eigene Person für QA. So jemand hält nur das Development auf und möchte viele unnötige Tests schreiben und diese noch manuell ausführen. Dafür haben wir keine Zeit.
QAs geben Schulungen, erledigen Administratives und kümmern sich um Sonstiges (wofür anderes Personal zu schade ist) Das QA-Team hat zwischen den Releases sowieso nichts zu tun und kann deshalb gut die Einschulung von neuen Mitarbeitenden oder das Nachdokumentieren übernehmen. Sie kennen die Applikationen durch das Testing fachlich und technisch gut. So muss keine Fachperson für die Einschulung der Neuen abgestellt werden. BA/PO können sich auf zukünftige Sprints und Releases konzentrieren.
All die Kleinigkeiten und nonverbale Kommunikation, die QAs das Gefühl geben, kein vollwertiges Teammitglied zu sein (vor allem, weil sie keinen Code schreiben)
Wow, da sind doch ein paar mehr Punkte zusammengekommen als ich zu Beginn gedacht hätte. Die Liste erhebt zudem keinerlei Anspruch auf Vollständigkeit. Doch lässt sich Alice davon unterkriegen? Offensichtlich nicht, sonst hätte sie schon längst einen anderen Job. Zum Glück. Sonst würde sie nicht die Erfahrung machen mit den großartigen Menschen zusammenzuarbeiten, die nicht nur Qualität und Qualitätssicherung wichtig und ernst nehmen, sondern noch vielmehr Alice als Mensch mit ihren wertvollen Eigenschaften schätzen.
Was diese Menschen anders machen und warum sie Alice so schnell nicht loswerden, dazu ein anderes Mal mehr.
[1] «Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint…The specific skills needed by the Developers are often broad and will vary with the domain of work.» Scrum Guide 2020)