Kommt Dir die folgende Situation bekannt vor?
Du sitzt in einem Termin, es werden Lösungsvorschläge zu einem Problem besprochen und nach kurzer Zeit meldet sich Peter zu Wort:
„Das ist doch alles nicht so schwer, lasst uns das Problem einfach mit Lösung XY beheben“.
Du hast ein Bauchgrummeln, denn so wirklich überzeugt bist du von dem Vorschlag nicht. Auch die Gesichter deiner Kollegen sprechen eine ähnliche Sprache – niemand scheint so wirklich überzeugt zu sein, aber es meldet sich auch niemand zu Wort.
Schlussendlich wird Peters Lösung XY wird verfolgt. So ist es immer, wenn Peter etwas sagt, er ist schließlich der Vorgesetzte, der das Vertrauen der Führungsetage genießt, seine Meinung wird also sicher die richtige sein…
Ein Problem des modernen Arbeitsmarkts? Nein!
1961 findet eines der berühmtesten Experimente in der Geschichte der Psychologie statt: Stanley Milgram bringt ahnungslose Probanden dazu, eingeweihten Schauspielern so lange Stromschläge zu versetzen, bis sie (wenn tatsächlich Strom geflossen wäre) dadurch gestorben wären – und dass, obwohl die Schauspieler vorgaben, vor Schmerzen zu schreien und um Gnade zu flehen. Passieren konnte das, weil Autoritäten (= die Versuchsleiter im weißen Kittel) anwesend waren und die Probanden dazu ermutigten, weiterzumachen [1]. Ein perfektes Beispiel für das Vorliegen des Authority Bias – der Tendenz von uns Menschen, der Meinung von Autoritäten eine hohe Bedeutung zuzuschreiben und ihr auch zu folgen, selbst wenn diese mitunter gegen die eigenen moralischen und ethischen Werte verstößt.
Das Experiment als Sonderfall?
Nein! Eine NASA-Studie kam zu dem Ergebnis, dass viele Unfälle in der Luftfahrt nur dadurch entstehen konnten, weil Crew-Mitglieder Fehler im Betriebsablauf zwar wahrgenommen hatten, sich aber entweder nicht trauten, diese Fehler an die ranghöhere Autorität zu melden oder die Bedenken mit dem Verweis auf mehr Erfahrung der Autorität abgewimmelt wurden [2]. Seit der Veröffentlichung der Studie werden daher standardmäßig „Widerspruch-Trainings“ innerhalb der Airlines durchgeführt, die die Angestellten dazu ermutigen sollen, Autoritäten auch mal zu widersprechen.
Der Expertenmeinung immer zu vertrauen, kann also fatale Folgen haben. Sollten wir deshalb jede Meinung kritisch hinterfragen und anzweifeln?
Auch nein! Zunächst einmal ist es nicht per se schlecht, auf die Einschätzung von Experten zu vertrauen. Wir gehen zum Arzt oder zum Psychologen, um uns Ratschläge und Hilfe zu holen. Wir beauftragen Unternehmensberater, die uns dabei helfen sollen, unser Business zu verbessern oder konsultieren Ernährungsexperten, die uns die „richtige“ Art und Weise aufzeigen, wie wir uns ernähren sollten. Es geht also nicht darum, das Wissen und die Meinungen von Experten permanent anzuzweifeln und zu hinterfragen (Experten haben auf ihrem Fachgebiet meist mehr Wissen als wir selbst), denn manchmal braucht es einfach eine gewisse Expertise, um Entscheidungen zu fällen. Es geht vielmehr darum, darauf zu achten, dass Meinungen von Einzelnen ebenso gehört und wertgeschätzt werden, wie die Meinung von Autoritäten, wenn es darum geht Fehler zu vermeiden oder im Komplexen Raum zu agieren. Also überall da wo es darum geht die kollektive Intelligenz anzuzapfen und wir im Kollektiv bessere Lösungen finden als alleine.
Ein Beispiel:
Ein Anästhesist weiß, wie er die Menge an Medikamenten berechnen muss, die einen Patienten, der 98 Kilo wiegt, für mindestens 180 Minuten schlafen lässt – er muss sich hierzu nicht erst die Meinungen vom operierenden Arzt, des Pflegers oder der Angehörigen anhören, denn er ist Experte auf diesem Gebiet und trägt am Ende auch die alleinige Verantwortung. Sollte er sich jedoch verrechnen und dies jemandem auffallen, brauchen wir zwingend ein Umfeld, dass es zulässt, diesen Fehler anzusprechen!
Sobald wir aber in einen komplexen Raum kommen, in dem wir nicht wissen, was wir nicht wissen und in dem es keine best practices mehr gibt (z.B. Stromausfall im OP), so zählt die Meinung des Anästhesisten, nur weil er Medizin studiert hat, nicht mehr als die der anderen anwesenden Personen, wenn es darum geht, GEMEINSAM mit der neuen Situation umzugehen und das Leben des Patienten zu retten.
Umfelder, die Fehler sowohl gezielt adressieren wie auch auf unbekannte, komplexe Situationen gut reagieren können, sind oft gekennzeichnet von einem hohen Maß an Psychologischer Sicherheit und einem Bewusstsein für den Authority Bias [3].
Was bedeutet das Wissen über den Authority Bias nun also für uns als Scrum Master oder agile Leader?
Das Wissen darüber, dass der Authority Bias existiert, ist für Scrum Master und agile Leader von großer Bedeutung. Unsere Aufgabe ist es, im Kontakt mit Teams und Organisationen darauf zu achten, dass Meinungen einzelner Teammitglieder nicht zu kurz kommen. Wir dürfen eine Achtsamkeit dafür entwickeln, wie das Autoritätsgefälle in einem Team gerade ist, denn Hierarchien bilden sich immer und wandeln sich – je nachdem wer im Raum ist – permanent. Unter anderem können wir den Authority Bias abschwächen in dem wir:
1. Führungskräfte, Meinungsbilder und autoritätsstarke Mitglieder unterstützen, auf Ihre Sprache zu achten, statt fertiger Lösungen lieber Vorschläge und Optionen zu suggerieren, Fehler und Unwissen einzugestehen und aktiv nach der Meinung von Anderen zu fragen.
2. Starke Team Agreements erstellen und konstant daran arbeiten, einen psychologisch sicheren Raum zu erschaffen und zu halten.
3. Aktiv Termine moderieren und sicherstellen, dass alle Teammitglieder angesprochen und gehört werden, sodass wirklich alle Meinungen auf den Tisch kommen.
4. Mit dem Team lernen, in welchen Situationen welche Art von Entscheidung/ Meinung wichtig und richtig ist. Wichtig ist immer die Frage, wo eine einzelne Expertenmeinung eventuell schon ausreicht und wo wir als Gruppe konkret die kollektive Intelligenz von allen brauchen.
Sobald man Software entwickelt, stellt sich die Frage, wie man eigentlich mit Wünschen und Ideen von Entwicklern, Kunden, Führungskräften, Produktmanagern, also den Stakeholdern umgeht.
Spätestens wenn ich eine User Story in eine Iteration reinnehmen möchte, sollte sie also gut verstanden sein, vielleicht auch schon kurz davor. Das bedeutet, dass das Entwicklungsteam weiß, was das Ziel der Umsetzung ist und woran es erkennen kann, dass es dieses Ziel erreicht hat. Häufig sind dann auch weitere Wissensquellen als Anlagen zu einer User Story vorhanden: Vielleicht ein UI-Entwurf, vielleicht eine Spezifikation eines Gesetzgebers, vielleicht Formeln in einer Excel-Tabelle. Hier ist erlaubt, was dem Team hilft – ohne es von Beginn an in seiner Kreativität und Lösungsfindung einzuschränken.
Die User Story bleibt dabei auf der Ebene der Benutzerperspektive: Sie sollte also von allen Menschen mit Domänenhintergrund verstanden werden können – und deswegen auch nicht technisch sein. Gedanklicher Kniff: Stellen Sie sich vor, ein Kunde ohne technischen Hintergrund sollte sie verstehen können. Eine Kommunikationsbrücke zwischen Entwickler und Fachperson also.
Der Weg hin zu einer agilen Organisation ist mit vielen Hürden und Problemen gespickt. Anforderungen, Ziele und Rahmenbedingungen ändern sich innerhalb von wenigen Tagen und Wochen.
Der Product Owner trifft nahezu täglich Produktentscheidungen: In welcher Reihenfolge werden die Anforderungen umgesetzt, welche kommen hinzu, welche werden gestrichen? Und in welcher Ausprägung wird eine Anforderung realisiert? Diese Entscheidungen benötigen ein Fachwissen in der Domäne des Produkts und die Fähigkeit, die Entscheidungen dann auch durchsetzen zu wollen.
Um die richtigen Entscheidungen zu treffen, braucht es aber nicht nur Fachwissen sondern auch ein gutes Gespür für den Kunden, die Anwender und den Markt.
Der Product Owner ist Teil des Scrum Teams. Und der Erfolg dieses Teams steht und fällt mit dem Zusammenspiel aller Teammitglieder. Wie gut findet man gemeinsame Lösungen für Konflikte und Probleme statt sich hinter seiner Rollenbeschreibung und Verantwortlichkeiten zu verschanzen?
Manche Teams fragen mich, warum es in Scrum eigentlich Sprints gibt und ob solch eine künstliche Einteilung in Wochenrhythmen überhaupt mit der Arbeit eines Teams vereinbar ist?
Stellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?
Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.
In einem Workshoptermin, den der 
