Darf der Product Owner beim Daily Scrum Event dabei sein?

Product Owner sind stille Beobachter bei täglichen Stand-Ups

In der zitierten Beschreibung hat das Wort teilnehmen die Konnotation von "aktiv teilnehmen". Der Product Owner sollte teilnehmen, aber nicht teilnehmen. Das Daily Stand-up ist als Synchronisations- und Abstimmungsmeeting gedacht, nicht als Statusmeeting, und der Product Owner hat darin keine aktive Rolle zu spielen.

Der Product Owner (PO) kann gerne teilnehmen, um zuzuhören und zu beobachten , da Scrum-Prozesse immer transparent sein sollten, der PO jedoch nicht interagieren darf. Zuhören, wenn das Team die Tagesarbeit plant, dient mehreren Zwecken:

• Es bietet einem aufmerksamen Zuhörer viele der gleichen Vorteile wie ein formeller Status-Pull, ohne störend zu sein.
• Es liefert dem PO frühzeitiges Feedback zum Umfang, das außerhalb des Standups verwendet werden kann, um den Umfang laufender User Stories auszuhandeln, Input für die Backlog-Verfeinerung bereitzustellen oder als „Frühwarnsystem“ zu fungieren, das eine vorzeitige Beendigung sein kann erforderlich.
• Es bietet dem PO einen direkten Überblick über die tägliche Kapazität des Teams. Dies ist oft hilfreich, um Erwartungen während der Sprint-Planung festzulegen, und kann erweitertes Wissen darüber liefern, welche Storys im nächsten Sprint priorisiert werden sollten.
• Es schafft einen gemeinsamen Kontext, sodass alle Diskussionen zwischen dem Entwicklungsteam und dem Product Owner während des Sprints nicht bei Null beginnen müssen.

Ja, Sie möchten Ihre PO unbedingt beim Daily Scrum haben.

Denken Sie zunächst daran, dass der Scrum Guide ungefähr 17 Seiten umfasst und nur die breitesten Pinselstriche abdeckt.

Der Product Owner ist Teil des Teams. Sie sind die direkte Verbindung zum Unternehmen und die Person, die Geschichten als erledigt abzeichnet. Sie wollen unbedingt, dass die PO dort ist, damit sie wissen, was los ist.

Die Absicht des Scrum Guides besteht allgemein darin, dass nur die Entwickler sprechen und der PO Fragen bis nach dem Standup zurückhält. Die meisten agilen Lehrer empfehlen, dass der PO während des Standups nur kurze Fragen stellt, um Dinge zu klären. Wenn eine Story fertig ist, kann der PO nach dem Daily Scrum mit dem Teammitglied Kontakt aufnehmen, um die Story zu genehmigen, damit sie ordnungsgemäß erledigt werden kann.

Interessanterweise hat Mike Cohn in seinen direkten E-Mail-Briefen an Abonnenten einige Ratschläge dazu gegeben. Er empfiehlt allen, einschließlich Scrum Master und Product Owner, Updates im Daily Scrum zu geben. Es ist eine Weiterentwicklung unseres Denkens, das anerkennt, dass während eines Sprints neben der Codierung noch andere Aufgaben anfallen.

Und denken Sie daran, es ist alles Führung. Wenn es für Sie funktioniert, ist das der wichtigste Maßstab dafür, ob Sie es tun sollten.

BEARBEITEN: Ich bin dabei, die Zertifizierung zum Certified Scrum Trainer zu erhalten. Also erkläre ich das aus dieser Perspektive. Der Scrum Guide ist ein Framework. Es ist keine Vorschrift, es ist eine Richtlinie. Es ist auch ein sich ständig weiterentwickelndes Konzept. Das letzte Mal wurde es vor mehr als drei Jahren aktualisiert, und Jeff Sutherland, einer der Autoren, hat seine Meinung sicherlich immer weiter entwickelt.

Wenn Ihnen also jemand sagt „Sie halten sich nicht an Scrum“, dann sind sie es, die das Problem haben. Ein 17-seitiges Dokument kann und sollte niemals das A und O sein.

Product Owner sollten unbedingt beim Daily Scrum dabei sein. Jeder CST, den ich kenne, lehrt das. Die genaue Rolle des PO beim Daily Scrum liegt im Ermessen des Teams, basierend darauf, was seiner Meinung nach funktioniert. Erinnern, prüfen und anpassen. Wir halten nicht starr, wir tun, was funktioniert.

Also, wenn ich Ihr Trainer wäre, würde ich Ihnen sagen, dass Sie mit dem "nach dem Buch" beginnen sollen, das nur die Entwickler sprechen. Entscheiden Sie dann anhand Ihrer Retrospektiven, ob das funktioniert.

Ein paar andere Anmerkungen: - Jeff Sutherland und Ken Schwaber pflegen den Scrum Guide. Sie sind nur zwei Stimmen in der Scrum-Community und nicht die einzigen, die dabei waren, als es erfunden wurde.
- Das Agile Manifest ist nicht Scrum und es ist die übergreifende Leitlinie für uns alle. Inspect and Adapt ist ein Schlüsselprinzip. Ebenso wie Einzelpersonen und Interaktionen über Prozesse und Tools.

Ich habe meine CSM-Zertifizierung vor ein paar Wochen erhalten. Eine der paar Fragen, die ich verpasst habe, war genau diese.

Die Frage fragt nach dem Grund, warum der PO am Daily Scrum teilnehmen sollte (was nach Modus Ponens impliziert, dass der PO am Daily Scrum teilnehmen sollte ).

Ich antwortete, dass es darum ginge sicherzustellen, dass das Dev-Team immer noch auf Kurs ist, um die Sprint-Ziele zu erreichen . Ein Zuhörer, wie CG sagt (+1!).

