Der Authority Bias – Sollten wir Autoritäten immer blind vertrauen? 

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. 

Neues aus dem magischen Labyrinth

9 neue Erkenntnisse für agile Teams mit Magic Maze

Dieser Artikel ist Ursprünglich im Januar 2020 erschienen.

Magic Maze für agile Teams -Was bisher geschah…

In meinem letzten Artikel zu Magic Maze hatte ich die uns bis dato 9 bekannten Erkenntnisse zusammengefasst und mit euch geteilt. Seitdem ist natürlich nicht Schluss gewesen. Ich selbst hatte bei Kunden mehrfach die Gelegenheit Magic Maze einzusetzen und zusammen mit meinem

Kollegen Veit sowie Stefan Zumbrägel beim Global Scrum Gathering in Wien eine Open Space Session zu Magic Maze zu hosten.
Mein Highlight bezüglich Magic Maze dieses Jahr war allerdings ein Certified Scrum Master Training mit Björn Jensen . Ich war als Co- Trainer mit dabei und konnte mit den Teilnehmern recht früh am ersten Tag eine Runde Magic Maze

Neun neue Erkenntnisse für agile Teams mit Magic Maze spielen, um sie für agiles Arbeiten zu sensibilisieren. Das hat nicht nur sehr viel Spaß gemacht, sondern auch noch richtig gut funktioniert. An dieser Stelle nochmal „Danke an Björn“ für diese tolle Gelegenheit und das Vertrauen!

Aber warum erzähle ich euch das alles? Es gab natürlich neue Erkenntnisse, insgesamt 9 neue Erkenntnisse für agile Teams mit Magic Maze. Und genau das treibt mich an, Magic Maze weiter mit Teams und in Trainings einzusetzen. Ich werde die bisher bekannten Erkenntnisse nicht nochmal hier zusammenfassen, dafür bitte den oben verlinkten Artikel lesen.

Feedback aus der Community

Kurz nach dem letzten Beitrag kam schon der erste Kommentar von Abigail Leijten , in dem sie zwei Erkenntnisse geteilt hat.

„Mut: es gehört Mut dazu, am Anfang dich als erste am Tisch zu setzen, wo du gar nicht genau weißt, was passieren wird.“
Das kann ich bestätigen, ich habe mehrfach größere Gruppen gehabt, bei denen wir auch die Rolle des Beobachters hatten und sich der Tisch somit erst zögerlich gefüllt hat. Das kann man in Retrospektiven auch oft beobachten. Man bittet das Team Beobachtungen zu teilen und es dauert eine Weile, bis sich der Erste traut oder freiwillig spricht. Sowohl im Spiel, als auch in der Retro, passiert aber nichts Schlimmes, wenn man die Initiative ergreift. Schönes Thema über das man im Debrief sprechen kann.

„Als Teil des „Agiles Mindset“ ist auch ein Satz „Jeder hat seine eigene Geschwindigkeit“. Wir hatten den Fall, wo manche Leute 3 Runden gebraucht haben, bevor sie den Teleporter komplett verstanden haben. Auch das war für die Gruppe ein schönes Learning.“ Das ist eine weitere tolle Erkenntnis, wie ich finde. Mir fällt das auch oft auf. Ich interpretiere da auch rein, dass man Leute nicht mit Informationen überladen und erwarten kann, dass es alle sofort verstanden haben. Man kann das Spiel noch so oft und ausführlich erklären – erst wenn es los geht, merkt man, ob es wirklich verstanden wurde.

Vielen Dank Abigail, dass du diese tollen Impuls mit uns geteilt hast!

Was wir neues gelernt haben

Ich knüpfe gleich an. Ich würde noch einen Schritt weitergehen und die Erkenntnis ziehen „einfach mal Machen“. Bei der Produktentwicklung wissen wir nicht, ob wir das Richtige bauen, bis wir den Kunden um Feedback bitten. So geht es mir als Facilitator des Spiels auch oft. Ob die Spieler meine Anweisungen verstanden haben, sehe ich erst, wenn sie es spielen. Und bisher hatte es keine Gruppe zu 100% verstanden. Das konnte dann aber schnell angepasst werden im Spiel. Ich weiß nicht, wie viel Zeit es gekostet hätte, um die Missverständnisse beim Erklären auszuschließen bzw. ich glaube es ist nicht möglich. Also Erkenntnis bzw. Parallele zu agilem Arbeiten, einfach mal machen und Feedback einholen!

