Trust in software, trust in people: Wie Teams vertrauensvoll zusammenarbeiten können

Warum wir mehr Vertrauen innerhalb der Projektteams haben sollten. Wie Vertrauen und psychologische Sicherheit entstehen. Und warum wir als Quality Assurance eine besondere Rolle spielen.

Als Tester ist es unsere Aufgabe, Vertrauen in neue und bestehende Software zu schaffen. Wir analysieren die Testobjekte, identifizieren Risiken, testen manuell und toolgestützt, berücksichtigen die Sicherheit, Barrierefreiheit und Performance. Wir evaluieren APIs und Oberflächen, werten Logfiles aus, testen Algorithmen, Dokumente und Daten.

Wir hinterfragen Prozesse, arbeiten mit Kanban-Boards, treffen uns zum Scrum-Daily, führen Retrospektiven durch, nutzen Behaviour-Driven-Development-Ansätze, stellen mit CI/CD-Tools einen kontinuierlichen Fluss aller Artefakte sicher.

Wir tracken alle Incidents mittels Dashboards, wir erstellen Aufwandsabschätzungen, Testreport, Abschlussberichte, Kosten-Nutzen-Rechnungen und liefern den Stakeholdern alle verfügbaren Daten.

Wir sind Experten für Abläufe und Produkte, denn Qualität entsteht durch Regelwerke, Best Practices und Objektivität.

Kurzum: Trust the process.

Der Blick zurück

In einem meiner ersten QA-Projekte hatte ich die Gelegenheit, die Qualitätssicherung eines elektronischen Gerätes zu übernehmen. Nach Abschluss der Entwicklung aller Komponenten (Hardware, Firmware, Konfigurations-Software) galt es, mittels manueller Tests die Qualität zu überprüfen. Heute würde ich es „End-to-End-Test“ nennen, damals hieß es „Freigabetest“.

Im Projektteam waren bereits alle Fachgebiete vertreten – von der Hardware-Entwicklung (Mechanik, Elektronik) über die Software-Entwicklung (Firmware, Windows-Konfiguration) bis hin zur Fertigung. Und jetzt auch die QA.

In den ersten Gesprächen mit diesem Team und den Stakeholdern begegneten mir Vorbehalte wie:

• „Du sprichst nicht unsere (Entwickler-)Sprache.“
• „Du bist jetzt dabei, weil wir laut Prozessbeschreibung eine QA brauchen.“
• „Du wirst nur Fehler finden, die kein Kunde jemals finden würde.“
• „Du kannst erst testen, wenn das Produkt zum Kunden gehen könnte. Wir werden also nur langsamer und halten schon jetzt kaum unsere Projektpläne.“

Die größte Herausforderung dieses Teams war die fach- und termingerechte Umsetzung aller Anforderungen. Im Team mangelte es nicht an Fachwissen. Es fehlte aber das Vertrauen gegenüber der QA und die Sicherheit, bestehende Prozesse zu verändern.

Die Performance von Teams

Im agilen Manifest findet sich der Punkt „Individuals and interactions over processes and tools“. Doch Hand aufs Herz: Nehmen wir uns im Projektalltag ausreichend Zeit, das Miteinander zu hinterfragen? Ist das Miteinander wichtig, um die „Produktivität eines Teams“ zu beschreiben? Welche Faktoren braucht ein funktionierendes Team, um „Performance“ zu erreichen?

Oft wird hierfür das Modell von Dr. Meredith Belbin zitiert. Ein heterogenes Team, in dem alle neun Rollen (siehe Abbildung 1) zusammenarbeiten, führt dabei zur höchsten Wertschöpfung. Diese Sichtweise gilt dabei für jedes Projekt und ist nicht auf die Software-Entwicklung eingeschränkt. Zweifelsohne beschreibt dieses Modell, WAS die Teammitglieder tun. Es fehlt jedoch die Antwort auf die Frage, WIE die Zusammenarbeit erfolgt.

Hierfür bedarf es weiterer Modelle, anhand derer ein „gutes Team“ von einem „High Performance Team“ unterschieden werden kann. Eine mögliche Antwort dazu liefert Google mit dem Projekt „Aristoteles“ [1], in dem fünf Faktoren identifiziert wurden:

1. Psychologische Sicherheit und Vertrauen
2. Zuverlässigkeit
3. Struktur und Klarheit
4. Sinnhaftigkeit (Einen Sinn in der eigenen Tätigkeit sehen)
5. Wirkung (Eine positive Wirkung durch das eigene Wirken haben)

Anders formuliert:

• Ist es akzeptiert und gewünscht, offen über Fehler zu sprechen und Projekt-Risiken zu benennen, ohne Schaden für die eigene Person zu befürchten?
• Werden bei Problemen Lösungen oder Schuldige gesucht?
• Werden Themen auf die „lange Bank“ geschoben, mit „Das ist jetzt so!“ abgetan und Entscheidung basierend auf der Hierarchie statt auf der Projekt-Expertise getroffen?