Ich war überrascht zu erfahren, dass die richtige Antwort darin bestand , die Anforderungen zu klären , was impliziert, dass der PO während des Daily Scrum eine aktive Rolle spielt . Stelle dir das vor.

Alles in allem solltest du dich an das halten, was Joel BC (+1!) sagt: Tu, was immer für dich funktioniert .

Ich denke, der Scrum Guide sieht das tägliche Scrum als etwas für das Entwicklungsteam, da dies sie dazu ermutigt, ihre Aktivitäten während des Sprints zu synchronisieren. Es sind jedoch auch Elemente der Synchronisierung zwischen dem Entwicklungsteam und dem Product Owner erforderlich.

Mike Cohn spricht über den Product Owner, der am Daily Scrum teilnimmt, um hervorzuheben, dass er nur ein weiteres Mitglied des Scrum-Teams ist .

Ich persönlich würde sagen, dass es keine gute Idee ist, einen Product Owner zu haben, der nur gelegentlich an einem Daily Scrum teilnimmt. Sie werden den aktuellen Ereignissen ständig hinterherhinken und können daher das Daily Scrum verzögern, indem sie Fragen stellen, auf die der Rest des Entwicklungsteams bereits die Antwort kennt.

Wenn ein Product Owner am Daily Scrum teilnimmt und es als Gelegenheit betrachtet, den Fortschritt zu überprüfen, ist dies ebenfalls keine produktive Nutzung der Zeit des Teams.

Andererseits wäre ein Product Owner, der an jedem Daily Scrum teilnimmt und prägnant und informativ spricht, für das Team von Vorteil.

Stellen Sie sich vor, ein Product Owner hat sich für einen Umzug entschieden und sitzt mit dem Entwicklungsteam zusammen. Würden Sie es ihnen dann verweigern, am Daily Scrum teilzunehmen oder dort zu sprechen? Ich glaube nicht, dass dies eine gute Botschaft über die Zusammenarbeit des Scrum-Teams aussenden würde.

Das Daily Scrum-Meeting sollte in 15 Minuten abgeschlossen sein – maximal 20 Minuten. Wenn der Product Owner (PO) dem Daily Scrum beitritt, schadet dies der Autonomie des Teams und meistens springt der PO ein und sagt „Hey, mach das nicht“ oder „das so“ und dann kann es lang werden Debatten.

Der PO sollte nicht am Daily Scrum beteiligt sein. Lassen Sie Entwickler basierend auf den Beschreibungen der User Stories ihr Bestes geben. Wenn es Blocker gibt, muss der Scrum Master die Diskussion moderieren und kann die PO bei Bedarf in das Daily Scrum ziehen.

Ich bin sehr stark auf der Seite von „ja, die PO sollte am täglichen Standup sein“. Ich denke auch, dass der SM auch da sein sollte. Für die PO habe ich drei Hauptgründe.

1. Sie können sich dann und dort mit Fragen rund um die Priorisierung und Klärung befassen. Dies muss die Timebox respektieren, aber wenn Probleme im Stand-up gelöst werden können, ist es viel, viel effizienter, als weggehen und diese Klärung einholen zu müssen.
2. Der PO kann relevante Updates für das Team haben: Ein Teil der Arbeit des Teams besteht darin, dem PO beim Schreiben der Backlog-Elemente zu helfen. Der PO ist die Stimme des Kunden. Wenn Sie ihn also im Stand-up haben, hat der Kunde eine Stimme in den täglichen Meetings. Und es kann die anderen Zeremonien (Verfeinerung und Planung) machen.
3. Es macht sie zu einem Teil des Teams; Sie tauschen sich regelmäßig mit dem Team aus, was dazu dient, Vertrauen und Kommunikation aufzubauen – ein wichtiger Faktor beim Aufbau guter, leistungsstarker Teams.

Ich weiß, dass der Scrum-Leitfaden sagt, dass sie nicht dort sein sollten; aber das ist ein Bereich, dem ich wirklich nicht zustimme. Allerdings gibt es dafür gute Gründe, die sehr reale Risiken sind, die es zu berücksichtigen gilt. 1. Das Stand-up ist ein Meeting für das Entwicklungsteam; es ist kein Status-Update-Meeting für die PO (oder SM). Im Stand-up besteht die Rolle des PO darin, die Entwickler bei der Bereitstellung des Sprints zu unterstützen. Sie werden etwas über den Fortschritt (und Blocker) erfahren, aber das ist ein Nebenprodukt davon, zu wissen, woran das Team arbeitet, und nicht das Ergebnis einer Statusaktualisierung. 2. Es kann zu ausführlichen Diskussionen kommen, wodurch das Meeting 15 Minuten dauern kann. Es macht mir nichts aus, mir im Stand-up ein wenig Zeit zu nehmen, um Themen zu diskutieren – aber dies muss auch überwacht werden, um sicherzustellen, dass die Timebox eingehalten wird und Themen bei Bedarf für spätere Diskussionen beiseite gelegt werden. 3. Sowohl PO als auch SM leiten mit größerer Wahrscheinlichkeit die täglichen Meetings – um den Ton anzugeben, zu entscheiden, wer spricht, zu detaillierte Gespräche abzubrechen usw. Dies untergräbt das Selbstmanagement. Es ist sehr wichtig, dass die PO diese Rolle nicht übernimmt; Es ist nicht ihr Treffen!

All diese Schwächen sind in einem ausgereiften Team weniger wahrscheinlich und können durch ein gutes SM ausgeglichen werden, das sicherstellt, dass das Standup dem Entwicklungsteam dient. Natürlich ist jedes Team und jede Umgebung anders; Es liegt also wirklich am Team, die richtigen Arbeitsmuster zu finden.