Methoden zur Verbesserung des Daily Scrum / Standup

Sie haben es versäumt zu sagen, ob Ihr Team von Angesicht zu Angesicht oder verteilt arbeitet und über Lync usw. kommuniziert, also gehe ich für diese Antwort davon aus, dass es verteilt ist.

Stufe 1: Grunddisziplin

• Gehen Sie mit dem Product Owner auf eine harte Linie und sagen Sie ihm, dass Sie die Sitzung moderieren und sicherstellen werden, dass sie produktiv ist. Die Aufgabenteilung ist für das Team verwirrend
• Wenn der PO ein Update benötigt, kann er nach dem Stand-up individuell mit den Entwicklern sprechen, aber der Ticket-Tracker (Jira, physisches Board) sollte als Lenkung ausreichen
• Machen Sie das Board mit den Tickets sichtbar (auf dem Bildschirm oder persönlich) und verlinken Sie die Tickets mit dem Entwickler, damit jeder es sehen und sich an seine Teamkollegen binden kann
• Bleiben Sie gesprächig, aber konzentriert (zum Beispiel)

Hallo Dave, wie war dein Tag gestern. Gibt es etwas, worüber Sie das Team auf dem Laufenden halten können? Sie haben an Ticket 267 gearbeitet, richtig? Wie ist es gelaufen? Fantastisch. Machen Sie heute damit weiter oder werden Sie in etwas anderes hineingezogen? OK. Gutes Zeug. Zuletzt; Gibt es irgendetwas, das Sie von mir oder dem Rest des Teams brauchen?

Obwohl diese Art der Interaktion langwierig ist, wird sie viel reibungsloser ablaufen, sobald sich das Team daran gewöhnt hat.

Phase 2: Es zugänglich halten

Denken Sie daran, dass Ihr Ziel darin besteht, ein sich selbst organisierendes Team zu bilden und nicht Zeremonien zu leiten.

