Kann eine einzelne Ressource in mehreren Teams für mehrere Projekte sein?

Ein einzelner Benutzer wird mehreren Teams in einer Organisation zugeordnet, die mehrere Projekte gleichzeitig bearbeitet. Kann ein Scrum Master die Aufgaben dem Benutzer zuweisen, der in mehreren Teams und mehreren Projekten ist?

Ihr Scrum Master sollte dem Benutzer keine Aufgaben zuweisen. Die Person sollte sich selbst Aufgaben zuweisen. Das Ausbalancieren von Prioritäten zwischen Projekten ist ziemlich schwierig und etwas, das Sie in Scrum-Teams im Allgemeinen vermeiden möchten.

Antworten (2)

Bei diesem Ansatz gibt es eine Reihe von Problemen:

  • Multitasking verringert die Effizienz. Jedes Mal, wenn sie zwischen Projekten den Kontext wechseln müssen, verlieren sie an Effektivität.
  • Scrum basiert auf der Idee einer bekannten Teamkapazität, die zur Berechnung der Geschwindigkeit verwendet wird. Wenn Teammitglieder wechseln oder für andere Teams arbeiten, kann die Geschwindigkeit nicht mehr genau bestimmt werden.
  • Die Person wird quasi zu einer externen Ressource, die es zu koordinieren gilt. Dies verringert die Effektivität des Teams.
  • Viele der Scrum-Zeremonien sind nur für Vollzeit-Teammitglieder gedacht. Zum Beispiel sind der tägliche Stand-up und die Retrospektive in der Regel für Vollzeit-Teammitglieder gedacht, die sich der Arbeit verschrieben haben.
  • Die Doppelteamrolle erzwingt eine Priorisierung zwischen zwei unabhängigen Backlogs. zB ist es eine Priorität für sie, an Story X für Team A oder Story Y für Team B zu arbeiten?
Wenn ich Ihren ersten Punkt ergänzen darf, haben einige Studien gezeigt, dass der Einfluss des Kontextwechsels für jedes Projekt bis zu 20 % im Vergleich zum ersten beträgt. Da es oft die Top-Leute des Unternehmens sind, die sich spalten, ist dies ein enormer Preis, der zu zahlen ist und der sehr offen besprochen werden sollte, bevor man sich dafür entscheidet.
Außerdem riecht es für einen Scrum Master, Aufgaben zuzuweisen. Es wird erwartet, dass sich das Team in Scrum selbst organisiert. Der Scrum Master sollte sehr hart arbeiten, um von der Praxis wegzukommen und die Entwickler darin zu coachen, ihre eigene Arbeit auszuwählen.

Wir hatten einen gottähnlichen Entwickler, der für mehrere Projekte arbeitete. Er war eine Wunderwaffe für jedes Problem. Wahrer Retter in verzweifelten Situationen. Die Lösung hier bestand darin, benutzerdefinierte Filter in Jira zu erstellen, damit er seine Arbeitslast verwalten konnte, da verschiedene Projekte unterschiedliche Abläufe und Schemata verwendeten. Die von PM verwalteten Probleme werden gemeinsam priorisiert, wobei der COO als Schiedsrichter fungiert und numerische Prios von Jira Agile verwendet, die eindeutig sind. Er nahm überhaupt nicht an Scrum-Meetings teil. Der Entwickler hat immer an Top-Prio-Problemen gearbeitet. Seine Hauptaufgabe war die Brandbekämpfung (Blockerprobleme bei Prod) und der letzte Ausweg (falls wir einen Booster brauchten, um alle Probleme aus dem Sprint-Rückstand zu schließen). Wir haben seine persönliche Geschwindigkeit nicht verfolgt, da die Teams unterschiedliche Story-Points-Skalen hatten. Alle Story Points für gelöste Probleme wurden zu einer Teamgeschwindigkeit hinzugefügt. Dass' So haben wir die Geschwindigkeit stabiler gehalten und unbekannte Risiken gemindert. Eine weitere Sache an ihm ist, dass trotz seines weit überlegenen Stundensatzes die durchschnittlichen Kosten für einen von ihm gelieferten Story Point im Vergleich zu einem von ihm unterstützten Team deutlich niedriger waren. Es gab also keine negativen Auswirkungen auf das Budget. Ich hoffe, diese Kriegsgeschichte war hilfreich für Sie.