Der Product Owner, mit dem ich zusammenarbeite, hat zugestimmt, „dieses selbstorganisierende Zeug“ in unserem Scrum-Team auszuprobieren.
Um es kurz zu machen: Ich habe sie davon überzeugt, dass es zwei Wege für das Team gibt. Einer, in dem sie das Team leitet und leitet, aber auch weitgehend die Verantwortung für die Ergebnisse und den Unterhalt übernimmt, oder alternativ können wir zusammenarbeiten, um ein selbstorganisierendes Team aufzubauen, das Eigenverantwortung und Eigenverantwortung übernimmt. Sie hat zugestimmt, letzteres zu versuchen.
Hat jemand dies ausprobiert oder kann eine Methode empfehlen, um dieses Konzept einem Product Owner zu vermitteln und zu coachen, der offen für Veränderungen ist, aber sehr dominant und richtungsweisend gegenüber dem Team ist.
Ich dachte daran, einfach all ihre Verhaltensweisen auf Miro abzubilden und zu erklären, welche Verhaltensweisen zu welcher Art von Team beitragen. B. das Team immer daran zu erinnern, x,y,z zu tun, führt dazu, dass es nie die volle Verantwortung für x,y,z übernimmt. usw
Obwohl es wie eine psychologische Frage erscheint und sich nicht auf Methoden bezieht, stimme ich nicht zu, dass es eine Sackgasse ist und Sie das Verhalten der Menschen nicht ändern können. Aber zuerst müssen Sie die zugrunde liegenden Gründe für ein solches Verhalten verstehen, könnten sein:
Sobald Sie verstehen, was diesem „herrschsüchtigen“ Verhalten zugrunde liegt, können Sie versuchen, einen Plan zu entwickeln, um es zu beheben. Einige Lösungen, die für manche Menschen funktionieren können:
Jedenfalls würde ich experimentieren. Ich denke, es ist entscheidend, dass das Team die Domäne sehr gut versteht, damit dieser Plan erfolgreich ist.
Aber ich würde auch darauf achten, das Team nicht zu überschätzen. Sie hören immer wieder von sich selbst organisierenden/selbst verwaltenden Teams, als ob es eine gute Sache wäre und wir danach streben sollten. Aber die meisten Teams (zumindest nach dem, was ich gesehen habe) sind von Natur aus nicht in der Lage, sich selbst zu organisieren. Und sich in diese Richtung zu bewegen, kann den Prozess verlangsamen und folglich Leute vertreiben, die tatsächlich in der Lage sind, einen guten Job zu machen (vielleicht ist es Ihr PO).
Nein, nein, nein. Einfach nein."
Die Frage basiert auf der fehlerhaften Annahme, dass Sie anderen Menschen Veränderungen aufzwingen können (Hinweis: Sie können nicht), und wünscht eine scheinbar schlechte Teamzusammensetzung ins Maisfeld.
Der Product Owner, mit dem ich zusammenarbeite, hat zugestimmt, „dieses selbstorganisierende Zeug“ in unserem Scrum-Team auszuprobieren.
Dies ist ein Warnsignal, das Ihnen sagt, dass eine Person, die Sie als „herrschsüchtig“ beschrieben haben, bereit ist, die Einführung von Agile per Hand zu winken oder der Bitte nachzugeben, ohne sich tatsächlich zu Scrum oder den agilen Werten zu verpflichten. Das ist keine solide Grundlage für Veränderungen.
Sie stellen eine Frage, die von vornherein davon ausgeht , dass es eine Wunderwaffe gibt, die es Ihnen ermöglicht, diese Person zu ändern , die derzeit nicht für die Mitgliedschaft in einem Scrum-Team geeignet ist. Der Product Owner ist ein Mitglied des Teams mit spezifischen Verantwortlichkeiten , kein auf Lebenszeit gewählter autoritärer Diktator. Der Scrum-Guide sagt:
Innerhalb eines Scrum Teams gibt es keine Unterteams oder Hierarchien. Es ist eine zusammenhängende Einheit von Fachleuten, die sich jeweils auf ein Ziel konzentrieren, das Produktziel ... Das Scrum-Team wird ... von der Organisation strukturiert und befähigt, ihre eigene Arbeit zu verwalten.
Daher ist jede Darstellung des Problems, die dort nicht beginnt, dazu bestimmt, eine Nebenschau von epischen Ausmaßen zu sein, voller Drama und Tränen. Nur der Product Owner kann sein eigenes Verhalten ändern, und dazu muss er es wollen . Ohne das ist es Zeitverschwendung.
Die richtigen Fragen sind:
Stellen Sie diese Fragen nicht nur sich selbst. Als Scrum Master müssen Sie das Engagement, den Fokus, die Offenheit, den Respekt und den Mut haben , diese Fragen allen Beteiligten einzeln und gemeinsam zu stellen. Das ist nicht Ihr Problem, das Sie lösen müssen; Es ist das Problem des Scrum-Teams, und wenn es ungelöst bleibt, wird es zum Problem der Organisation.
Der Product Owner hat eine klar definierte Rolle (ausgesprochen „accountabilities“ im Scrum Guide 2020), und das Scrum-Team sollte zusammenarbeiten, um interne Arbeitsvereinbarungen zu entwickeln, die die Anforderungen des Frameworks unterstützen (aber nicht konterkarieren). Das bedeutet, dass „herrschsüchtiges“ Verhalten sein muss:
Als Scrum Master können und sollten Sie diese Person so gut wie möglich coachen. Erklären Sie die Rollen/Verantwortlichkeiten, helfen Sie ihnen, die agilen Prinzipien , die Scrum-Theorie und die Scrum-Werte so gut wie möglich zu verstehen , und geben Sie ihnen sogar einige Hausaufgaben zum Lesen von agilen Praktiken und Fallstudien, wenn Sie etwas Passendes finden. Jedoch...
Der Scrum Master ist nicht nur ein passiver Servant-Leader. Der 2020 Scrum Guide hat dies deutlich gemacht. Zu den Verantwortlichkeiten eines Scrum Masters gehören:
Der Scrum Master ist verantwortlich für die Etablierung von Scrum, wie im Scrum Guide definiert. Sie tun dies, indem sie jedem helfen, Scrum-Theorie und -Praxis zu verstehen, sowohl innerhalb des Scrum-Teams als auch der Organisation.
Der Scrum Master ist für die Effektivität des Scrum Teams verantwortlich. Sie tun dies, indem sie es dem Scrum-Team ermöglichen, seine Praktiken innerhalb des Scrum-Frameworks zu verbessern.
Wenn Sie also den Product Owner (und den Rest des Scrum-Teams) nicht für die effektive Zusammenarbeit innerhalb des Scrum-Frameworks verantwortlich machen, dann erfüllen Sie Ihre Rolle auch nicht richtig. Ihre Aufgabe ist es, sie über das Framework aufzuklären, ihnen zu helfen, das Framework auf ihre Probleme und Prozesse anzuwenden, und die Sichtbarkeit unüberwindbarer Probleme bei der Teamzusammensetzung für die Geschäftsleitung zu erhöhen . Tatsächlich sagt der 2020 Scrum Guide (Hervorhebung von mir):
Der Scrum Master dient der Organisation auf verschiedene Weise, darunter:
- Führung, Schulung und Coaching der Organisation bei der Einführung von Scrum;
- Planung und Beratung von Scrum-Implementierungen innerhalb der Organisation;
- Unterstützung von Mitarbeitern und Stakeholdern [einschließlich Führungskräften] beim Verstehen und Umsetzen eines empirischen Ansatzes für komplexe Arbeiten; Und,
- Beseitigung von Barrieren zwischen Stakeholdern und Scrum-Teams .
Letzteres ist besonders wichtig. Probleme mit der Teamzusammensetzung liegen (in vielen Organisationen) außerhalb der Kontrolle des Scrum-Teams. Daher müssen Probleme, die innerhalb des Teams nicht durch Selbstverwaltung und Zusammenarbeit gelöst werden können, für die Organisation sichtbar gemacht werden , und die Verantwortung für die Behebung von Problemen bei der Teamzusammensetzung oder die Lösung von HR-Problemen liegt letztendlich in der Verantwortung der Führung der Organisation.
Als Scrum Master müssen Sie den Mut und das Engagement haben, diese Probleme bei Bedarf anzusprechen. Wenn dem Scrum-Team als Ganzes die Fähigkeiten, das Engagement oder die Bereitschaft fehlen, Kommunikations- und Prozessprobleme direkt anzugehen, gibt Scrum eine klare Anleitung, was zu tun ist: Transparenz und Sichtbarkeit des Problems für die Organisation schaffen und dann halten Die Führung der Organisation ist dafür verantwortlich, die Dinge zu lösen, zu deren Lösung nur sie befugt sind.
Arbeiten Sie auf jeden Fall mit dem Product Owner und den Entwicklern zusammen, um die Probleme sichtbar zu machen und die Zusammenarbeit nach Möglichkeit zu lenken, aber Ihre Aufgabe ist es nicht, auf dem Hügel zwischenmenschlicher Konflikte innerhalb des Teams zu sterben. Erklären Sie den Prozess, leiten Sie das Team bei der Anwendung des Prozesses an und helfen Sie dem Team, den Prozess anzupassen, aber am Ende ist jedes Mitglied des Scrum-Teams voll verantwortlich für seine eigene effektive Teilnahme (oder das Fehlen einer solchen) am Prozess. Sie können sie nicht dazu bringen , es zu tun, oder sie dazu bringen, es tun zu wollen .
Scrum ist keine Wunderwaffe. Es kann Menschen, die sich nicht selbst verwirklichen, nicht durch Magie in ein zusammenhängendes, leistungsstarkes Team verwandeln. Es erfordert Engagement und harte Arbeit des gesamten Teams sowie ein gewisses Maß an intrinsischem Antrieb von den Teammitgliedern. Ihre Hauptaufgabe in dieser Situation besteht darin, festzustellen, ob es sich um einen Berg oder eine Maulwurfshügel handelt, und dann dem Team und der Organisation zu helfen, den Lösungsraum zu erkunden, bis sich alle auf ein Experiment oder einen Aktionsplan einigen, der im besten Interesse des gesamten Teams ist , das aktuelle Projekt und die Organisation.
Mit einem anderen Ansatz als Barnaby würde ich vorschlagen, sich auf das zu konzentrieren, was von ihr benötigt wird , und nicht auf das, was von ihr problematisch ist. (Oder kombinieren Sie die beiden Ansätze.)
Gehen Sie den Scrum Guide mit dem gesamten Team durch und achten Sie dabei auf den Abschnitt über die Verantwortlichkeiten der Rollen. Wenn sie dann anfängt, ihre Anwesenheit gegenüber dem Team zu behaupten (auf eine Weise, bei der es offensichtlich keine korrekte Behauptung ist), bitten Sie sie, dies zu rechtfertigen.
"Können Sie bitte erklären, wie genau das mit Ihrer Vertretung der Bedürfnisse des Kunden zusammenhängt?"
„Das tut es nicht, aber wir müssen uns trotzdem der Auswirkungen auf das Projekt bewusst sein.“
„Danke, dann lassen wir uns bei unserer Entscheidung beraten. Sonst noch etwas?“
Was natürlich auch Raum für den Fall lässt, wenn:
"Können Sie bitte erklären, wie genau das mit Ihrer Vertretung der Bedürfnisse des Kunden zusammenhängt?"
"Der Kunde hat ausdrücklich darum gebeten, die Verwendung von flexiblen Widgets zu vermeiden."
"...Warum?"
"Ich muss das noch einmal überprüfen, aber ich denke, weil sie nicht mit ihren Servern kompatibel sind?"
„Okay, gut, überprüfen Sie das bitte noch einmal, und in der Zwischenzeit werden wir versuchen, uns etwas anderes auszudenken.“
Der Schlüssel wird darin bestehen, Möglichkeiten zu haben, die Auswirkungen des Mikromanagements des Product Owners hervorzuheben. Wenn Sie die Auswirkungen nicht nachweisen können, gibt es wenig, was sie davon abhalten könnte, zu ihren alten Gewohnheiten zurückzukehren.
Zum Beispiel:
„Sally war heute blockiert, da sie darauf warteten, dass der Product Owner entscheidet, was als nächstes zu tun ist. Wenn sie diese Entscheidung selbst oder in Zusammenarbeit mit dem Team treffen könnten, hätten wir uns einige Stunden sparen können.“
Wie bereits erwähnt, kann man eine dominierende Persönlichkeit nicht davon überzeugen, nicht zu dominieren.
Ich bin mir auch nicht sicher, ob sie die Welt so sieht wie du, nämlich:
Eines, in dem sie das Team leitet und leitet, aber auch weitgehend die Verantwortung für die Ergebnisse und den Unterhalt übernimmt, oder alternativ können wir zusammenarbeiten, um ein selbstorganisierendes Team aufzubauen, das Eigenverantwortung und Eigenverantwortung übernimmt .
Das heißt, da sie "Mikromanagement" betreibt, ist sie für die Konsequenzen verantwortlich, aber wenn sie "loslässt", ist das Team verantwortlich.
Ich vermute, dass Sie eine Vermutung anstellen.
Sie kann sich so oder so für verantwortlich halten oder nicht verstehen, warum sie in beiden Szenarien verantwortlich ist – das hängt auch von ihrer Persönlichkeit ab.
Sobald Sie ihre Weltanschauung zu diesem Thema geklärt haben, können Sie versuchen, die Situation zu verbessern.
Wenn sie sich "auf jeden Fall" verantwortlich sieht, dann müssen Sie ihr beweisen, dass es für sie bessere Ergebnisse bringt, wenn Sie Ihrem Team den nötigen Spielraum geben.
Wenn sie das Team verantwortlich macht, dann haben Sie es schwerer; versuchen, sie davon zu überzeugen, dass sie das Sagen hat, während sie etwas Unabhängigkeit erlangen. Du stehst in direktem Konflikt mit ihrer gesamten Persönlichkeit.
Okay, ich werde meine "abgelehnte Antwort" noch einmal hinzufügen.
"Du bist ein Softwareprojekt. Gut für dich. Du organisierst dich selbst oder selbst, wie du willst. Gut für dich."
"Du bist nicht der Product Owner!"
Der Product Owner ist die entscheidende Schnittstelle zwischen Ihrem gesamten Entwicklungsprozess und dem Unternehmen, das dafür bezahlt. Und wollte ich das erwähnen: "Das Geschäft weiß, versteht oder kümmert sich nicht?"
Die Rolle des Product Owners ist weit mehr als nur die eines „Stellvertreters“. Die Rolle des Besitzers ist wirklich die von Janus – „der zweiköpfige Gott“. Es ist eine Rolle, die von „denen, die darunter liegen“, häufig missverstanden wird, und es ist keine Rolle, um die man sie beneiden muss. Der Eigentümer ist derjenige, der Sie schützt .
Über Ihrem Team wird „das Unternehmen“ den Eigentümer zur Rechenschaft ziehen. Und „der Eigentümer“ wird diese Verantwortung übernehmen , sodass – absichtlich – keiner von Ihnen dies tun muss. Aber die Verantwortlichkeit ist immer noch da.
Stanislaw Baschkirtsew
Benutzer32613
Todd A. Jacobs
Benutzer32613