• Lassen Sie die Entwickler den nächsten Entwickler als Redner nominieren und fragen Sie, woran sie gestern gearbeitet haben
• Lassen Sie die Leute nicht wirklich aufstehen. Menschen haben Rückenprobleme, Verletzungen, Hüftprothesen und alles Mögliche. Einer meiner Teammitglieder für 62 und hasste Stehen. Natürlich haben wir uns die ganze Zeit bei einem Kaffee hingesetzt
• Stellen Sie sicher, dass die Entwickler unterstützendes Verhalten hervorrufen (Oh, Dave hat Ihnen dabei geholfen, Karen? Großartig. Danke, dass Sie uns das wissen lassen. Großartige Teamarbeit, danke, dass Sie diese Gatekeeping-Aufgabe so schnell erledigt haben usw.)
• Seien Sie bei der Timebox nicht zu streng. Die 15-Minuten-Frist wurde auferlegt, um 40-Minuten-Meetings zu stoppen. Es war nicht darauf ausgelegt, die Leute nach 16 Minuten aggressiv abzuschneiden und sich aufzulösen. Sie haben bereits alle im Gespräch, entlassen Sie einfach diejenigen, die nicht benötigt werden, und setzen Sie es nach eigenem Ermessen fort
• Als ScrumMaster; Bestätigen Sie Ihrem Team auch, was Sie an diesem Tag tun werden
• Stellen Sie sicher, dass Sie das Meeting am Ende oder am Anfang mit einem kleinen Rapport-Builder eröffnen (Hey Team – alle genießen das tolle Wetter? Hat jemand am Wochenende etwas Tolles gemacht? Nein? OK, fangen wir an)
• Stellen Sie sicher, dass Sie das Team während des Stand-Ups über die Kommunikation auf dem Laufenden halten (Hey Team, nur zur Kenntnisnahme aller, die Back-End-Leute aktualisieren möglicherweise heute XYZ, also überprüfen Sie Ihre Posteingänge oder Slack auf die Benachrichtigungen
• Beenden Sie das Meeting mit dem PO (Hallo PO, irgendwelche wichtigen Stakeholder-Nachrichten oder Änderungen, über die Sie das Team informieren müssen, bevor wir brechen?)

Der wichtigste Teil ist immer daran zu denken, dass Ihre Programmierer die Code-Pipeline verwalten; Sie verwalten die Beziehungspipeline. Vergessen Sie Scrum und Stand-up und sprechen Sie einfach mit Ihrem Team, als wären sie Menschen, die an etwas Wertvollem arbeiten; denn genau das sind sie.

Weitere Hinweise und Tipps zum Aufbau eines Teams

• Kümmern Sie sich wirklich um ihre Tagebücher; Fragen Sie, wie viele Besprechungen sie an diesem Tag haben. Fühlen sie sich unter Druck gesetzt oder belastet. Fragen Sie, ob Sie sich einmischen müssen, um etwas zurückzudrängen
• Alle paar Stand-ups werfen eine persönliche Anekdote über Sie oder ein Teammitglied ein, um die Bindung aufzubauen. (Hey, wussten Sie, dass Alice gerade ihre AWS-Prüfung abgeschlossen hat? Das ist großartig. Wir sollten es bei der Überprüfung abholen, um es den Stakeholdern mitzuteilen, aber fürs Erste; gut gemacht)
• Verwenden Sie Humor, um Meetings erträglich zu machen. Ich sehe so viele Teams, die auf dem Todesmarsch in eine Lieferung marschieren. Bei Agile geht es um Flexibilität, aber der traditionelle Aufbau von Projektmanagement-Berichten ist nicht verschwunden. Verbinde dich während deiner Sitzungen wirklich mit Menschen
• Konzentrieren Sie sich auf den Aufbau einer Teamidentität
• Wenn Sie von Angesicht zu Angesicht sind, dann machen Sie die Zeremonie zu einer echten Versammlung; Sagen Sie den Leuten, dass sie 5 Minuten vorher mit der Arbeit aufhören und sich ein Getränk / einen Kaffee usw. für das Aufstehen bereit machen sollen (Nebenbei unterbreche ich auch meine Sprint-Planung mit einer 10-minütigen Pause nach diesem Muster).
• Stellen Sie sicher, dass Ihre Teams die psychologische Sicherheit haben, sich zu äußern (ich tue dies normalerweise, indem ich mich in 25 % der Fälle auf das schüchternste Mitglied des Teams konzentriere und den Satz verwende: „Ich habe nichts dagegen, was Sie sagen, wirklich, sagen Sie uns einfach, was Sie denken . Seien Sie mutig.“ Sobald sie ein Maß an Selbstvertrauen erreicht haben, verlagere ich den Fokus für ein paar Timeboxes auf ein anderes Teammitglied

Da Sie die Frage mit Scrum und Scrum-Master und Daily-Scrum markiert haben , gehe ich davon aus, dass Sie Scrum folgen, wie es im Scrum-Leitfaden definiert ist .

Nimmt der Scrum Master am Daily Scrum teil? Obwohl er kein obligatorischer Teilnehmer ist, besteht einer der Dienste des Scrum Masters darin, „Scrum-Events nach Wunsch oder Bedarf zu moderieren“. Ich würde erwarten, dass ein guter Scrum Master gelegentlich die Daily Scrums beobachtet und, wenn gegen die Regeln des Events verstoßen wird, sich zu Wort meldet und das Event wieder auf Kurs bringt. Ich würde auch erwarten, dass der Scrum Master während der Sprint-Retrospektiven mit dem Entwicklungsteam in Kontakt bleibt, um bei der Ideenfindung zu helfen.

Der Scrum Guide sagt auch, dass eine der Aufgaben des Scrum Masters darin besteht, sicherzustellen, dass niemand außerhalb des Entwicklungsteams, der am Daily Scrum teilnimmt, das Meeting stört. Wenn der Scrum Master als Beobachter am Daily Scrum teilnimmt oder mit dem Entwicklungsteam die Wirksamkeit des Daily Scrum bei Sprint-Retrospektiven nachverfolgt, sollte der Scrum Master von etwaigen Störungen erfahren. Hat das Team ein 15-Minuten-Zeitfenster, um das Daily Scrum durchzuführen? Empfindet das Team die Fragen des Product Owners als störend? Wenn das Team sein Daily Scrum in einer 15-Minuten-Timebox beendet, spricht nichts dagegen, zusätzliche Zeit nach dem Event zu verbringen. Tatsächlich sagt der Scrum Guide, dass es für Teammitglieder (bezogen auf das gesamte Scrum-Team, nicht nur das Entwicklungsteam) üblich ist, „

Es ist auch wichtig zu erkennen, dass das Daily Scrum nicht im Format „drei Fragen“ sein muss. Der Scrum Guide sagt sogar, dass "einige Entwicklungsteams Fragen verwenden werden, andere mehr auf Diskussionen basieren". Unabhängig vom Format besteht der Zweck jedoch darin, in kurzen Abständen zu überprüfen, wie der Fortschritt im Hinblick auf das Erreichen der Sprint-Ziele konkurriert, Anpassungen vorzunehmen, um die Wahrscheinlichkeit zu erhöhen, dass die Sprint-Ziele erreicht werden, und dem Product Owner Bedenken hinsichtlich des Sprints zu melden Es besteht die Gefahr, dass Ziele daran arbeiten, Änderungen vorzunehmen, um sicherzustellen, dass am Ende des Sprints ein wertschöpfendes, potenziell veröffentlichbares Inkrement verfügbar ist. Der Scrum Master kann das Entwicklungsteam in verschiedenen Methoden coachen, aber das Entwicklungsteam sollte letztendlich die Ausführung des Daily Scrum vorantreiben.

Der einzige Punkt, der bei der Moderation des Events und dem Coaching der Scrum-Regeln durch den Scrum Master nicht angesprochen wird, ist, dass die Mitglieder des Entwicklungsteams nicht wissen, was sie als nächstes tun werden. Die Prioritäten der Arbeit sollten vom Sprint-Ziel und den Wert- und Ordnungsattributen bestimmt werden, die den in den Sprint eingebrachten Product-Backlog-Einträgen zugewiesen werden. Das Sprint Backlog enthält zerlegte Product Backlog Items, aber die gesamte zerlegte Arbeit sollte an ein oder mehrere Product Backlog Items (mit einem Wert und einer Reihenfolge) gebunden sein und möglicherweise eine technische Abhängigkeit haben. Es sollte für das Team trivial sein zu bestimmen, woran es als nächstes arbeiten sollte, sobald es ein Element aus dem Sprint Backlog abgeschlossen hat.

Negatives Verhalten hat im Allgemeinen verschiedene Gründe. Während Ihre Aufgabe als Scrum Master darin besteht, die Scrum-Zeremonien zu moderieren, sollte Ihr Ziel darin bestehen, das Team in eine Position zu bringen, in der Sie im Wesentlichen überholt sind.

1. Verstehen

Ermitteln Sie die Ursache für dieses Verhalten. Es kann Faulheit/Bequemlichkeit sein (warum ein weiteres Treffen vereinbaren, wenn Sie Ihr Problem jetzt besprechen können?). Es könnte sich um einen Bedarf handeln, der ansonsten nicht erfüllt wird (unzureichende Sichtbarkeit der Fortschritte, tatsächliche oder wahrgenommene Schwierigkeiten, Probleme mit anderen zu besprechen). Es könnte Angewohnheit sein (PO war früher ein PM und nach dem Status zu fragen, ist das, was er gewohnt ist. Oder das Team hatte früher regelmäßige monolithische Meetings, bei denen alles zusammen gehasht wurde).

2. Unterstützung

Erfahren Sie, was Sie tun können, um bei entdeckten Problemen zu helfen. Vielleicht muss sich jemand wohler fühlen, wenn er andere Teammitglieder um Hilfe/Feedback bittet. Vielleicht würde die Verlegung des Standups auf einen späteren Zeitpunkt allen ermöglichen, sich morgens zu orientieren. usw.

3. Erziehen

Bitten Sie Ihre Teamkollegen höflich, ihre Beiträge kurz zu halten und alles, was über das Wesentliche hinausgeht, hinterher mit wem auch immer es betrifft, zu besprechen. Weisen Sie den PO darauf hin, dass er nach dem Meeting den Fortschritt auf dem Board sehen kann. Versuchen Sie, das Team dazu zu bringen, die Probleme selbst zu lösen.

4. Führer

Wenn all dies fehlschlägt, sollte der Scrum Master eingreifen und die Zeremonien genauer lenken, bis sich das neue Muster verwurzelt hat. Schneiden Sie Tangenten ab, indem Sie sie genauer durch die drei Fragen führen. Unterbrechen Sie den PO, wenn er sich einmischt, oder laden Sie ihn sogar aus, wenn das Verhalten anhält. Führen Sie kleine Bußgelder für Teammitglieder ein, die unvorbereitet ankommen. Mein Scrum Coach erzählte mir, dass er einmal ein Team mit einem schwerwiegenden Handyproblem hatte. Also nahm er etwas Malerband und zeichnete Parkplätze auf einen Tisch. Jeder konnte seine Telefone frei aufstellen. Aber jeder, der beim Telefonieren erwischt wurde oder sein Telefon klingelte, musste 5 Dollar in die Kaffeekanne stecken.

Ich werde Ihre Bedenken der Reihe nach ansprechen. Ich sehe hier mehrere mögliche zugrunde liegende Probleme. Diskutieren Sie wie immer mit dem Team in der Retrospektive , um die zugrunde liegenden Ursachen zu ermitteln und Lösungen zu vereinbaren !

Sie neigen dazu, vom Thema abzukommen, anstatt sich auf das zu konzentrieren, was ich getan habe, was ich tun werde, und auf Hindernisse

Wie andere gesagt haben , muss das Daily Scrum nicht im Drei-Fragen-Format sein. Der Zweck des Treffens besteht darin, dem Team zu dienen. Wenn das Team das Gefühl hat, dass es dieses Format nicht braucht, dann kümmern Sie sich nicht darum.

Es ist jedoch ein Problem, wenn das Meeting vom Thema abweicht, vorausgesetzt, dass die „off-topic“-Diskussionen nicht für das gesamte Team nützlich sind . Ich habe es häufig erlebt, dass 2-4 Entwickler mit einem Nebenthema beschäftigt sind, während alle anderen desinteressiert dasitzen, aber nicht unterbrechen wollen. Ein Ansatz, den ich mag, ist, jemanden die Hand heben zu lassen, wenn er das Gefühl hat, dass ein diskutiertes Thema für ihn nicht relevant ist. Sobald Sie 2 Hände hoch (oder 1 oder 3 usw., abhängig von Ihrem Team) erreichen, wird die Diskussion angehalten und nach dem Meeting nur unter den Beteiligten fortgesetzt.

Der Product Owner spricht während oder direkt nach dem Daily Scrum mit ihnen und bittet sie um „Updates“.

Dies ist nicht der Zweck des Daily Scrum. Der Scrum Master (SM) muss den Product Owner (PO) darüber aufklären. Dies kann jedoch mehrere Ursachen haben.

1. Die PO ist sich einfach nicht bewusst, dass dies schädlich ist. Lösung: Aufklärung des PO.
2. Die Informationen, die der PO benötigt, sind in einem Informationsstrahler wie dem Sprint Board nicht verfügbar. Lösung: Stellen Sie sicher, dass Sie einen Informationsstrahler haben, stellen Sie sicher, dass der PO Zugriff darauf hat, und stellen Sie sicher, dass er die Informationen enthält, die der PO benötigt.
3. Der PO ist sich nicht bewusst, dass sich die Informationen, die er/sie benötigt, auf dem Informationsstrahler befinden. Lösung: Aufklärung des PO.
4. Die Informationsbedürfnisse des PO sind so komplex/einzigartig, dass sie nicht auf den Informationsstrahler gehen können. Lösung: Finden Sie ein weniger störendes (für das Team) Mittel, um diese Informationen an die Bestellung weiterzugeben. Vielleicht spricht der PO privat nur mit denen, von denen er/sie Informationen benötigt?

Sie wissen oft nicht, was sie tun werden ... dh sie können die Frage während des Daily Scrum nicht beantworten, also sagen sie, dass sie nach dem Daily Scrum entscheiden werden, was zu tun ist.

Die Tatsache, dass das Team vor dem Meeting nicht weiß, was es tun wird, es aber unmittelbar danach tut, deutet für mich auf mehrere mögliche Probleme hin.

1. Dem Team bleibt vor dem Daily Scrum nicht genug Zeit, um sich zu orientieren. Lösung: Verschieben Sie das Meeting auf einen späteren Zeitpunkt am Tag.
2. Das Team hat einfach keine Lust dazu. Lösung: Informieren Sie das Team über die Risiken, wenn der Rest des Teams nicht weiß, was die einzelnen Teammitglieder tun. Hinweis: Stellen Sie zunächst sicher, dass Risiken für Ihre Situation bestehen ! Wenn nicht, dann ist das Problem:
3. Die Frage selbst ist für das Team nicht nützlich. Lösung: Hör auf zu fragen!
4. Das Team hat Angst. Sie fühlen sich nicht sicher genug, um die Frage zu beantworten. Dies ist das gefährlichste Problem und am schwierigsten, das Team dazu zu bringen, es zuzugeben. Vielleicht haben sie Angst, dass sie, wenn sie anfangen, an Aufgabe A zu arbeiten, und bei Aufgabe A etwas herauskommt, irgendwie bestraft werden. Es ist besser, die Tatsache zu verbergen, dass sie überhaupt an Aufgabe A arbeiten ... Lösung: Finden Sie heraus, warum sich das Team unsicher fühlt, und beheben Sie das Problem. Dies ist an sich schon ein bedeutendes Unterfangen, aber von entscheidender Bedeutung.

Das sind nur die möglichen Ursachen, die mir auf Anhieb eingefallen sind. Es ist durchaus möglich, dass die Ursachen in Ihrer Situation anders sind. Deshalb ist es wichtig, Ihre Bedenken in der Retrospektive vorzubringen. Dafür ist es da!