Es gilt die Prime directive (von Norman L. Kerth). „Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“ Übersetzt: „Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen, den Ressourcen und unseren individuellen Fähigkeiten getan hat.“ Wie sehr diese Haltung hilft, erkennt man bei Magic Maze in den Phasen, in denen gesprochen werden kann. Ist das erste Fingerpointing vorbei, haben die Teams in der Regel verstanden, was ihnen weiterhilft ihr Ziel zu erreichen und was nicht. Fingerpointing hilft nie! So ist es auch in Retrospektiven. Nicht umsonst ist die Prime directive dort so wichtig. Dieser Punkt baut ebenfalls sehr schön auf den Punkten 11 und 12 auf, wie ich finde.

Läuft man bei Magic Maze ein Feld zu weit, kann man diesen Fehler selbst nicht korrigieren. Man braucht Hilfe aus dem Team. Diese Erkentiss hat dazu geführt, dass die Runde gemerkt hat, dass es auch im Alltag OK ist, um Hilfe zu bitten, wenn man sich in eine Sackgasse manövriert hat. Denn man bedenke Punkt 13, es gilt die Prime directive; man hat es ja nicht absichtlich gemacht.

Der letzte Punkt aus meinem vorherigen Artikel bezog sich darauf, dass man durch lange Planung am Anfang nicht besser vorhersagen kann, wie sich das Labyrinth aufbauen wird. Ein Team hat dies noch um die Aussage „eine Schätzung am Anfang wäre sehr sehr ungenau“ ergänzt. Das Team weiß, dass es alle Mittel hat, um die Aufgabe zu lösen, aber es hätte sich nicht gut gefühlt eine feingranulare Schätzung abzugeben. Sicher ein tolles Learning für Personen außerhalb eines Entwicklungsteams. Nehmt den Punkt gerne gezielt mit ins Debrief, wenn ihr im Alltag Probleme mit den Ansprüchen an Schätzungen habt.

In den Phasen auf der Sanduhr wird immer fleißig gesprochen und geplant. Doch dann kommt oft alles anders. Das führte zu der Erkenntnis, dass eine gemeinsame Sprache und gemeinsames Wording nicht selbstverständlich sind. Auch das ist bei Scrum oft zu beobachten. Daher führe ich sehr gerne Grundlagentrainings mit neuen Teams durch, um die verschiedenen Taxonomien ans Licht zu bringen und eine gemeinsame zu verankern.

Der „Tu was Stein“ kann von jedem Spieler genutzt werden, um einem andren Spieler zu signalisieren, dass er etwas tun kann, das dem Team weiterhilft. Im Spiel passiert das sehr natürlich und unverzüglich, sobald eine solche Situation erkannt wird. Die Analogie zu Scrum ist das Impediment. Ein Spieler hält unwissentlich den Betrieb auf. Es ist total OK und auch wichtig, dies sofort anzusprechen. Im Spiel passiert das von alleine. Warum sollte das also im Alltag nicht ebenso selbstverständlich werden?

Ich schließe mit einem für mich schönsten Sätze in einem Debrief, der auch keiner weiteren Erklärung bedarf „Das Spiel hat aus Fremden innerhalb kürzester Zeit ein Team gemacht“

Viel Spaß beim Ausprobieren und Danke fürs Lesen!

User Stories verständlich erklärt

 User stories in Oxford - (c) Jacopo Romei CC-BYSobald 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.

Schreibt man alles in ein Word-Dokument mit sauberer Gliederung? Nutzt man Skizzen oder Prozessmodellierungswerkzeuge? Machen wir ein Grobkonzept, dann ein Feinkonzept, stimmen es mit dem Kunden ab und fangen dann an zu arbeiten? Oder doch eine Excel-Tabelle oder einen Projektplan mit Tätigkeiten?

Eine beliebte Variante zur Arbeit mit Anforderungen in agilen Projekten nennt sich „User Story“: Eine User Story sind wenige Sätze natürlicher Sprache, um als Gedankenstütze für eine Anforderung zu dienen.

Ein Beispiel für eine User Story:

Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.

Könnte das Team diese Anforderung umsetzen? Vermutlich nicht. Die beschriebene Anforderung ist  recht vage, nur grob umrissen. Eine Idee, die es zu durchleuchten gilt. Das Grundprinzip dahinter: Ein guter und kontinuierlicher Dialog der Beteiligten ist wichtiger als eine detaillierte, niedergeschriebene, im Voraus für das Projekt völlig durchdrungene Spezifikation.

Man kann sich so eine User Story wie ein „Aufhänger für eine Funktionalität“ vorstellen. Die Funktionalität wird sichtbar, anfassbar, begreifbarer. Aber eben nicht vollständig definiert.  Das verhindert allein schon die Unschärfe von Sprache und auch die Komplexität von Softwareentwicklung. Besser wir investieren hier nicht allzuviel Zeit.

