Mir ist (in unserem Unternehmen) aufgefallen, dass Scrum Master einen der Ansätze haben:
Beginnen Sie mit Metriken und arbeiten Sie an der Verbesserung der Zahlen: Wenn beispielsweise während des Sprints eine neue User Story auftaucht, lehnt das Team sie möglicherweise ab, weil sie die Geschwindigkeit beeinflusst. Der Entscheidungsprozess konzentriert sich also auf die Metriken und darauf, wie diese Maßnahmen die Metriken und die Teamleistung beeinflussen.
Beginnen Sie mit dem Wert und konzentrieren Sie sich auf die Wertsteigerung: zB kommt eine neue User Story in den Sprint, wie wichtig ist diese User Story für das Produkt (oder wertvoll) => die Entscheidung wird ausschließlich auf dieser Grundlage getroffen. Betroffene Metriken sind irrelevant, solange Sie wissen, warum das Delta auftritt.
Beginnen Sie mit dem Prozess und konzentrieren Sie sich auf die Prozessverbesserung: Wenn beispielsweise eine neue User Story auftaucht, wird das Aufstellen während des Sprints den Sprint stören und wahrscheinlich die Leistung insgesamt verringern, sodass das Team beschließt, sie wegzulassen (selbst wenn die Story das Produkt verbessern würde). Wert) und im nächsten Sprint erledigen.
Meine Teams und ich kombinieren 2 & 3 (wenn der Wert hoch ist, fügen wir ihn dem Sprint hinzu). Aber ich habe zum Beispiel oft einen Fokus auf 1 gesehen.
Daher meine Frage: Worauf konzentriert ihr euch? Wie treffen Sie Entscheidungen, und was sind Ihrer Meinung nach die Nachteile, wenn Sie sich nur für das eine oder andere entscheiden?
Ich werde dies allgemeiner beantworten, weil ich kein agiler Typ bin. Sie treffen mit den Konzepten der Metriken auf ein systemisches Problem, und das heißt, Sie können am Ende das falsche Verhalten belohnen und fördern, während Sie das gewünschte Verhalten auslöschen. Unsere Kultur, zumindest in den USA, ist sehr "ergebnisorientiert". Wenn Sie nur diese Ergebnisse haben, ist das, was Sie zu tun versucht haben, eine irrelevante Mentalität, dann landen Sie bei Ergebnistypmetriken, und die Verhaltensweisen, die Sie dorthin bringen, werden sich durchsetzen, und das Risiko könnte ein Verhalten sein, das Sie beschrieben haben, oder noch schlimmer, z. B. etwas Illegales.
Meiner Ansicht nach ist es sehr kurzsichtig, Ihre Metriken so zu erstellen. Das soll nicht heißen, dass es einige Metriken für Ergebnistypen geben sollte, aber ich denke, es sollte auch andere Metriken geben, die auf das Verhalten getestet werden.
Aus meiner Sicht sind Prozess und Wert miteinander verbunden. Wenn Ihr Prozessansatz also eine kontinuierliche Verbesserung, ständiges Lernen usw. ist, dann wird der Wert für das Produkt, das für den Kunden hergestellt wird, meiner Meinung nach maximiert. Um Ihre Frage zu beantworten, wäre mein Fokus eine Kombination aus Ihrer 2 und 3, vielleicht mit mehr Fokus auf 3 zuerst mit der Annahme, dass der Wert folgt.
Dies ist eine große Frage, da es kein ungewöhnliches Anliegen ist.
Was sind Metriken? Eine Möglichkeit, etwas zu messen. Natürlich müssen sie wertvoll sein; Wenn nicht, hören Sie auf, sie zu sammeln. Wenn Metriken die Grundlage für Teamentscheidungen sind, dann gibt es eine Chance für Verbesserungen. Das ist ein Warnsignal dafür, dass die Prioritäten für das Unternehmen und/oder das Team nicht dort sind, wo sie sein sollten. Denken Sie an das Manifest: „Funktionierende Software ist das wichtigste Maß für Fortschritt.“
Was ist ein Sprint? Ein zeitlich festgelegtes Ereignis, um Fokus zu schaffen und das Risiko zu begrenzen. Wenn besonders regelmäßig neue Arbeiten zwischengeschaltet (oder sogar für eine Injektion in Betracht gezogen) werden, gibt es Bedenken. Wie konzentriert sich das Entwicklungsteam auf die Prognose und das Sprint-Ziel aus dem Sprint-Planungsereignis? Wie wirkt sich das auf das Risiko aus?
Was sagt der Scrum Guide über die Änderung des Sprint Backlogs während des Sprints?
Sobald das Product Backlog in der Sprint-Planung festgelegt ist, sollten im Idealfall nur Elemente hinzugefügt oder entfernt werden, die sich auf das Sprint-Ziel beziehen und die Qualität des Inkrements nicht beeinträchtigen.
Wenn etwas wirklich so kritisch ist, dass es eine Änderung des Plans rechtfertigt, müssen Faktoren berücksichtigt werden.
Da jeder Sprint weniger als einen Monat lang ist, gibt es im Allgemeinen keinen großen Wertverlust, wenn Sie ihn zum höchsten Eintrag im Product Backlog machen, um ihn in den nächsten Sprint aufzunehmen. Vielleicht ist noch mehr Verfeinerung erforderlich, damit es bereit ist, also denken Sie daran, dies bei der Anpassung des aktuellen Sprints zu berücksichtigen.
Der Product Owner ist der einzige, der einen Sprint abbrechen kann. Das Scrum Team soll sich selbst organisieren, also redet mit. Verstehen Sie alle Risiken sowohl für die aktuellen Sprint-Elemente als auch für das neue Element. Störungen betreffen das Produkt und die Personen. (siehe „Agile Prozesse fördern nachhaltige Entwicklung.“)
Ganz allgemein zum Titel des Beitrags: Verbesserung (Produkt, Lernen, Prozesse) ist wichtiger als Metriken.
Als Scrum Master liegt mein Fokus darauf, dem Team zu helfen, sich zu verbessern.
Jedes Team ist anders. Einige konzentrieren sich gerne auf Metriken. Andere setzen sich leidenschaftlich für den Geschäftswert ein.
Meine Aufgabe ist es, ihnen zu helfen, mit den von ihnen gewählten Tools oder Ansätzen erfolgreich zu sein. Gegebenenfalls biete ich ihnen auch Alternativen an, aber es kommt immer auf die Entscheidung des Teams an.
Sarow
David Espina