Unsere beiden Scrum-Entwicklungsteams befinden sich in Indien. Unser Shared Product Owner zieht dauerhaft in die USA um und wir stehen kurz vor dem Abschluss unseres ersten Sprints. Er und das Team schlugen vor, den nächsten Sprint um eine Woche zu verschieben, während er unterwegs ist. Der Rhythmusverlust des Teams beunruhigt mich ebenso wie der Verstoß gegen eine der Grundregeln von Scrum.
Ich bin kein Teil der Scrum-Teams, aber ich bin ein zertifizierter ScrumMaster und habe im Laufe der Jahre viel von dieser Seite gelernt, sodass ich als agiler Coach innerhalb der Organisation agiere.
Also wollte ich vorschlagen, dass sie trotzdem einen weiteren Sprint machen, sich aber nur auf technische Schulden konzentrieren und so tun, als würden sie einen Sprint machen, bei dem sie sich auf null Story Points festgelegt haben. Ich weiß, dass das Verzögern eines Sprints in Scrum laut Scrum Guide nicht empfohlen wird , aber sich weniger zu verpflichten, damit das Team technische Schulden lösen kann, wird in einigen Materialien empfohlen, die ich gelesen habe.
Der Product Owner zieht es vor, dass das Team nicht an Product-Backlog-Einträgen arbeitet, bis er das Backlog weiter pflegen kann. Wir hatten geplant, ein Meeting zur Verfeinerung des Product Backlogs durchzuführen, stellten jedoch fest, dass die Arbeitsbelastung des PO diesmal zu hoch war. Besteht also eine Gefahr darin, sich auf null Story Points festzulegen, aber den Sprint so zu laufen, als wäre es ein echter Sprint?
Aus meiner Erfahrung ist es normalerweise kein allzu großes Problem, sich eine Woche frei zu nehmen und an anderen Dingen zu arbeiten. Oft haben die Entwickler dann ihre eigene Zeit, um an ihrem Lieblingsprojekt zu arbeiten. Zu anderen Zeiten ist es um die Thanksgiving-Feiertage oder die Weihnachts-/Neujahrsferien herum, also ist ein großer Teil des Teams sowieso unterwegs.
Was ist Ihre normale Sprintlänge? Wenn es eine Woche ist, dann erscheint es vernünftig, eine Woche im Sprint zu arbeiten. Wenn Sie normalerweise längere Sprints haben und diesen eine Woche lang laufen möchten, warne ich davor. Wie Sie bereits erwähnt haben, gibt es einen Rhythmus für einen Sprint. Wenn du eine Woche Pause vom Sprinten machst, ist es, als ob du auf Pause drückst und dann wieder spielst, wenn du wieder aktiv bist. Das Ändern der Sprintlänge ist eher wie das Ändern dessen, was Sie spielen, oder zumindest das Ändern der Temperatur dessen, was Sie spielen.
Wenn Sie nun einwöchige Sprints haben und an technischen Schulden gearbeitet werden muss, klingt das nach einer guten Option. Ich würde fragen, warum Sie nicht dem Standardprozess folgen würden? Was ich damit meine ist, schreiben Sie die technische Schuld in Wert für das Entwicklungsteam auf (was natürlich auch für den Endkunden einen Wert hat, auch wenn er es nicht so leicht sehen kann). Wenn Sie die technischen Schulden wie Geschichten behandeln, hilft dies sicherzustellen, dass das Team alle seine Standardpraktiken befolgt und hoffentlich zu qualitativ hochwertigen Ergebnissen führt.
Ich denke, es ist auch wichtig sicherzustellen, dass der Product Owner versteht, dass er auch Verpflichtungen gegenüber dem Team hat. Wenn er möchte, dass sich das Team dazu verpflichtet, geplante Features bis zum Ende des Sprints zu liefern, muss er sich auch dazu verpflichten, das Team mit qualitativ hochwertigem Input aus dem Sprint zu versorgen – seine Anforderung.
Ich denke also, das Team könnte selbst entscheiden, je nachdem, wie viel Vertrauen es hat und wie gut die Beziehung zum Product Owner ist, ob es weitermachen und einen neuen Sprint mit technischer Forschung beginnen oder was auch immer es verwenden möchte die Zeit vertreiben oder einfach eine Woche lang entspannen und das Leben genießen. Aber beim nächsten retrospektiven Meeting mit dem Product Owner müssen sie sowieso eine ernsthafte Diskussion mit dem Product Owner führen, wie sie sicherstellen können, dass das Team genug Input bekommt, auch wenn der Product Owner auf Reisen ist.
Ich bin überrascht, dass Ihr Product Owner keinen weiteren Sprint machen wollte. Im Allgemeinen neigen Product Owner dazu, die Entwicklungsteams dazu zu drängen, Releases eher früher als später herauszubringen. Sie sind immer mit externen Treibern konfrontiert, wie z. B. der Markteinführung auf einer Messe oder dem Schlagen eines Konkurrenten auf dem Markt.
Ihr Bauchgefühl geht jedoch in die richtige Richtung. Ja, Sie sollten aus folgenden Gründen einen weiteren Sprint machen:
Um den Rhythmusverlust zu vermeiden, wie Sie zu Recht erwähnt haben.
Noch wichtiger ist, dass Sie durch das Überspringen eines Sprints die falsche Botschaft über die Wichtigkeit dieses Projekts, Fristen usw. an das Team senden.
Dieser Sprint kann eine Mischung sein aus:
Auflösung technischer Schulden.
Durchführung von Forschungsarbeiten zu vorrangigen Geschichten, die wahrscheinlich in den kommenden Sprints geplant sind. Dies gibt dem Entwicklungsteam die Möglichkeit, die Entdeckung durchzuführen oder tatsächlich einen Proof-of-Concept zu erstellen, damit es besser in der Lage ist, die Stories zu dimensionieren und das Risiko zu minimieren, wenn sie tatsächlich geplant sind.
Außerdem ist es nicht erforderlich, null Punkte zu machen. Wenn etwas Arbeit erledigt wird, erfordert es Anstrengung, und damit sind Story Points verbunden. Also, machen Sie weiter und setzen Sie Story Points. Auf den Forschungsgeschichten ziehen es manche Leute vor, eine Zeitbox anstelle von Story Points zu setzen.
In Ihrem speziellen Fall wäre es am besten, die Woche als Belastung für die Produktivität zu behandeln. Dies wirkt sich nicht wirklich auf die Teamgeschwindigkeit aus, wenn Sie nicht mit Sprintlängen jiggern. Es wirkt sich als sichtbarer Kostenfaktor in der Release-Planung Ihres Projekts aus, indem es die Anzahl der in Ihrem aktuellen Zeitplan verbleibenden Sprints in voller Länge reduziert. Dies ist eine gute Sache™, weil es die Realität des Projekts widerspiegelt.
Ist es in Ordnung, einen Sprint zu haben, bei dem sich das Team zu null Story Points verpflichtet?
Ja, aber Ihre eigentliche Frage ist etwas anderes. :)
Der Product Owner zieht es vor, dass das Team nicht an Product-Backlog-Einträgen arbeitet, bis er das Backlog weiter pflegen kann. Wir hatten geplant, ein Meeting zur Verfeinerung des Product Backlogs durchzuführen, stellten jedoch fest, dass die Arbeitsbelastung des PO diesmal zu hoch war. Besteht also eine Gefahr darin, sich auf null Story Points festzulegen, aber den Sprint so zu laufen, als wäre es ein echter Sprint?
Während Kadenz für agile Methoden wichtig ist, wird die Bedeutung von Transparenz oft übersehen. Das eigentliche Problem dabei ist, dass das Verzögern der Arbeit, während der Product Owner nicht verfügbar ist, echte Kosten für das Projekt darstellt und als solche sichtbar gemacht werden sollte .
Vor diesem Hintergrund würde ich den Entwicklern raten, diese Woche als arbeitsbezogene Freizeit zu nutzen. Lassen Sie sie ihre Workstations aktualisieren, ein Buch über eine neue Programmiersprache lesen, an der sie interessiert sind, oder anderweitig dafür bezahlt werden, etwas Nützliches für sie (und ihre zukünftige Produktivität) zu tun, ohne es zu formalisieren.
Es ist wichtig, dies nicht zu einer arbeitsreichen Woche zu machen. Das widerspricht nicht nur den selbstorganisierenden Prinzipien der Agilität, es ist auch einfach nicht gut für die Teammoral. Vielbeschäftigte Arbeit schafft auch die Illusion, dass das Team am Produktwert arbeitet, obwohl diese Zeit (obwohl sie möglicherweise für die Entwickler nützlich ist) das Projekt als Ganzes ausdrücklich belastet. Diese zentrale Wahrheit muss fest aufrechterhalten werden.
Bei jedem Projekt gibt es nicht produktbezogene Aufgaben, die Aufmerksamkeit erfordern. CI-Server benötigen Updates, SCM-Server benötigen Patches und so weiter. Soweit diese Dinge das Team betreffen, ist dies ein guter Zeitpunkt, um daran zu arbeiten, aber das Problem ist, dass es zu „unsichtbarer Arbeit“ wird, weil es im Product Backlog nicht priorisiert wird.
Außerdem lohnt sich der Mehraufwand, der mit der Erstellung eines einwöchigen Sprints verbunden ist, anstatt einfach zu warten, bis der PO für die Standard-Sprintlänge wieder im Sattel sitzt, wahrscheinlich nicht. Ich glaube, es ist besser, diese verlorene Produktivität als Bremse für die Geschwindigkeit des Teams zu erfassen und einfach besser in die Zukunft zu planen.
Gute Product Owner behalten für solche Gelegenheiten im Allgemeinen auch ein paar „Evergreen“-Geschichten und Geschichten über technische Schulden im Rückstand. Dann, wenn nichts anderes drängt, können diese Geschichten legitim bearbeitet werden, ohne dass sie vernachlässigt werden.
Schließlich sind die Probleme mit einem vom Team entworfenen und durchgeführten Sprint ohne Beteiligung des PO Legion. Betrachten Sie einige der folgenden Punkte:
Das Beste, was Sie tun können, ist, Ihre Entwickler informell für die Woche freizulassen. Lassen Sie sie an dem arbeiten, was sie interessiert, oder an ihrer beruflichen Entwicklung. Auch wenn es das Projekt nicht direkt voranbringt, trägt es langfristig zur Zufriedenheit der Entwickler bei und verbessert die Gesamteffektivität des Teams, ohne die Integrität des Scrum-Prozesses zu gefährden.
Also wollte ich vorschlagen, dass sie sowieso einen weiteren Sprint machen, sich aber nur auf technische Schulden konzentrieren …
Wenn Sie davon sprechen, sich auf technische Schulden zu konzentrieren, klingt das so, als würden Sie voraussehen , welche Prioritäten im Produkt-Backlog gesetzt werden. Du könntest Recht haben, oder du könntest falsch liegen.
Das mag puristisch klingen, aber ich würde vorschlagen, Elemente von der Spitze des Produkt-Backlogs auszuwählen, sobald es vorhanden ist . Da die Produkt-Backlog-Verfeinerung im Vorfeld dieses Sprints weggelassen wurde, gehe ich davon aus, dass das Sprint-Planungsmeeting herausfordernder und zeitaufwändiger sein würde, aber das ist nur eine natürliche Folge dessen, wie die Dinge gelaufen sind. Es ist sozusagen „Wasser unter der Brücke“.
Gönnen Sie sich ein längeres Sprint-Planungsmeeting als üblich, bei dem Sie viel Zeit damit verbringen, die wichtigsten Punkte ausreichend aufzuschlüsseln. Seien Sie vorsichtig, wenn es darum geht, wie viele der Top-Produkt-Backlog-Einträge Sie in das Sprint-Backlog aufnehmen. Tun Sie, was Scrum anleitet. Das Schlimmste, was passieren kann, ist, dass der PO entscheidet, dass er die ausgewählten Elemente niedriger priorisiert hätte. Zumindest haben Sie, soweit Sie das beurteilen können, an dem gearbeitet, was als Priorität identifiziert wurde.
Besteht also eine Gefahr darin, sich auf null Story Points festzulegen, aber den Sprint so zu laufen, als wäre es ein echter Sprint?
Ich glaube, die Gefahr besteht darin, dass Sie Arbeiten an technischen Schulden durchführen, von denen Sie annehmen, dass sie notwendig werden, und dann feststellen, dass dies nicht erforderlich war oder nicht in der Art und Weise, wie Sie es tun.
Wenn Sie als Teil großer Teams arbeiten (oder wenn Sie mehrere Teams auf einer Codebasis haben), kann dies als Härtesprint bezeichnet werden . Obwohl Sie die herausragenden Punkte des MVP per se nicht herunterfahren, machen Sie die Dinge insgesamt besser.
Sie können eine Reihe von Aufgaben übernehmen, um die Dinge zu verbessern:
Sie würden diese schätzen und an einer ähnlichen Anzahl von Punkten wie bei einem normalen Sprint arbeiten (vorausgesetzt, Sie haben diese Probleme als Storys protokolliert).
jmort253
jmort253
jmort253