Doch mit so großer Unschärfe kann auch das beste Team der Welt nicht wirklich effizient arbeiten. Die User Story enthält zwar wer was warum möchte – aber nicht was genau und schon gar nicht wie genau.

Vom Groben ins Feine.

Wann wird solch eine Idee namens User Story nun also konkreter? Kurz bevor wir die umschriebene Anforderung der User Story umsetzen möchten, sollte sie klein und konkret sein. Um dahin zu gelangen, machen agile Teams häufig so genannte Backlog Refinement Besprechungen. In diesen Besprechungen geht es darum, das Verständnis zu vertiefen und gemeinsam mit dem Product Owner, große User Stories in kleinere zu zerlegen.

 Prioritizing user stories - (c) Jacopo Romei CC-BY - https://www.flickr.com/photos/jakuza/3578548023Spä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.

Ich bin fertig und mache dann mal Feierabend für heute.

Woher weiß ein Team nun, ob es das Ziel einer User Story erreicht hat? Wann ist die Funktionalität fertig? Das klärt das agile Team im Dialog mit seinem Product Owner. User Stories werden während dieses Dialogs häufig durch schriftliche Akzeptanzkriterien ergänzt. Das sind stichpunktartige Kriterien, die erfüllt sein sollten, damit der Product Owner eine User Story als fertig akzeptiert. Eine Art Checkliste oder für diese eine User Story geltende Ergänzung der Definition of Done.

Ein Beispiel:

Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.

Akzeptanzkriterien:
– Die Liste zeigt alle noch nicht verkauften Fahrzeuge an
– Die Liste ist nach Kaufpreis sortiert
– Wenn keine Fahrzeuge vorhanden sind, erscheint ein Hinweistext

(c) CC-BY https://www.flickr.com/photos/psd/8591351239Die 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.

Ein bisschen mehr Technik bitte.

Wann wird es nun endlich technisch? Wo entsteht die Lösungsidee? Welche Architektur braucht es und welche Anpassungen im Code? Alle konkreten, technischen Tätigkeiten wird ein agiles Team in der Sprintplanung oder in einer Iteration selber identifizieren und als so genannte „Tasks“, also kleine Schritte zur Implementierung solch einer Anforderung, an eine User Story hängen. Das ist elegant, denn so sind fachliches Problem und technische Lösung bis zur Sprintplanung getrennt. Wir verwenden so nämlich keine Zeit auf technische Überlegungen, die vielleicht doch nie umgesetzt werden, weil sich die Marktanforderungen ändern und damit die Prioritäten unseres Backlogs.

Nun: Wie sähe wohl Ihr aktuelles oder nächstes Projekt mit dem Konzept von User Stories aus? Was wäre anders? Was schwieriger, was leichter? Viel Erfolg beim Ausprobieren.

Enterprise Transition Community (ETC) verständlich erklärt

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.

Um so mehr Teams mit agilen Vorgehensweisen arbeiten, umso mehr Hindernisse auf Organisationsebene werden deutlich. Themen, die die Teams davon abhalten, effizient Software zu entwickeln und voranzukommen. Ungelöste Zuständigkeiten, unklare Rollenbilder und Karrierepfade, zu lange dauernde Entscheidungsprozesse, inkonsequentes oder nicht vorhandenes Portfolio- oder Programmmanagement.

Doch wie begegnet man dieser Komplexität, den Risiken und der Vielfalt der Stakeholder einer Agilen Transition?

Auch Software-Entwicklungsteams sind ständig mit veränderlichen Anforderungen und technisch sowie fachlicher Komplexität konfrontiert. Was für diese Teams funktioniert, ist auch bei einer Unternehmenstransition das Mittel der Wahl: Scrum. Durch seine mehrfachen eingebauten Feedback-Schleifen versteht es das Scrum-Rahmenwerk, die Komplexität zu adressieren. Eine Enterprise Transition Community kann so auf die häufig erst bei der Umsetzung auftretenden Hindernisse und Ideen eingehen und in kurzen Zyklen lernen, was funktioniert und was nicht.

Eine Gemeinschaft als Taktgeber für die Veränderung

Die Veränderung hin zu Agilem Vorgehen benötigt Menschen aus den unterschiedlichsten Bereichen eines Unternehmens.

Eine Enterprise Transition Community (kurz: ETC) ist ein Scrum-Team, dass die Transition hin zu agilem Vorgehen in einem Unternehmen durchführt.

