Tägliches Stand-up mit mehreren Scrum-Teams

Es gibt 3 Scrum-Teams (mit ca. 15 Personen), deren Arbeit eng miteinander verbunden ist, sodass es notwendig ist, dass die Teams über den Fortschritt der anderen auf dem Laufenden sind.

Wie ist es möglich, Informationen zwischen Teams täglich effektiv auszutauschen?

Ein großes Stand-up mit allen Mitgliedern ist zu lang. Wir haben versucht, dass jedes Team einen „Botschafter“ delegiert, der auch am Stand-up der anderen teilnimmt, aber in diesem Fall war der Informationsfluss nicht der beste.

Kennen Sie einen guten Weg, um das verbundene Scrum-Team übereinander auf dem Laufenden zu halten?

Was waren die Probleme bei der Entsendung eines Botschafters? Das Scrum of Scrums wurde entwickelt, um dieses Problem zu lösen, indem Vertreter aus jedem Scrum-Team eingesetzt werden. Haben Sie darüber nachgedacht, sich die ausgewählten Repräsentanten, das Meeting-Format oder andere Gründe anzusehen, warum es nicht funktioniert hat, Botschafter auszuwählen und ein Scrum of Scrums abzuhalten?
@ThomasOwens, was das OP beschrieben hat, ist eigentlich kein Scrum of Scrums.
Haben Sie sich schon einmal Gedanken über ein internes, Twitter-ähnliches Statussystem gemacht?
Sind das insgesamt ~15 Personen in den 3 Scrum-Teams?
... oder 3 Teams mit je 15 Personen, also insgesamt 45 beteiligte Personen?
Möglicherweise finden Sie die Antworten auf diese ähnliche Frage hilfreich: pm.stackexchange.com/questions/6230/…
15 Personen: 105 Kommunikationskanäle. 45 Personen: 990 Kommunikationskanäle. Scrum-Teams sollten bei durchschnittlich nur 22 Kommunikationskanälen auf etwa 7 Personen plus oder minus 2 beschränkt werden.
Abgesehen von anderen Problemen, haben Sie sich das Nexus- Framework angesehen?

Antworten (7)

Wie Thomas Owens feststellte, ist eine der Lösungen zur Skalierung von Scrum das Scrum of Scrums. Was Sie im OP beschreiben, ist jedoch anders:

Wir haben versucht, dass jedes Team einen „Botschafter“ delegiert, der auch am Stand-up der anderen teilnimmt, aber in diesem Fall war der Informationsfluss nicht der beste.

Anstatt dass jedes Team einen Botschafter zum täglichen Scrum der anderen Teams schickt, ist das Scrum of Scrums ein separates Treffen auf höherer Ebene, zu dem normalerweise ein einzelner Botschafter aus jedem Team gehört. Es muss nicht unbedingt ein tägliches Meeting sein, oft ist es für das Team am besten, es 2-3 Mal pro Woche zu haben. Und sein Fokus unterscheidet sich etwas von dem der Scrums auf Teamebene. Ziemlich offensichtlich konzentriert es sich auf den Status auf Teamebene und Blocker. Aber es ist auch eher auf die schnelle Entfernung von Blockern ausgerichtet, so dass es möglicherweise kein strenges Zeitlimit gibt und es sich (nach gemeinsamer Vereinbarung) bei Bedarf in eine Problemlösungssitzung verwandeln kann. Die Teilnehmer können – und sollten – variieren, idealerweise könnte jedes Team seine Botschafter mehr oder weniger regelmäßig wechseln.

Ein weiterer Ansatz zur Unterstützung des Informationsflusses sind Communities of Practice .

Eine Community of Practice ist eine gleichgesinnte oder gleichqualifizierte Gruppe von Personen, die sich aufgrund ihrer Leidenschaft und ihres Engagements für eine Technologie, einen Ansatz oder eine Vision freiwillig zusammenfinden. Bei einem großen Projekt sind diese Praxisgemeinschaften hilfreich, um die Grenzen der vielen funktionsübergreifenden Teams zu überwinden und Einzelpersonen zusammenzubringen.