Willkommen in der Welt der menschlichen Interaktion, in der Welt von „Psychologischer Sicherheit“ und ihrem kleinsten Baustein „Vertrauen“.

Vertrauensformel

Wie entwickelt sich „Vertrauen“? Welche Fähigkeiten und Verhaltensweisen zeigen vertrauensvolle Menschen?

Um vorweg das Offensichtliche zu benennen: Wir können niemanden überreden, uns zu vertrauen. Wir können jedoch Verhaltensweisen zeigen, die Vertrauen aufbauen oder zerstören.

Das „Vertrauensvolle Handeln“ basiert im Wesentlichen aus vier Bausteinen (ich referenziere hier das Modell der „Vertrauensformel“ [2]):

Die Komponenten im Einzelnen:

„Vertrauen“ bezieht sich dabei immer auf die Interaktion zweier Personen – wie gesagt, wir reden vom kleinsten Nenner in Team-Dynamiken. Und gerade in der Forming-Phase eines Teams ist es wichtig, über regelmäßiges Feedback Vertrauen entstehen zu lassen.

Tipps für die praktische Umsetzung:

Nutzt dieses Modell in einer Retrospektive, um das Verhalten der Team-Mitglieder zu reflektieren. Wichtig: Es geht niemals um Kritik an einer Person selbst, sondern um Verhaltensweisen, die diese Person zeigt.

Folgende Fragen können hilfreich sein, diese Reflexion zu begleiten:

1. Welche der vier Dimensionen ist für dich fundamental / am wichtigsten?
2. Welche Dimension ist deine Stärke? Wie zeigst du sie?
3. Wo hast du das größte Potenzial? Wie kannst du dieses Potenzial für dich aufbauen?

Aus der Erfahrung sei ergänzt: Es sind oftmals kleine Dinge, die hier – einmal benannt – große Wirkung entfalten können.

Psychologische Sicherheit

Wer noch einen Schritt weitergehen möchte, erweitert den Blick von der Interaktion zweier Projektmitglieder auf die Frage, wie das gesamte Team agiert. Wie viel „Veränderung und Innovation“ ist es bereit, einzugehen? Werden Schwächen und Schwierigkeiten angesprochen? Mit welchen Reaktionen ist zu rechnen? Ist gar ein Scheitern erlaubt?

Basierend auf den Arbeiten von Timothy R. Clark lässt sich „Psychologische Sicherheit“ in vier Stufen erfassen [3] (siehe Abbildung 2). Es lohnt sich, diese vier Stufen bei neuen Teams oder Team-Veränderungen nacheinander bewusst zu gestalten.

Tipps für die praktische Umsetzung:

Aufgrund der Tiefe der Diskussionen rate ich, hierfür separate Termine vorzubereiten, um die folgenden Fragen in Workshops zu reflektieren:

• Auf welcher Stufe sehen sich die einzelnen Personen?
• Ist das Team bereit, die nächste Stufe in Angriff zu nehmen?

Wichtig ist:

• Startet mit Feedback innerhalb des Teams. Schafft dazu eine ruhige Atmosphäre, gern in 1:1-Situationen.
• Stellt sicher, dass alle Beteiligten gehört werden. Fragt aktiv nach, trainiert aktives Zuhören.
• Achtet auf einen respektvollen Umgang.
  Bei Fehlern geht es nie um die Frage, wer den Fehler verursacht hat, sondern um die Frage, wie der Prozess zu gestalten ist, dass der Fehler nicht erneut auftritt (oder gar nicht erst entstehen kann).
• Gebt eigene Fehler und Schwächen zu.

Bedankt euch, wenn ihr Unterstützung erhalten habt.

Insbesondere in hierarchisch geführten Unternehmen ist es schwer, in die Stufe 4 dieses Modells zu gelangen. Prozesse bleiben vorgegeben, werden nicht überdacht und neu aufgebaut. Verbesserungsvorschläge enden trotz eines „Kontinuierlichen Verbesserungs-Prozesses“, weil sie nie vorgeschlagen oder erprobt werden.

Doch zurück zur Software-Entwicklung und der Frage: Welche Rolle spielt QA in Bezug auf Vertrauen?

QA als Führungsrolle

In einem Online-Artikel beschreibt Javier Lopez das Wirken von QA wie folgt:

„The QA role is a leadership role, because a QA needs to find quality problems inside the current development process and convince people in the team to fix them.”

Ich mag diese Sichtweise. Es ist eine essenzielle Aufgabe, als QA das Vertrauen in Software zu liefern. Gleichzeitig müssen wir das Thema „Qualität“ in das gesamte Team hineintragen. Wir können diese Führungsrolle wahrnehmen, ignorieren oder aktiv gestalten. Wir können über Vertrauen in Retrospektiven sprechen oder – mein bevorzugtes Format – in ganztägigen Workshops reflektieren.