Dieses Team arbeitet nach Scrum, produziert aber keine Software. Es liefert Organisationsveränderung in kleinen Schritten je Sprint. Es wurde von einem der beiden Begründer von Scrum, Ken Schwaber, im Jahr 2007 bekannt gemacht (siehe The Enterprise and Scrum) und seitdem in verschiedenen Variationen neu veröffentlicht und in etlichen Unternehmen praktisch eingesetzt (siehe z.B. BMC, EWE oder Amazon).

Enterprise Transition Community

In dem hier dargestellten Prozess kommen auch die bekannten Artefakte und Rollen von Scrum zum Einsatz:

Product Owner – der Fokusgeber

Der Product Owner einer ETC trägt die Verantwortung dafür, dass das Team fokussiert an den Veränderungen mit dem höchsten Wert für das Unternehmen arbeitet. Er verwendet dazu ein Transition Backlog, welches die zu lösenden Organisationsthemen beinhaltet. In regelmäßigen Backlog Refinements werden die teils großen Organisationsveränderungsthemen (Epics) in Sprint-gerechte User Stories zerlegt.

Teammitglieder – Umsetzer und Gestalter

Die Teammitglieder sind Personen des Unternehmens, die ein Interesse an der Veränderung hin zu Agilität haben und sich einbringen möchten mit ihrer Zeit. Die Teammitglieder haben die Umsetzungsverantwortungen der organisatorischen Veränderungen. Sie sollten aus den Bereichen stammen, die maßgeblich von den Veränderungen betroffen sind und diese auch maßgeblich beeinflussen können. Am besten sie gehen die Themen selbst in der Umsetzung an. Falls es aber notwendig sein sollte, sollten sie dazu die Arbeit maximal eine Ebene delegieren, behalten aber die Verantwortung

ScrumMaster – Servant Leader und Facilitator

Der ScrumMaster einer ETC moderiert die Besprechungen, sorgt für das Prozessverständnis von Scrum und arbeitet an Lösungen von Hindernissen, die die ETC davon abhalten, hochproduktiv zu sein. Manchmal unterstützt er in Agilität unerfahrenere Teammitglieder bei der Vertiefung des Verständnisses und der Findung „agiler Lösungen“ für Organisationsthemen. Er dient dem Team und führt Kraft Anerkennung.

Die Organisation teilhaben lassen

Die Stakeholder einer Enterprise Transition Community sind oft breit gestreut im Unternehmen. Jeder betroffene Mitarbeiter und jede betroffene Führungskraft hat ein Interesse an den Ergebnissen dieses Teams. Nach einer anfänglichen Findungsphase der ETC sind sie gerne gesehene Feedbackgeber für „ETC Entwicklungsteam“ und ETC Product Owner im Review-Meeting.

Wer mehr zu dem Thema lesen möchte, empfehle ich die Szenen einer Scrum Transition (englisch), welche auch meine Abbildung inspiriert haben.

Welche Fähigkeiten braucht ein Product Owner in Scrum?

Der Product Owner ist eine der drei Rollen in Scrum. Er verantwortet den Produkterfolg. Doch welche Fähigkeiten helfen dabei, diesen zu erreichen?

Überzeugungskraft

POSpeaking

Immer weniger Menschen möchten heutzutage an fraglichen, vielleicht gar sinnlosen Projekten arbeiten. Software entwickeln als Lohn-und-Brot Job? Egal, ob das Produkt jemand später einsetzt? Das Entwicklungsteam muss an die Vision des Product Owners glauben, um motiviert zu sein.

Dazu braucht es einen überzeugenden Product Owner. Und nicht nur das Team will glauben können, auch die Kunden und Anwender des Scrum-Teams. Beide muss der Product Owner davon überzeugen, dass er die richtigen Entscheidungen trifft zum Wohl des Produkterfolgs.

Was Sie als Product Owner zur Stärkung tun können:

  • ein Produkt suchen, hinter dem Sie wirklich stehen
  • ein Rhetoriktraining besuchen, um Ihre Botschaft zu verstärken
  • Visual Facilitation erlerne, also mit Bildern und Metaphern kommunizieren
  • die Zukunft des Produkts mit guten Geschichten lebhaft ausmalen

Fachwissen über die Domäne und Durchsetzungsfähigkeit

PuzzleDer 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.

Was Sie als Product Owner zur Stärkung tun können:

  • Fachzeitschriften und Bücher zur Domäne lesen
  • Fachkonferenzen besuchen und Kollegen interviewen
  • Sich öfter in einem klarem „Ja“ und „Nein“ üben, auch wenn es unbequem sein sollte

Empathie für den Kunden und Anwender

FeedbackUm 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.

Gerade technischen Product Ownern fällt es oft schwer, die Nutzerbrille aufzusetzen. Was will der Anwender wirklich? Was sind seine Bedürfnisse? Warum möchte er etwas?

