Ist es möglich, Mitglied in zwei Scrum-Teams zu sein, und wie lässt sich das am effektivsten gestalten?

Wir haben eine Organisation, in der wir zu zwei Scrum-Teams wechseln, die an verschiedenen Teilen unseres Backlogs arbeiten . Ich verstehe die Idee, dass jedes Team eine komplette funktionsübergreifende Einheit sein sollte und keine anderen Ablenkungen haben sollte. Das scheint ein perfektes Ideal zu sein.

In unserem Fall haben wir ein Teammitglied, dessen Fähigkeiten für beide Teams nützlich sein könnten, aber beide Teams haben normalerweise keine Vollzeitbeschäftigung für sie. Um dies konkret zu machen, sie ist Webdesignerin (und Web ist nicht unser Hauptprodukt), aber das Gleiche könnte für jeden mit speziellen Fähigkeiten gelten. Und sie ist sehr gut in dem, was sie tut, also ist es sowohl suboptimal als auch unbefriedigend für sie, zu sagen: „Nun, arbeiten Sie in diesem einen Team und finden Sie andere Möglichkeiten, um zu helfen – schreiben Sie ein paar Dokumente oder so etwas“.

Gibt es eine gute Möglichkeit für sie, zu beiden Teams beizutragen, ohne das Gefühl zu haben, doppelt so viel Meta-Arbeit und widersprüchliche Prioritäten zu haben?

Wenn ja, wie geht man damit am besten um? Was, wenn es vier Menschen gibt, die so denken, und nicht nur einer?

Wenn nicht, was ist stattdessen zu tun? Der Ansatz, zu dem ich neige, besteht darin, sicherzustellen, dass alle User Stories so aufgeteilt werden, dass alles, was ein gewisses Webdesign erfordert, vollständig von ihrem Team gehandhabt werden kann, aber ich weiß nicht, wie gut das skalieren wird.

Antworten (4)

Ich sehe, dass dies bei System Architects die ganze Zeit passiert. Ihre Spezialfähigkeiten werden von mehreren Teams benötigt, aber kein einzelnes Team verbraucht ihre gesamte Zeit während des Sprints.

Die beste Lösung, die ich für diese Art von Situation gesehen habe, besteht darin, dass die Gruppe spezialisierter Personen (Architekten, Designer usw.) als ihr eigenes Scrum-Team agiert und Verpflichtungen eingeht, die auf ihrer Fähigkeit basieren, die Bedürfnisse der anderen Teams zu erfüllen.

Dadurch stellen Sie sicher, dass die spezialisierte Gruppe/Einzelperson eine ehrliche Verpflichtung eingehen kann, und Sie legen die Probleme offen, die damit verbunden sind, dass sich die Teams auf eine spezialisierte Ressource verlassen, die es Ihnen ermöglicht, diese Probleme zu inspizieren/anzupassen, um sie zu lösen oder zu mindern.

+1 - Interessante Arbeitsweise. Sie verwenden Scrum im Grunde, um Teams zu leiten, die andere Scrum-Teams unterstützen.
Wie geht dieses Team seine Verpflichtungen zu Beginn des Sprints ein?
Sie summieren ihre Kapazität für den Sprint und beginnen, sich den Aufgaben mit der höchsten Priorität zu widmen, wo ihre Spezialisierung erforderlich ist. Wenn zwei Teams das Fachwissen des Webdesigners für ihre volle Kapazität benötigen, muss eine Entscheidung (oder ein Kompromiss) mit Priorität getroffen werden.

Laut Scrum ist es nicht möglich, aber im wirklichen Leben passiert es von Zeit zu Zeit, und es ist eine gute Sache und es funktioniert. Stellen Sie sicher, dass sie sowohl an Stand-up- als auch an Planungsbesprechungen teilnehmen kann, damit sie seine Arbeit organisieren kann, weiß, was kommt, und die Teams wissen, was sie von ihr erwarten können. Ich sehe keine andere gute Lösung.

Scrum by the Book besagt, dass Teammitglieder weder in verschiedenen Teams noch in verschiedenen Projekten sein müssen. Dies ist eine ideale Situation, aber wenn ein Unternehmen auf Scrum/Agile umstellt, kann es eine Weile dauern, bis die Projektressourcen nach Scrum strukturiert sind.

Ich würde damit beginnen, sie in mehreren Teams und Projekten zu haben, auch wenn das nicht ideal ist, aber die gleichzeitigen Splits so weit wie möglich reduzieren. Dann müssen Sie in den Retros wachsam sein, wie das Team und das Projekt funktionieren. Wenn alle glücklich sind, cool. Wenn nicht, arbeiten Sie mit dem Management zusammen, um für eine bessere Situation zu sorgen. Dies könnte bedeuten, dass Sie die ganze Zeit über einen Junior-Architekten in Ihrem Team haben oder sogar die Idee „Architekt als Scrum-Team“ von Clayton umsetzen.

Liefern Sie zuerst, wenn das Management gute Ergebnisse sieht, ist es einfacher, es zu den Änderungen zu überreden, die für noch bessere Ergebnisse erforderlich sind.

Scheuen Sie sich nicht davor, „einen beschissenen Anfang zu machen“, bei Scrum geht es darum, Ihren Prozess zu verbessern, nicht darum, ihn von Anfang an richtig zu machen.

Lassen Sie sie nacheinander zu jedem Team beitragen. Es ist nicht ideal. Aber es ist besser, als ihr Multitasking zu haben.