Wir haben dieses Format in unseren Projekten in den letzten drei Jahren erfolgreich eingesetzt. Eine wichtige Erkenntnis, die wir entwickelt haben, ist, dass das Scrum of Scrum-Meeting protokolliert und versendet werden muss. Die Themen auf dieser Ebene haben oft Breitenwirkung und das Versenden von Protokollen hält diejenigen auf dem Laufenden, die nicht persönlich anwesend sind.

All dies unten ist aus meiner eigenen schmerzhaften Erfahrung:

Im selben Raum sein.

Sprechen Sie während der Arbeit oder in der Mittagspause miteinander.

Am wichtigsten

Stellen Sie sicher, dass Sie ein allgemeines Treffen mit allen versammelt haben (stehend oder nicht), bei dem jede einzelne Person gefragt wird:

  • Was hast du gestern gemacht
  • Woran arbeitest du heute
  • Wenn es Probleme gibt oder er/sie Hilfe braucht

Treffen sind ein Muss, und wenn Sie sie kompromittieren, können die Ergebnisse verheerend sein.

"Ein großes Stand-up mit allen Mitgliedern ist zu lang." war Teil der OP.
Sehen Sie, ich würde gerne Code schreiben, ohne nachzudenken, und einen Tag damit verbringen, Kunden einfache Dinge zu erklären, aber es wird einfach nicht passieren. Manche Dinge lassen sich nicht für immer vermeiden. Als Projektmanager sind Sie eine Führungsfigur und Sie sollen Verfahren durchsetzen, um sicherzustellen, dass das Projekt abgeschlossen und alle bezahlt werden, anstatt alle zufrieden zu stellen und das Projekt zu scheitern.
Ich bin ein Scrum-Master, kein Projektmanager, also bin ich glücklicherweise nicht an den Gehaltsschecks der Teammitglieder beteiligt :-) Ich verstehe, dass dies in Ihrem Team funktioniert hat, und das ist in Ordnung. Das bedeutet jedoch nicht, dass es automatisch die beste Lösung für alle Teams auf dem Planeten wäre. Wenn das OP der Meinung ist, dass Daily Scrums zu langwierig sind, ist die starre Durchsetzung eines Prozesses meiner Meinung nach nicht die richtige Antwort (insbesondere nicht aus der agilen Perspektive). Es gehört zur Definition von Scrum, dass die empfohlene Scrum-Teamgröße ca. 5-9 Personen. Oberhalb dieser weichen Grenze muss Scrum angepasst werden, um zu skalieren.
Übrigens wäre ich daran interessiert, tatsächlich einige konkretere Details zu den Erfahrungen zu lesen, auf die Sie sich oben beziehen. Wie groß war Ihr Team? Auf welche Probleme sind Sie gestoßen und wie haben Sie sie gelöst? Ich denke, wir alle hier sind offen für solide Argumente und freuen uns, aus gut geschriebenen Antworten zu lernen. Leider gibt uns Ihre derzeitige Antwort nicht viel zu lernen :-(
@Peter, tut mir leid, dass ich dir nicht viele Details gegeben habe, da ich diese Beiträge zufällig bei der Arbeit schreibe. Derzeit leite ich ein Team von 9 Personen und Meetings sind unerlässlich. Wenn Menschen gezwungen sind, vor anderen Menschen über sich selbst zu sprechen, bekommen sie ein Verantwortungsgefühl und sie hören auch, was die anderen getan haben. Dadurch erhalten Sie zwei Dinge: Wie gut Sie im Vergleich zu den anderen sind und Sie erfahren den Fortschritt des gesamten Projekts, sodass Sie tatsächlich wissen, warum es für Sie wichtig ist, diese Aufgabe heute zu erledigen (weil das QA-Team darauf wartet, dass Sie fertig sind diese Funktionalität, damit sie sie testen können)
@Peter: Ich habe versucht, solche "großen Meetings" zu vermeiden, um die Entwickler "nicht zu langweilen" und "ihre Zeit zu verschwenden" (da ein Meeting mit 9 Entwicklern und 2-3 Managern mindestens 20-60 Minuten dauert). Das Ergebnis dieser Vermeidung war, dass die Menschen noch mehr voneinander getrennt wurden und Missverständnisse zunahmen. Einfach gesagt: Menschen um jeden Preis dazu zwingen, sich zu treffen und miteinander zu reden. Die meisten Entwickler (oder Arbeiter im Allgemeinen) mögen das nicht, weil sie entweder zu schüchtern oder zu beschäftigt sind, aber es liegt in Ihrer Verantwortung, dafür zu sorgen, dass diese Treffen stattfinden. Hoffe, ich habe geholfen.
Ich stimme voll und ganz zu, dass nur weil Teammitgliedern etwas nicht gefällt, es kein guter Grund ist, es nicht zu tun, wenn es ansonsten auf lange Sicht klare Vorteile für das Team bringt. Das Team muss jedoch verstehen – und schließlich selbst erfahren – warum es erforderlich ist und warum es gut für sie ist. Also meiner Meinung nach sollten wir sie aufklären und überzeugen, anstatt sie zu zwingen, sich zu fügen. Wenn sie den Vorteil nicht sehen, können wir es ihnen zeigen oder demonstrieren? IMHO ist das eine Herausforderung für den Scrum Master / PM, nicht das Manko des Teams.
Ich stimme Gangsta IRL zu - es ist sehr vorteilhaft, alle in einem einzigen Meeting zu haben. Wenn die Meetings zu lange dauern, geht es eher darum, sie „auf den Punkt“ zu bringen. Das Wissen, das in solchen Treffen geteilt wird, bringt meiner Erfahrung nach hervorragende Ergebnisse. Von Zeit zu Zeit hört sich ein Entwickler, der an Projekt A arbeitet, ein Problem an, das von jemandem in Projekt B angesprochen wurde, und schlägt eine Lösung vor, die mehrere Stunden Arbeit und Frustration erspart. In meinem Team führen wir auch monatliche "Wissensaustausch"-Meetings durch, bei denen wir längere, ausgewählte Themen diskutieren.

Vor einigen Monaten habe ich eine Erfahrung mit zwei Teams gemacht: Produkt- und Datenwissenschaftler. In ihrem Moment ändern wir das, was du gestern getan hast , in das, was du gestern bekommst .

Es ist eine einfache Änderung, aber ich denke, eine sehr wichtige Änderung angesichts dieser Situation. Es ist wichtiger, das erreichte Ziel zu erklären, als den Weg, es zu erreichen.

Ich stimme der Hellen-Erfahrung zu.

Achten Sie auf Informationsüberflutung. Es sollte nicht so viele Interaktionen geben, die jeder benötigt, um mit dem Status aller Schritt zu halten

  • Super-Stand-ups haben nur begrenztes Interesse für Mitglieder. Ihre Aufgabe ist es, das Management auf dem Laufenden zu halten.
  • Holen Sie sich ein Team -Chat-Tool . Wenn jemand eine öffentliche Ankündigung hat, kann er sie über den Chat rüberbringen. HipChat von Atlassian ist speziell auf Teams zugeschnitten. Wenn Sie beispielsweise jemand in einem öffentlichen Raum erwähnt oder wenn Sie abwesend sind, sendet es Ihnen eine E-Mail an den Chat.
  • Holen Sie sich ein Team-Wiki . Beispielsweise werden in Atlassian Confluence jedes Mal, wenn jemand eine von Ihnen beobachtete Seite aktualisiert (z. B. den Status bei jeder größeren Änderung), alle benachrichtigt.

Auf diese Weise entsteht weniger Druck auf die Vollständigkeit des täglichen Stand-Ups und jeder kann mit den für ihn relevanten Informationen Schritt halten.

Haftungsausschluss: Ich habe früher bei Atlassian gearbeitet und bin immer noch ein Fan, also können Sie die von mir vorgeschlagenen Tools gerne durch Mitbewerber ersetzen.

In diesem Zusammenhang empfehle ich eigentlich dringend iDoneThis .

Grundsätzlich sendet iDoneThis eine E-Mail an alle in Ihrem Team (also in diesem Fall an alle in Ihren 3 Scrum-Teams) und jede Person schreibt eine kurze Antwort auf die E-Mail darüber, was sie an diesem Tag getan hat (Sie können sie jederzeit versenden lassen). Sie wollen). Am nächsten Tag sendet iDoneThis eine Übersicht mit diesen Antworten an das gesamte Team.