Was Sie als Product Owner zur Stärkung tun können:

  • In User Stories den WARUM-Teil des Satzes vom Anwender erläutern lassen
  • Ein Werkzeug wie das Vision Board verwenden, um den Anwender besser zu verstehen
  • Den (potenziellen) Anwender bei seiner täglichen Arbeit beobachten
  • Beim Formulieren von Anforderungen auf technisches Jargon verzichten

Teamfähigkeit

TeamDer 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?

Was Sie als Product Owner zur Stärkung tun können:

  • Lassen Sie sich von Ihrem Entwicklungsteam bei der Erfüllung Ihrer Rolle helfen. Auch Teammitglieder können User Stories schreiben
  • Fragen Sie Ihr Entwicklungsteam, ob Sie an der Retrospektive teilnehmen dürfen
  • Betrachten Sie sich und das Team als „alle im selben Boot“ und suchen Sie aus dieser Haltung Lösungen

Diese Beitrag wurde inspiriert durch Fragen der Teilnehmer meines gemeinsamen CSPO-Trainings mit Peter Beck.

Scrum Sprints verständlich erklärt – Warum Iterationen Sinn ergeben

WarumSprintsBadgeManche 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?

Prinzipiell ist ein Sprint ein gleich langer sich regelmäßig wiederholender Zeitabschnitt eines Scrum Teams, um Feedback zu ritualisieren.

Schauen wir uns an, was dieses ritualisierte Feedback in einem Softwareprojekt bringt:

Von der „Black Box Entwicklungsabteilung“ zum Vertrauensverhältnis durch Kundennähe

Die Sprintplanung gibt dem Product Owner und damit auch dem Kunden eine Vorschau, was das Team in der kommenden Iteration schaffen möchte. Zum Sprintende folgt dann das Review-Meeting, in dem Stakeholder wie Kunde, Anwender, Management und Team zusammenkommen.

Durch die dort entstehende regelmäßige Transparenz über Liefergegenstände und Gespräche von Angesicht zu Angesicht wird Fortschritt erlebbar und Hintergründe von Entscheidungen oder Verzögerungen verständlich. Es entsteht eine Diskussions- und Vertrauensbasis zwischen Kunde und Team.

Weniger unfertige Arbeit

Ein Team, dass früher Feedback vom Kunden erhält, weiß schneller, ob eine Funktion so gelungen ist, dass Sie das Bedürfnis des Kunden tatsächlich deckt. Damit werden Features schneller „als fertig“ abgehakt und weniger unfertige Arbeit ist gebunden, die im Kopf der Teammitglieder den Fokus und das Gefühl von Fortschritt verhindert. Wer mag schon haufenweise unerledigte Dinge in seinem Hinterkopf?

Kostengünstigere Fehlerbehebung

Wer Software entwickelt, produziert auch Fehler. Das ist normal und Teil des Handwerks. Gerade deshalb sollten wir mit diesem Wissen unser Möglichstes tun, um sie dann so günstig wie möglich zu finden und zu korrigieren. Günstig bedeutet in diesem Fall, das ein Fehler um so weniger Geld kostet, um so schneller wir ihn finden. Am besten noch vor der Produktivsetzung. Hierfür haben wir viele Mittel in der Softwareentwicklung wie z.B. Automatische Tests, Code Reviews oder auch Pair Programming. Ein Sprint ist eine Qualitätsschranke, die uns ritualisierte Qualitätskontrollen ermöglicht, in einem Rahmen der so zeitnah ist, dass ich als Entwickler tatsächlich noch wissen kann, in welchem Kontext der Fehler steckt. Besser jetzt gleich nochmal an den Quelltext als in zwei Monaten, oder?

Wissen, wann welches Feature kommt

Softwareentwicklung findet immer für Menschen statt, die Erwartungen an unsere Produkte und Lösungen haben. Ein Teil dieser Erwartungen ist zeitlicher Natur: Wann kann eine Software dies oder jenes? Wann wird mein Kundenfeedback umgesetzt? Wie lange muss ich mit einem Fehler noch leben?

Auf diese Fragen braucht ein Product Owner zuverlässige Antworten, um glaubwürdig zu sein. Sprints ermöglichen es einem Scrum-Team, Daten über die bisherige Produktionsleistung zu ermitteln und diese in die Zukunft fortzuschreiben. So wird eine Roadmap zur Basis des Erwartungsmanagements. Versetzen wir uns mal in die Sicht des Kunden: Wieviel Transparenz würden Sie als Kunde über den Fertigstellungszeitpunk Ihres Features gerne haben?

Niedrigerer Koordinationsaufwand

