In meinen früheren Beiträgen über die Definition von READY und Flow to Ready, Iterate to Done habe ich versucht, etwas Licht in das große schwarze Loch von Scrum zu bringen: den Product Owner. Dies ist Nummer drei in dieser Serie. In meinem letzten Blogbeitrag habe ich die Phasen vorgestellt, die ein Backlog-Artikel durchläuft, bevor er fertiggestellt wird. Aber das waren nur die Ideen dahinter. In diesem Blogbeitrag zeige ich, wie ich sie in der Praxis umgesetzt habe. Ich werde Ihnen zwei interessante Beispiele zeigen.
Das grundlegende Ready Kanban hat drei Spalten: Neu, Vorbereitet und Bereit (siehe die Erklärung im letzten Beitrag der Serie). Sie
Robs READY Kanban
Diese Tafel wurde von Rob Buster, einem der Product Owner bei bol.com, erstellt. Wie Sie sehen können, hat seine Tafel vier Spalten, da sie in der Nähe seines Schreibtisches hängt, der sich auf einer anderen Etage befindet als der des Teams.
Einige Dinge, die Sie an seinem Brett beachten sollten:
- fügte er einen "Poker Ready"-Abschnitt hinzu, in dem er eine Anzahl von User Stories sammeln kann, die in einem Zug in einer Poker-Planungssitzung geschätzt werden können. Das ist eine sehr gute Idee und wird wahrscheinlich auf vielen Ready Kanbans landen. Trotzdem schreibe ich es in meinem allgemeinen Format nicht ausdrücklich vor, da es von der Arbeitsdynamik zwischen einem Team und einem PO abhängt, ob sie dies einzeln oder in Stapeln tun wollen.
- die rosa Herzen wurden von einem Kollegen im selben Raum hinzugefügt, der das große braune Papier hässlich fand... :-)
- Rob verwendet blaue Stickies, um seinen Ready-Puffer in Sprints zu unterteilen. Auch dies ist eine sehr gute Idee, denn sie zeigt deutlich die aktuell erwarteten User Stories, die im nächsten Sprint abgeholt werden sollen. Außerdem können so die User Stories physisch umgeschichtet werden, um die Sprints entsprechend der Geschwindigkeit des Teams aufzufüllen.
Das erste Ready Kanban
Dies war der erste Ready Kanban, den ich je aufgestellt habe. Ich füllte es zunächst mit dem oberen Teil des Backlogs, das sich in Vorbereitung befand: die ersten fünf im Zustand "Vorbereiten" und die nächsten 10 im Zustand "Top 10 Neu". Beachten Sie, dass es an seinem logischen Platz hängt: auf der linken Seite des Scrum-Boards, im Einklang mit dem allgemeinen Fluss der User Stories von links nach rechts. Das ist dasselbe Board ein paar Tage später (ich habe die Titel verwischt):
Hier waren viele interessante Dinge geschehen:
- Die Analysten, die die gesamte Vorbereitungsarbeit leisteten, tauchten immer häufiger im Teamraum auf. Ähnlich wie ein Scrum-Board für ein Team, wurde es zum Treffpunkt, um Koordination, Status und Fortschritt zu besprechen.
- Der neue Puffer begann zu versiegen. Mit der zunehmenden Geschwindigkeit des Teams wurden viele Punkte auf der alten Liste der Änderungswünsche neu bewertet und als veraltet oder überflüssig eingestuft. Das deutete eindeutig darauf hin, dass der Dialog mit dem Unternehmen beschleunigt werden musste, um deren Anfragen zu erhalten. Damit hatte ich nicht gerechnet, denn ich dachte, dass dieser Puffer immer voll sein würde. Es stellt sich heraus, dass hier ein subtiler Effekt stattfindet: Wenn Sie etwas in Neu einfügen, bedeutet das eine subtile Beförderung, und das führt dazu, dass eine einfache Triage an der Benutzergeschichte vorgenommen wird. Man könnte sagen, dass dies wie ein "Bullshit-Filter" funktioniert :-).
- Die oberste Karte in der Vorbereitungsspalte blieb dort stecken, während sich die Karten darunter bewegten. Es wurde deutlich, dass es ein Hindernis bei der Fertigstellung dieser Benutzergeschichte gab, und es wurden zusätzliche Anstrengungen unternommen, um die vom Unternehmen zu treffenden Entscheidungen zu klären.
- Der Bereitschaftspuffer füllte sich nicht schnell genug. Der Stand des Bereitschaftspuffers ist ein wirklich gutes Mittel, um zu zeigen, ob die Geschwindigkeit des PO mit der des Teams übereinstimmt. Es funktioniert in dieser Hinsicht so gut, dass die Teammitglieder erkannten, dass es nicht wirklich sinnvoll ist, weiter an der Funktionalität zu arbeiten, wenn die Arbeit versiegt. Also begannen sie, die PO-Rolle dabei zu unterstützen, User Stories fertig zu stellen. Na, das nenne ich Selbstorganisation!
Fazit
Alles in allem bin ich WIRKLICH zufrieden mit den Ergebnissen, die ich gesehen habe, als ich dieses Board eingesetzt habe. Plötzlich haben die POs ihren Informationsradiator, sie können sich mit anderen abstimmen, steckengebliebene User Stories sind deutlich sichtbar, und jetzt gibt es eine Grundlage für die Messung der Leistung der PO-Rolle. Wir können ein Trenddiagramm erstellen, das den Stand des Ready Buffer anzeigt (die PO-Version des Burndown...), wir können die durchschnittliche Fertigstellungszeit einer User Story messen (in Anlehnung an die "Taktzeit" von Lean), und der PO kann etwas Vernunft zurückbringen, indem er die in Arbeit befindliche Arbeit im Status Preparing begrenzt. Bitte verbreiten Sie die Nachricht und sorgen Sie dafür, dass so viele POs wie möglich von Ready Kanban erfahren: die PO-Rolle ist bei weitem die schwierigste aller Rollen in Scrum, und ich weiß aus Erfahrung, dass jede Hilfe willkommen ist... :-) Was steht als Nächstes an? Ich hoffe, ich brauche nicht so lange wie beim letzten Mal, aber ich werde Ihnen zeigen, wie ich Ready Kanban in JIRA implementiert habe. Wenn Sie eine verteilte PO-Rolle haben (oder überhaupt eine verteilte Situation), brauchen Sie Unterstützung durch Tools, um die Lücke zu schließen...
Verfasst von
Serge Beaumont
Unsere Ideen
Weitere Blogs
Contact