Es ist fantastisch; Jeder kann die Informationen einsehen, aber wenn etwas Bestimmtes angesprochen werden muss, können die Personen, auf die es sich bezieht, es untereinander klären. Auf diese Weise verschwenden Sie keine Zeit für Unbeteiligte. Diese Personen können dann bei Bedarf ein Update in die E-Mail des nächsten Tages aufnehmen.

Ich fand, dass es für kleinere Teams nicht effizient war. Wir haben es zum Beispiel in meinem 6-köpfigen Team verwendet und waren von der Idee begeistert, stellten aber fest, dass wir neben einem Chat-Client auch einfach ein kurzes tägliches Stand-up haben könnten. Aber für ein großes Team wette ich, dass dies von unschätzbarem Wert sein wird.

Ich denke, es ist immer noch wichtig, gelegentliche Team-Meetings abzuhalten, aber für ein tägliches Update ist dies perfekt.

Es ist nicht kostenlos, aber es kostet nur $5/Mitglied/Monat und ist es meiner Meinung nach wert.

Nebenbemerkung: Dies ist auch großartig, um es nur als Werkzeug für sich selbst zu verwenden (ein "Arbeitstagebuch", wenn Sie so wollen). Für diesen Zweck (1 Person) ist es kostenlos. So benutze ich es jetzt und liebe es.