Und zu guter Letzt spart ein Sprint auch noch Koordinationsaufwand durch regelmäßig festgelegte Termine für alle Beteiligten und somit planbare Räumlichkeiten, Teilnehmer und Ergebniserwartungen.

Vereinbarkeit von Sprints und Arbeitsinhalten

Doch wie teile ich nun meine Arbeit so auf, dass ich sie in Sprints umsetzen kann? In der Essenz geht es darum, Features richtig zu zerteilen und somit kleinere, abgeschloßene Einheiten zu produzieren.

Poster: Warum gibt es in Scrum Sprints?

Ein Bild sagt mehr als tausend Worte

Eine graphische Übersicht dieser Aspekte finden Sie auch auf meinem Teamraum – Poster (PDF; 8 MB).

Sie können es zum Beispiel auf Postergröße ausgedruckt im Teamraum aufhängen, um mit Ihren Kollegen darüber zu sprechen, warum wir in Scrum iterativ arbeiten und was Team und Unternehmen davon haben.

Oder ergänzen Sie es doch noch in einer Retrospektive mit dem Team um neue Aspekte mit Haftnotizzetteln, weshalb Sprints einfach Sinn ergeben?

Scrum skalieren – Communities of Practice (CoP) verständlich erklärt

Communities of Practice in ScrumStellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?

Softwareentwickler arbeiten nun in kleinen Teams von 5 – 9 Personen. ScrumMaster und Agile Coaches investieren viel Energie, diese Teams zu stärken und zu schützen. Im Laufe der Zeit entwickelt dabei jedes Team seinen eigene Definition davon, wie gute Softwareentwicklung aussieht und funktioniert.

Doch was ist mit Querschnittsthemen?

Wie koordiniert man gemeinsame Auslierferungen, an denen mehrere Teams arbeiten? Wie lernen wir teamübergreifend neue Softwareentwicklungspraktiken? Wie entwickeln wir Entwicklungsrichtlinien, die für alle Teams passen? Wo kommen Tester zusammen, um herauszufinden, was gute Qualität für sie bedeutet?

Wenn wir agil mit mehreren Teams arbeiten möchten, brauchen wir teamübergreifend einen Weg, solch einen Austausch zu gestalten. Eine Art von loser Interessensgemeinschaft aus Praktikern. Menschen, die freiwillig und aus Leidenschaft zusammenkommen – vielleicht wie wir Deutschen das so gerne in Vereinen tun (nur weniger bürokratisch)?

Vor über 20 Jahren beschäftigten sich die Sozialforscher Jean Lave und Étienne Wenger mit der Bedeutung von sozialen Konstrukten in Lernprozessen. Und sie formten den Begriff der „Communities of Practice“ – kurz: CoP.

Definition einer CoPEine 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.

Eine Teilnahme an solch einer Community ist immer freiwillig – und unabhängig vom bisherigen Wissensstand. Anfänger, Fortgeschrittene und Experten treffen sich regelmäßig, um gemeinsam zu lernen.

Wie beginnt man nun so eine Community of Practice?

Das ist leicht! Derjenige, der für ein Thema eine große Leidenschaft besitzt, sucht nach Gleichgesinnten im Unternehmen. Man legt gemeinsam erste Ziele fest und lädt alle interessierten Kollegen zu einem großen Willkommens-Termin ein. Dort informiert man dann über das Vorhaben und bittet die Teilnehmer, um Feedback, ob sie in Zukunft auch mit an Bord sind. Ein erfahrener ScrumMaster als Experte für Teamprozesse kann von Anfang an schon als Facilitator den Weg der CoP begleiten.

Wie sähe Ihre Firma mit solchen Lerngemeinschaften aus? Was wäre dann anders? Wer würde zu welchen Themen wohl im Austausch sein? Wenn Sie Lust bekommen haben, selbst eine Community of Practice zu Gründen oder Kollegen dabei zu helfen, mit ihrer Initiative erfolgreich zu sein, empfehle ich Ihnen dieses Buch. Und danach viel Spaß bei der Umsetzung! Denn gemeinsames Lernen macht uns doch oft am meisten Spaß, oder?

Manchmal ist Scrum wertlos.

(c) Jared Tarbell, CC-BY-2.0

Viele Unternehmen beschäftigen sich mittlerweile mit Scrum. Neben durchaus erfolgreichen Transformationen von Teams und Abteilungen gibt es auch die Veränderungsinitativen, die auf ihrem Weg zu agilem Arbeiten stecken bleiben:

Mißverstandene Praktiken, fehlende Management-Unterstützung und fragwürdige Rollenverständnisse zeigen sich.