Ein solches Seminar sollte dabei Raum für Diskussionen lassen, ergänzt um zeitlichen Freiraum und eine Verpflichtung auf die VEGAS-Regel. Mit dieser Regel ist die Verschwiegenheit der Teilnehmer und die Vertraulichkeit der Diskussion gemeint. Die konkrete Ausgestaltung des Tages ist vielschichtig und anhand der Gegebenheiten im Team individuell zu planen:

• „Vertrauen“ als einziges Workshop-Thema. Hier liegt der Fokus auf einer persönlichen Reflexion über jede der Vertrauens-Dimensionen.
• „Vertrauen“ in Kombination mit „Psychologischer Sicherheit innerhalb des Teams“, um die Team-Performance zu erhöhen.
• „Vertrauen“ in Kombination mit „Psychologischer Sicherheit innerhalb der gesamten Organisation“, um eine gemeinsame Sprache für Unternehmenskultur und Werte zu definieren.

Des Weiteren muss geklärt sein, wie die Maßnahmen in den folgenden Tagen und Wochen umgesetzt werden können. Gibt es interne Buddy- oder Mentoring-Systeme? Werden begleitende Coaching-Maßnahmen angeboten? Welche Möglichkeiten und Einschränkungen für Veränderungen gibt es? Gibt es überhaupt den Willen und das Bedürfnis, anders zusammenzuarbeiten?

Der (zweite) Blick zurück

Doch selbst, wenn kein großer Rahmen zum Austausch über „Vertrauen“ vorhanden ist, können wir im Kleinen vertrauensvoll agieren:

• Den Entwickler:innen zuhören und offene Fragen stellen
• Prozesse verstehen wollen und nicht sofort verändern
• Sich Zeit nehmen, gemeinsam gefundene Bugs besprechen, aus Kundensicht einordnen und Verständnis fördern

Rückblickend haben mir diese wenigen Punkte den Weg vom „Freigabetester“ zum vollwertigen Team-Mitglied geebnet. Wir haben gemeinsam Anforderungsdokumente erstellt und überarbeitet, Testpläne entwickelt sowie Prioritäten und Risiken festgelegt.

Wir haben auf Augenhöhe diskutiert. Wir haben gelernt, vertrauensvoll und wertschätzend miteinander zu arbeiten.

Wir sind gemeinsam besser geworden. Der gesamte Entwicklungsprozess wurde transparenter und planbar.

Die unscheinbaren Interaktionen haben ihre sichtbare Wirkung entfaltet.

Unser „Circle of Influence“

Als QA-Verantwortliche sitzen wir in den Projekten an einer zentralen Stelle. Wir haben Schnittstellen zu Stakeholdern, Entwicklern, Product Ownern, Operations-Managern und anderen Qualitätsabteilungen.

Diese Position ermöglicht es uns, gestalterisch auf die Projekte zu wirken. Wir können diesen Einfluss nutzen, die Themen „Vertrauen“ und „Psychologische Sicherheit“ anzusprechen und voranzutreiben.

Es ist nicht schwer, psychologische Sicherheit zu erreichen. Jeder Baustein auf dem Weg bedarf weder einer intensiven Schulung, Fachwissen noch einer anderen Expertise. Und gleichzeitig ist es kontinuierliche Arbeit, sich dieses Themas bewusst zu bleiben und zu verbessern. Vertrauensaufbau wirkt langfristig und ist selten kurzfristig sichtbar.

Den ersten Schritt wagen

Oft ist in den Projekten vorgegeben, WAS wir tun müssen. Es ist unsere Entscheidung, das WIE mitzugestalten. Können wir als QA einen Beitrag leisten, Vertrauen in unseren Projekten entstehen zu lassen? Wollen wir uns zurücklehnen und die Verantwortung dafür den Projektleitern, Scrum Mastern und Teamleitern überlassen? Können wir mutig sein und vertrauensvoll agieren?

Lasst es uns austesten. Trust the process. Trust the people.

Referenzen

1. Studie über 180 Teams (2012–2014), verfügbar über https://rework.withgoogle.com/
2. David H. Maister, Charles H. Green, Robert M. Galford: „The Trusted Advisor“[Free Press, 2001], ISBN: 978-0743212342
3. Timothy R. Clark: „Die vier Stufen der psychologischen Sicherheit“ [Vahlen, 2023] ISBN: 978-3800671908
4. Javier Lopez, „QA antipatterns“, https://levelup.gitconnected.com/qa-antipatterns-a9167e1fac5e (24.08.2024)

Über Andreas Döring:

Andreas Döring, ist Senior IT Con-sultant und Teamcoach bei accompio. „Qualität als Ergebnis von Teamwork“ fasst das Wirken von ihm gut zusammen. Mit über 12 Jahre Erfahrung in der QA verbindet er Testautomatisierung und Test-Management mit dem Motto: „Other people matter“.