Meiner Meinung nach kann das 3er-Team sein Scrum-Meeting individuell durchführen. Aber der Scrum Master als gemeinsamer Faktor in allen 3 Meetings kann die Informationen/Abhängigkeiten von einem Team zum anderen weitergeben.

Es gibt zwei Probleme mit dem Problem.

  1. Koordination zwischen mehreren Teams, was mit Scrum of Scrums erreicht werden kann, wie in einigen der Antworten oben besprochen.
  2. Das andere ist, dass das Stand-up-Meeting kurz und knackig gehalten werden sollte, sonst verlieren die Leute mit der Zeit das Interesse. Bei mehreren Teams oder sogar einem Team mit deutlich mehr Personen können Stand Ups mit Hilfe eines Tools effektiv erleichtert werden.

Wizergos ist eine solche Software, die Ihrem Team mit den folgenden Funktionen helfen wird, ansprechendere kurze Stand-ups zu haben.

a. Es ruft die erforderlichen Daten (hauptsächlich erledigte und für das nächste Meeting geplante Aufgaben) für jede Person ab, und die Daten sind für alle Teilnehmer sichtbar. Es ist nur ein menschliches Eingreifen erforderlich, wenn jemand auf irgendetwas blockiert ist.

b. Es erstellt am Ende das automatisierte Protokoll. Jeder Teilnehmer wird mit dem zusammengefassten Protokoll benachrichtigt. Auch der Scrum Master erhält die Liste der blockierten Elemente.

c. Ein Timer, um das Meeting rechtzeitig zu beenden.

Mit den oben genannten Funktionen dauert selbst ein Aufstehen für 15 Personen kaum 15-20 Minuten.

Sie können sich registrieren und es für Ihr Team für eine 30-tägige kostenlose Testphase verwenden.

Tägliches Stand-up mit mehreren Scrum-Teams
AntwortenHierDatenschutz-Bestimmungen1y, 0v