Doch was fehlt diesen Versuchen, Scrum zu etablieren eigentlich? Warum passen die Praktiken nicht oder fühlen sich inkongruent im Unternehmen an?

Bei der Suche nach der Antwort finden wir im ersten Buch von Ken Schwaber und Mike Beedle fünf Kernwerte von Scrum:

Mut, Offenheit, Respekt, Fokus, Commitment

Schauen wir uns die Scrum-Werte einmal etwas genauer an:

Mut ist die Fähigkeit, Herausforderungen trotz Risiken aktiv anzugehen, um Sie erfolgreich zu überwinden. Veränderungen benötigen diesen Mut: Unbekanntes und Neues will gelernt und gemeistert werden. Rollen verändern sich und der Status quo wird in Frage gestellt.

Offenheit ist das bereitwillige Aufnehmen und Teilen von Informationen, um Situationen einschätzen und richtig entscheiden zu können. Nur durch Offenheit entsteht die Transparenz, gute Entscheidungen zu treffen und gegenseitiges Verständnis für die Situation zu entwickeln.

Respekt ist Wertschätzung für Beitrag und Person aller Beteiligten, um konstruktiv zusammenzuarbeiten. Unterschiedliche Lebenswege, Meinungen und Perspektiven verdienen Anerkennung und wollen für Kreativität und Synergien genutzt werden.

Fokus ist die bewußte Einschränkung von Optionen, um gemeinsam effektiv voran zu kommen. Weniger ist mehr. Die Essenz umzusetzen in bester Qualität macht Kunden zufrieden und lässt uns Risiken steuern.

Commitment ist die Selbstverpflichtung zur Erledigung einer Aufgabe oder Mission, um Verlässlichkeit und Motivation zu erhöhen. Im Scrum Team genießen Angestellte eine hohe Freiheit und Selbstbestimmung. Damit wächst ihre Verantwortung für den Erfolg.

Die Einführung von Scrum bringt die Abteilung dazu, diese fünf Werte in ihrer Arbeitskultur zu schätzen: Scrum ist sozusagen ein Kulturwandler, ein Veränderungsagent im System, ein Katalysator für eine neue Form der Zusammenarbeit.

Die wichtigste Frage ist also, wieweit diese Zielkultur erwünscht ist und wie sie zu den weiteren Kulturelementen passen kann.

Einige Beispiele:

  • Wenn Harmonie (und somit Konfliktvermeidung) ein hoher Wert in der bestehenden Kultur ist, wie wird dann Mut wahrgenommen? Als Aggressor?
  • Wenn Erfolg der wichtigste Wert ist, darf Offenheit in der Kommunikation über Fehlschläge existieren?
  • Wenn Arbeit zugeteilt wird und top-down Deadlines ausgerufen werden, wie stark ist die gefühlte Selbstverpflichtung (also das Commitment) des Einzelnen?

Cargo Cult Scrum - (c) tattooblogger, CC-BY-2.0Schafft man es nicht, auf Grund der bestehenden Kultur die Werte von Scrum zu erlernen, sind diese Scrum-Implementierungen wert-los. Dem Vorgehen fehlt die Seele, die Praktiken wirken blutleer. Manche nennen dies einen Cargo-Cult: Ohne in der Tiefe zu verstehen, worum es geht, werden Praktiken falsch eingesetzt – und die erhoffte Veränderung bleibt aus.  Scrum löst sein Versprechen der besseren Arbeitswelt dann nicht ein – was zu verständlicher Frustration und Ablehnung der Methode führt.

Vor einer Scrum-Einführung lohnt es sich also, zu prüfen, ob die Zielkultur lohnenswert und erwünscht ist. Im Zweifelsfall erleben Sie in einem Scrum-Training oder während eines Pilotprojekts, wie sich Agilität anfühlt und welche Reibungspunkte es gibt.

Was ist Ihre Wunscharbeitskultur?

Definition of Done verständlich erklärt

(c) Bernard Goldbach - Creative Commons

Vor Kurzem hielt ich in einem Workshop ein Smartphone in die Luft und fragte einige Menschen, ob das ein gutes Telefon sei. Viele fanden es gut, manche okay und einer mochte es absolut nicht. Bei der Nachfrage nach Gründen stellten wir schnell fest, dass verschiedene Menschen verschiedene Qualitätsmerkmale betrachten und wichtig finden.

Das ist auch in einem Softwareentwicklungsteam nicht anders – bei der Frage, ob ein Stück entwickelte Software fertig ist, gibt es oft Uneinigkeit und Diskussionen. Woher weiß ich, dass ich fertig bin mit der Entwicklung? Was kann ich von meinen Kollegen erwarten, wenn sie ein Feature umsetzen? Was erwartet mein Product Owner?

