Wie kann man ein Scrum of Scrums-Meeting kurz und effizient halten, wenn man bedenkt, dass die Berichterstattung über nicht-technische Probleme lange dauern kann?

Wir führen ein Projekt mit einem Team von rund 60 Personen mit Scrum durch. Die Hälfte des Teams berichtet an einen Projektleiter; die Hälfte an einen anderen Projektleiter. Diese 2 Projektmanager treffen sich mit dem Testleiter und dem Programmmanager in einem täglichen Scrum of Scrums (SoS). Da dies neu ist, gibt es einige Bedenken, den SoS kurz und effizient zu halten.

Ich habe mehrere gute Artikel zum Thema SoS gelesen, aber die meisten konzentrieren sich auf die technische Integration zwischen den Scrum-Teams über das SoS . Was ist mit dem Melden von nicht technischen Problemen und Status während des SoS?

Insbesondere sind die Projektmanager nicht technisch versiert (und der Programmmanager auch nicht). Wie detailliert sollte der (nicht-technische) Bericht im SoS sein und wie können wir diesen kurz und effizient halten?

@Balinjdl, Willkommen bei PMSE. Dies könnte für die Hauptseite besser geeignet sein. Aber es muss noch verfeinert werden. Wie es derzeit geschrieben steht, handelt es sich um eine Umfragefrage. Was ist die spezifische Herausforderung, die Sie angehen möchten, damit es besser passt (und um besseres Feedback zu erhalten)? Wäre es richtig, Ihre Frage so umzuformulieren, wie Sie einen SoS kurz und effizient halten können, da die Berichterstattung über nicht-technische Probleme in einem Meeting lange dauern kann?
@MarkPhillips Ja, das wäre richtig. Ich interessiere mich hauptsächlich für die nicht-technische Seite des SoS, da die Projektmanager (in diesem Beispiel) nicht technisch sind. Danke für den Vorschlag und das Willkommen!
Hallo Balinjdl, ich habe die Umfrage bearbeitet, um sie zu eliminieren und mich auf die Vorschläge von Mark zu konzentrieren. Bitte zögern Sie nicht, weiter zu bearbeiten, wenn meine Änderungen den Geist Ihrer Frage verfehlen. :) Hoffe das hilft!
Beim Nachdenken über die Frage kommt mir ein Punkt in den Sinn, was (wenn überhaupt) während des Meetings als „Meeting-Protokoll“ aufgezeichnet werden sollte? Zeichne ich die abgeschlossenen, geplanten und Hindernisinformationen, nur die Hindernisinformationen oder eine Teilmenge für jedes Meeting auf? Oder zeichne ich nichts auf (obwohl eine schriftliche Aufzeichnung für die Teilnehmer hilfreich wäre)? Soll ich eine neue Frage erstellen oder die vorhandene Frage überarbeiten, um dies klarer zu formulieren?
@balinjdl Sie haben bereits mehrere Unterfragen in dieser Frage. Ich denke, Ihre Fragen zum Treffen von Artefakten sollten auf jeden Fall getrennt werden.

Antworten (3)

So halten Sie sich kurz: Verbreiten Sie keinen Status oder lösen Sie keine technischen Probleme. Mach das danach.

Mit 60 Personen in Ihren Scrum-Teams hätten Sie wahrscheinlich zwischen 7 und 10 Teams, die sich alle einzeln treffen. Es wäre für Ihre beiden Projektmanager unmöglich, an allen Daily Scrums teilzunehmen, und Sie sollten darauf vertrauen, dass die Entwicklungsteams Sie nach dem Meeting auf die relevanten Informationen aufmerksam machen.

Daily Scrum – Der Zweck dieses Meetings besteht darin, dass das Entwicklungsteam (3-9 Personen) zusammenkommt und versteht, was es noch zu tun hat, und seinen Plan aktualisiert. Es ist wirklich nicht erforderlich, dass ein Projektmanager am Daily Scrum teilnimmt, außer als Beobachter, und alle Informationen, von denen das Entwicklungsteam glaubt, dass sie entweder dem Scrum Master oder dem Product Owner zur Kenntnis gebracht werden müssen, sind ihre Sache.

Scrum of Scrums – Jedes Entwicklungsteam sollte einen Vertreter wählen, der am Scrum of Scrums teilnimmt, damit dieselben Informationen zwischen den Entwicklungsteams weitergegeben werden können, damit sie Abhängigkeiten minimieren und sicherstellen können, dass alle Entwicklungsteams ihre gesamte Arbeit integriert haben und bis zum Ende des Sprints getestet. Auch hier geht es um die Entwicklungsteams selbst und nicht um das Projektmanagement.

Abgesehen von diesen beiden spezifischen Instanzen können Sie so viele andere Treffen haben, wie Sie möchten.

Die Sache ist, dass das Scrum-Meeting nicht technisch sein sollte . Es gibt ein Treffen namens Community of Practice (CoP) und dieses Treffen ist für die Scrum-Teams, um über technische Probleme zu sprechen. Wenn Sie also die technischen Diskussionen aus dem Scrum oder Scrum-of-Scrums heraushalten können, werden Ihre Manager in Ordnung sein. Es liegt am Scrum Master und wie er andere bei diesen Meetings betreut.

In der Organisation (>500) eines Freundes von mir gibt es ein wöchentliches SoS für organisatorische Fragen und ein CoP für technische Fragen. Sie sind sehr glücklich über dieses Setup, weil es für sie funktioniert. Manager gehen zum SoS, Tech-Leads zum CoP. Product Owner gehen zu beiden.

Mike Cohn über Praxisgemeinschaften .

Geben Sie während Scrum-of-Scrums keine Berichte ab

Ihre Frage hat einen großartigen Titel, der bereits den Kern Ihrer Antwort enthält, aber ich denke, der Hauptteil Ihrer Frage verschleiert das Problem. Sie fragen (Hervorhebung von mir):

Wie kann man ein Scrum of Scrums-Meeting kurz und effizient halten, wenn man bedenkt, dass die Berichterstattung über nicht-technische Probleme lange dauern kann?

Sie haben genau Recht: Die Berichterstattung (technisch oder anderweitig) kann viel Zeit in Anspruch nehmen, und die Berichterstattung im Vorfeld ist nicht die Absicht eines agilen Meetings. Das soll nicht heißen, dass agile Praktiken dem Reporting per se widersprechen , aber dass agile Frameworks wie Scrum darauf abzielen, den Projektstatus für alle Interessierten durch Artefakte wie Burndown-Diagramme, Produkt- und Sprint-Backlogs und Teammanagement leicht sichtbar zu machen Prozesse wie Storyboards im Kanban-Stil.

Das Scrum-of-Scrums ist ein Treffen zur Koordination von Abhängigkeiten zwischen Teams. Wenn jemand während des Meetings den Status zieht oder drückt (ja, pusht ; ich habe das gesehen), wird der Prozess falsch angewendet.

Wie kann man ein Scrum of Scrums-Meeting kurz und effizient halten, wenn man bedenkt, dass die Berichterstattung über nicht-technische Probleme lange dauern kann?
AntwortenHierDatenschutz-Bestimmungen1y, 0v