In der heutigen Folge geht es um die Kraft der Gemeinschaft. Es geht darum, wie du Gemeinschaften dazu nutzen kannst, Veränderungsvorhaben, die gerade anstehen oder da sind, zu unterstützen.
Und was dabei zu beachten ist, welche Parameter wir uns anschauen und welche Reflexionsfragen wir uns in unserem Leben stellen, wenn es um das Thema Gemeinschaften geht.
Wer agile Arbeitsweisen wie Scrum oder Kanban schon einmal eingeführt hat, weiß, dass Widerstände ein Teil der Sache sind. Jede Veränderung in einer Organisation hat immer wieder Felder von Widerstand. Was ist deine persönliche Rolle im Umgang damit und wie kannst du mit Menschen, Teams und Systemen besser umgehen, die im Widerstand zu solchen Veränderungen sind?
Darum geht es in dieser Folge. Wir teilen unsere Praxiserfahrungen und Tipps dazu, die dir helfen, effektiver in solchen Umfeldern zu sein.
Viel zu viele Meetings! Wer Scrum einführt und auf agiles Arbeiten setzt, kennt das Problem: irgendwer nörgelt immer darüber, dass es jetzt so viele neue Meetings gibt. Wir schauen uns die Symptome dieser Problematik an: hat Scrum wirklich so viele Meetings und was müssen wir tun, um sie effektiver zu gestalten?
Warum kann es legitim sein ein Team Assessment durchzuführen?
Wie gehen wir da ran, mit welcher Haltung und wir stellen Dir ein ganz konkretes Werkzeug vor, welches wir lieben und oft benutzen und stellen Dir auch drei Arten vor, wie Du dieses für Dich in Deinem Alltag benutzen kannst.
Darf, soll oder muss ein Scrummaster oder Agilecoach eigentlich auch ein Performancecoach sein?
Wir haben ChatGPT gefragt und waren mit der Antwort völlig unzufrieden. In einem munteren Diskurs pflügen wir uns durch unsere Erfahrungen, wie individuelles und teambezogenes Performancecoaching in das Bild von agilen Vorgehensweisen passt.
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.
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ägelbeim 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“
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.
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.
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.
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
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.
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.
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).
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.
Der Product Owner ist eine der drei Rollen in Scrum. Er verantwortet den Produkterfolg. Doch welche Fähigkeiten helfen dabei, diesen zu erreichen?
Überzeugungskraft
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
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.
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
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.
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
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?
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.
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?