Um diese Fragen in einem agilen Team zu beantworten und Klarheit zu schaffen, gibt es in der agilen Welt ein Artefakt mit dem Namen „Definition of Done“. Im Prinzip ist es soetwas ähnliches wie eine sehr spezifische Arbeitsvereinbarung oder selbst auferlegte Regeln, wie man Entwicklungsqualität definiert.

Eine Definition of Done (kurz: DOD) ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird.

Man kann sich das als eine Art Kriterienkatalog oder Checkliste vorstellen, die man bei jedem Feature (sprich: User Story) durchgeht und auf Erfüllung überprüft:

  • Habe ich Unit Tests entwickelt?
  • Wurde die Dokumentation erweitert?
  • Sind die Codekonventionen eingehalten?
  • usw.

Definition of Done (DOD)In einem Workshoptermin, den der Agile Coach bzw. ScrumMaster moderiert, wird diese Selbstverpflichtung des Teams als Einigung gemeinsam erarbeitet. In Zukunft ist sie die Basis für Klarheit bei der Frage, ob ein Feature fertig ist und hängt deswegen im Idealfall im Teamraum. Die Verantwortung für die Inhalte und auch die Einhaltung der Vereinbarung liegt ausschließlich beim Team. Ein wachsamer Agile Coach erinnert aber an die festgelegten Elemente zur passenden Gelegenheit.

Übrigens darf man im Laufe des Wachstums eines agilen Teams durchaus erwarten, dass die Definition of Done reift, somit mehr und umfangreichere Qualitätskriterien enthalten sind. Vielleicht ist es damit die erste Checkliste, die organisch wächst.

Qualitätssicherung in agilen Methoden

Scrum sagt, produziere potenziell auslieferbare Software in jedem Sprint, Kanban hat als Prinzip „Fokussiere Dich auf hohe Qualität„.

Leicht erkennbar ist, dass agile Methoden Anforderungen an die zu produzierende Qualität einer Software treffen. Was bedeutet dies nun in der konkreten Anwendung im Unternehmen?

In der perfekten agilen Welt liefern wir einen kontinuierlichen Fluss von Funktionalitäten aus: Auf der Ebene einer jeden Story ist diese getestet auf ihre Qualität und im Kontext des Gesamtsystems validiert, im Extremfall nicht nur auf den Test- sondern auch auf den Produktivserver verteilt.

Um soetwas tun zu können, müssen wir in der Lage sein, mit geringem Aufwand zu prüfen, ob eine User Story funktioniert und die Erstellung der Story eine Auswirkung auf einen anderen Teil des Systems hatte. Schließlich wollen wir ja keine neuen Defekte hinzufügen, weil neue Funktionen hinzukommen. Mittlerweile gibt es ja eine ganze Hand voll Best Practices in diesem Bereich. Specification By Example, TDD, Integrations- und Unittests oder Konfigurationsmanagementtools sind einige von Ihnen.

Schaffen wir es, den Automatisationsgrad von Tests und Deployment so weit zu bringen, dass es im Sprint möglich ist, die Qualität zu sichern, die wir gerne hätten, haben wir Feedback dann zur Hand, wenn es am wichtigsten ist: Kurz nach der Produktion, wenn Entwickler noch wissen, wo der Defekt zu finden ist oder wie das Feature leicht zu modifizieren ist, damit es das tut, was der Kunde wirklich will. Denn wir wollen Fehler beheben, statt sie zu verwalten.

Abhängig von den Fähigkeiten im Team, den bisher verwendeten Tools, der Testbarkeit des Codes und der eigenen Disziplin ist die Erreichbarkeit solch einer Qualitätskontrolle für das eine Unternehmen eine überschaubare Strecke, für das andere ein Ultramarathon, der schnell als unmöglich schaffbar bezeichnet wird.

Ein befreundeter Agile Coach, der aus Leidenschaft extrem lange Strecken läuft, hat mir einmal erzählt, wie man eine 116km-Strecke angeht:

Viel Training, die Vorstellung des nächsten kleinen Abschnitts statt der ganzen Riesenstrecke im Kopf und: man sollte Lust darauf haben.

Wenn ihr Team sich gerne die Finger schmutzig macht, versuchen Sie es mit kleinen kontinuierlichen Schritten: Erweitern Sie die Definition of Done regelmäßig in der Form, dass mehr Aspekte auf Story- und Sprintebene fertiggestellt werden und weniger je Release. Das wird vielleicht zeitweilig anstrengend sein, aber Schritt für Schritt gelingt so auch der lange Lauf – wenn man darauf Lust hat.