Ich bin Teammitglied in einem Scrum-Team. Heute Morgen hatte ich eine Diskussion mit meinem Scrum Master, in der ich sagte, dass ich zwei Leute aus einem anderen Team brauche, um Teil meines Teams zu werden. Ich sagte, ich würde das gerne mit dem Product Owner und dann mit dem Manager besprechen. Der Scrum Master änderte die Diskussion grundlegend und sagte, dass die Verantwortung dafür nicht bei mir oder dem Product Owner liege, sondern beim Scrum Master.
Wer ist für die Änderung der Zusammensetzung des Scrum-Teams verantwortlich?
Das ist eine interessante Frage, weil sie einige der Feinheiten der Selbstorganisation mit agilen Frameworks anspricht. Insbesondere werden die Unterschiede zwischen Autorität und Einfluss hervorgehoben .
Scrum- Teammitglieder sind dafür verantwortlich, Hindernisse zu identifizieren (z. B. das Team hat nicht genügend Fachwissen im Datenbankdesign) und adaptive Verbesserungen zu empfehlen (z. B. vorzuschlagen, dass John Doe, der DBA, die Erfahrung einbringen könnte, die dem Team fehlt). Teammitglieder sind auch dafür verantwortlich, Einfluss auf die Teamzusammensetzung auszuüben, indem sie Empfehlungen zum Hinzufügen oder Entfernen von Personen aus dem Team abgeben.
Product Owner sind (häufig) für die Ressourcenbudgetierung verantwortlich. In solchen Fällen wäre der Product Owner dafür verantwortlich, Ressourcen zu genehmigen oder abzulehnen, die mit seinem Budget belastet würden. Dies fällt direkt in die Kernverantwortung des Product Owners, Projektprioritäten festzulegen.
Scrum Master sind dafür verantwortlich, Diskussionen über Projektressourcen (einschließlich Ressourcenbeschränkungen), Prozesshindernisse und Empfehlungen zur Prozessverbesserung zu erleichtern. Scrum Mastern fehlt jedoch im Allgemeinen die Autorität , organisatorische Veränderungen direkt umzusetzen. Wenn sich das Scrum-Team auf eine Vorgehensweise einigt, ist der Scrum Master dafür verantwortlich, dass die Empfehlungen des Teams die entsprechenden Entscheidungsträger erreichen, und die Interessen des Teams innerhalb der größeren Organisation durch Einfluss zu fördern .
Sofern dem Scrum Master keine zusätzlichen Befugnisse über den typischen Umfang der Rolle hinaus zugewiesen wurden, sollte er keine einseitigen Entscheidungen über die Einstellung oder Zuweisung von Ressourcen treffen. Dies ist keine allgemein akzeptierte Scrum-Praxis und sicherlich nicht im Interesse der Teambildung; Dennoch kommt es gelegentlich in bestimmten Arten von Organisationen vor.
Es ist völlig richtig, Ihre Bedenken und Empfehlungen im Team vorzubringen, aber es ist die gemeinsame Verantwortung des Scrum-Teams, sich auf eine Lösung und einen Sprecher zu einigen . Die Entscheidung, welche Personen oder Ressourcen das Team benötigt und wie das Team den Scrum Master am besten dabei unterstützen kann, die Interessen des Teams gegenüber dem Rest der Organisation zu vertreten, liegt jedoch definitiv nicht in Ihrer alleinigen Zuständigkeit.
Organisatorische Befugnisse, sei es im Namen des Unternehmens oder des Scrum-Teams, müssen immer delegiert werden. Der Scrum Master wäre völlig richtig, wenn er ein Teammitglied, das eine einseitige Herangehensweise an dieses Problem verfolgt, als außerhalb der allgemein akzeptierten Praktiken des Frameworks kennzeichnen würde.
Das erste des agilen Manifests lautet: „Individuen und Interaktionen stehen über Prozessen und Werkzeugen“. Das bedeutet, dass niemand davon abgehalten werden sollte, Hindernisse zu beseitigen, indem man sagt, dass dies nicht seine Rolle ist . Vor allem, wenn es einen tragfähigen Impuls gibt, Dinge zu erledigen.
Wenn Sie sich die "Regeln" genauer ansehen möchten, sollte jedes Teammitglied in der Lage sein, Risiken und Hindernisse anzusprechen und Lösungen und Minderungspläne vorzuschlagen. Wenn einem Team Fähigkeiten oder Wissen fehlen, würde dies auch die Fähigkeit eines Teams beeinträchtigen, Ziele zu erreichen. Es hört sich auch nach einem PO-Hindernis an.
Das Entfernen von Hindernissen liegt in der Verantwortung eines Scrum Masters, da Teammitglieder und PO oft stark darauf konzentriert sind, die Ergebnisse zu erzielen, also sollte es jemanden geben, der sich auch um die Leistung des anderen Teams kümmert , da ihre Ressourcen (eigentlich) ausgeraubt werden. Trotzdem kann ich mir kaum einen SM vorstellen, der es ohne aktive Unterstützung eines Teams schaffen würde, eine Teamgröße zu verändern.
Wenn ich Ihre Frage richtig verstanden habe, da Ihr Team versucht, Ressourcen hinzuzufügen, dann tun Sie das Richtige. Wenn Sie jedoch festgestellt haben, dass Sie eine solche Anpassung vornehmen müssen, befürchten Sie, dass dies nicht Ihre Entscheidung ist, sondern die Entscheidung des Teams. In Scrum-Teams treffen Sie solche Entscheidungen gemeinsam. Wenn Sie also glauben, dass Sie zwei Ressourcen benötigen, ist es besser, dies als Hindernis im täglichen Scrum vorzustellen und nach dem Scrum gegenüber Team und SM die Gründe zu begründen, warum Sie dies beabsichtigen. In Scrum ist das Team befugt, Anpassungen am Team-Setup vorzunehmen, ein Scrum Master könnte jedoch überwachen, ob Sie das Richtige tun oder nicht. Zum Beispiel ist Ihre Teamgröße 6-7 und Sie fügen ein paar weitere Ressourcen hinzu, Sie riskieren den Aspekt der Kommunikation, des Flusses usw. PO ist am Ende des Tages dem Unternehmen für den ROI am Ende des Sprints verantwortlich. Er könnte das Projekt finanzieren, wenn dies der Fall ist, wie Adrian oben vorschlägt, dass dies seine letzte Aufforderung ist, Ressourcen hinzuzufügen, da dies Auswirkungen auf die Kosten haben könnte. Wenn diese beiden Ressourcen von anderen Teams gemeinsam genutzt werden, sollte dies nicht die Genehmigung von PO erfordern, sondern möglicherweise die leitende PO für die gesamte Plattform. Wenn Sie Ressourcen gemeinsam genutzt haben, ist es besser, Cluster-Sprint-Planungsmeetings durchzuführen, bei denen gemeinsame Ressourcen beteiligt sind.
Lassen Sie uns ein wenig rationalisieren: - Es ist definitiv nicht der Anruf des PO, er ist für das Management des Produkts und nicht des Teams (das selbst verwaltet wird) verantwortlich, aber natürlich hält er das Budget, so dass es einen indirekten Anruf für die Teamstruktur gibt. - Der Scrum Master muss das Team im Hochleistungsmodus halten - also sollte sein Ansatz sein: Ich sehe, Ihnen fehlt etwas Muskelkraft, schauen wir uns an, ob wir X weitere Leute zu unserem Scrum hinzufügen können.
Aber es sollte der Aufruf des Teams sein, ein weiteres Teammitglied hinzuzufügen und wer diese Teammitglieder sein sollten, da sich das Team mit der Hinzufügung wohl fühlen muss.
Nun zum Timing: Retrospektive ist ein guter Moment, um zu sagen: „In diesem Sprint sind wir auf den Mangel an X- oder Y-Fähigkeiten gefallen“ oder während der Planung: „Um diese USs zu erledigen, brauchen wir X und Y, die wir nicht im Team haben.“
Das ist Theoriegerede... In der Praxis entscheidet meist derjenige, der das Budget hat.
In einer idealen Scrum-Welt braucht man keine Menschen, man braucht Teams. Natürlich sieht die Realität anders aus. Ihr Scrum Master hat Recht, es liegt nicht in seiner Verantwortung, aber er muss Teil der Diskussion sein. Ihr Product Owner hat auch recht, denn es liegt auch nicht in seiner Verantwortung. Seine Verantwortung ist es, zu liefern, und wenn diese Handlung gefährdet ist, sollte er etwas dagegen tun. Bis die Änderung des Team-Setups dies nicht beeinflusst, sollte er mit der Änderung einverstanden sein. Es scheint, dass niemand dafür verantwortlich ist. Das ist einer der Schwachpunkte von Scrum. Die entstandene Kluft zwischen Entwicklung und Management ließ diese Fragen offen.
Ich sehe jedoch eher eine recht gute Lösung für dieses Problem: Der Linienvorgesetzte, der Projektleiter, der Product Owner und der Scrum Master sitzen zusammen und die Situation. Wenn sie sich einig sind, fragen sie nach dem Vorschlag des Teams und treffen gemeinsam eine Entscheidung .
Wer ist für die Änderung der Zusammensetzung des Scrum-Teams verantwortlich?
Ich würde ein Treffen einberufen und einladen
Da diese Änderung Auswirkungen auf andere Projekte haben könnte, sollten diese Personen die Möglichkeit haben, sich an der Diskussion zu beteiligen.
Der Manager, der Product Owner und der Scrum Master sollten sich zusammensetzen und dies mit Ihnen besprechen, um zu verstehen, woher Sie kommen.
Der Product Owner sollte sein Backlog griffbereit haben, der Scrum Master sollte Burndowns griffbereit haben und der Manager sollte ein Verständnis für Budget usw. haben.
Sie diskutieren alle, um die unterschiedlichen Standpunkte zu verstehen, und dann müsste der Manager höchstwahrscheinlich prüfen, ob dies finanziell machbar ist.
Dann bringen Sie es zum Team und lassen es entscheiden.
Hirschjäger
pvblivs