Distributed PI Planning Experience - das Neue wird Normal

Das Neue wird Normal - Dispersed PI Planning Event (PIPE) ist das neue Distributed PIPE

Was ist der Unterschied? 
Zusätzlich zu den kontinentübergreifenden Teams, die im Büro sitzen (verteilt), sitzt jetzt jeder alleine zu Hause (verstreut). In den letzten zwei Monaten haben wir viel gelernt
.
 
Welche Erfahrungen können anderen helfen?
1.    Es geht besser als gedacht. Der Aufwand und die Transformation eines Co-located PIPE (immer besser) in ein Dispersed PIPE lohnt sich!
Nicht weil man danach nur noch Dispersed arbeiten möchte, sondern weil der Perspektiven-Wechsel die Nutzung von Methoden und Werkzeugen ganz allgemein, also auch für das Neue, normal verbessert. Es gibt viel zu lernen und es beginnt damit das ´gut Ding, gut Weile´ haben möchte, also
2.    Prepare, prepare, prepare, um genug Luft für Überraschungen, die auf jeden Fall kommen werden, zu haben. Das Durchdenken des PIPE- Prozesses erlaubt einem an vielen Stellen, den agilen Weg zu wählen. Die richtigen Tools vorausgesetzt, lassen sich z.B. kürzere Wege finden, als im realen Leben. Bei den Tools gibt es zur Zeit klare funktionale Präferenzen (Zoom, Miro, Jira, Slack), es geht aber auch anders (Teams, Concept Board, TFS, Excel, Teams). In kürzerer Zeit mehr Qualität für die Anwender, gerne mit mehr als 100 Personen. Zeitaufwand hierfür liegt schnell bei mehreren Personentagen. Noch wichtiger ist ein Vorlauf von einigen Wochen.
3.    Mache es so ähnlich wie möglich zum bisherigen Erleben, dieses Prinzip hilft sehr: Denke vom Nutzer aus und mache ihm die Arbeit einfacher.
4.    Ablenkungen durch das Tool minimieren. Immer aus der Sicht des Nutzers aufsetzen. Das bedeutet, wie so oft, weniger ist mehr. Weniger Vielfalt in der Bedienung, die Nutzer früh einbeziehen oder eben genau wissen, was Scrum Master, POs und Teams so brauchen, um sich auf ihren Job zu fokussieren.
5.    Die Nutzung üben und lernen. Z.B. 4-8 Wochen vorher starten und dann iterativ, inkrementell erst mal einen Durchstich anlegen.
6.    Was gebraucht wird, im PDCA Cycle erstellen: 
a.    Iteration 1: 
I.    Das sortierte Feature Backlog (FB) auf ein Planning Board platzieren 
II.    Das Programm Board (PB) designen
III.    Die Team Boards (TB) definieren
IV.    Das Roaming Board, (RB) gerne als Foto
V.    Das Voting Board (VB) und last but not least
VI.    Retro Board (RB), das sich sehr bewährt hat 
Review Meeting  mit Anwendern -> Feedback … weiter geht´s. 
b.    Iteration 2: 
I.    Feature Backlog (FB) Teamzuordnung farbig darstellen => jedes Team kriegt seine Farbe
Feature Backlog (FB) Indikator für die Business Owner, was gerade in der Planung ist 
II.    PB Teamnamen (Farbe in den Spalten wiederholen)
PB Input-Queue für Dependencies (SM schauen danach und sortieren diese nach Priorität der Features)
Owner für allgemeine Aufgaben benennen (z.B. SM oder PO, oder BOs)
III.    Team Boards (TB) so wie es die Teams gewohnt sind, als Vorlage für alle Post-its oder User-Story-Karten vorbereiten,
Fibonacci Reihe vorbereiten 
IV.    …
Review Meeting mit Anwendern -> Feedback und so weiter……. Mehr Tipps in unserer Schulung zu Remote PIPEs.
c.    Iteration 3:…..
7.    Nicht perfektionieren: A fool with a Tool is still a fool!! Also nach 2-4 Iterationen in den Trainingsmodus wechseln.
Auf jeden Fall einen Dry Run machen. Aus dem Dry Run lernen, es tauchen gern Probleme mit Security und Einstellungen auf. Genug Zeit, einige Tage haben, um diese beheben zu können. Dass die Tools genutzt werden dürfen, heißt nicht, dass sie auch genutzt werden können.
8.    Video nutzen: Wenn technisch irgend möglich (Zoom) mit eingeschalteter Videokamera arbeiten 
9.    Einen technischen Admin dabei haben, der bei eventuellen Störungen alles wieder ins Laufen bringt – das beruhigt sehr.
Operations vorwarnen, dass eventuell für diese untypische Last und Nutzungsverhalten Probleme auftreten werden.
10.    Das Agile Manifest beachten – hahaha genau wie war das noch:
•    Individuals and interactions                over processes and tools
•    Working software                                  over comprehensive documentation
•    Customer collaboration                        over contract negotiation
•    Responding to change                           over following a plan

Ein schöner Trick, die rechte Seite ist erlaubt solange sie die Linke fördert!!! Und dann Spaß haben und sich an der konstruktiven Art des Umgangs mit einem Dispersed PIPe erfreuen.

Kommentare (0)
Keine Kommentare gefunden!
Neuen Kommentar schreiben

Kurt
Jäger


Veröffentlicht am

Kurt Jäger arbeitet seit 40 Jahren als Softwareengineer in unterschiedlichen Software-Produkthäusern in verschiedenen Positionen. Seit Oktober 2013 ist er agiler Management-Berater und Partner der KEGON AG. Er ist zertifizierter Scrum Master und Programm Consultant für das Scaled Agile Framework von Dean Leffingwell, aktuell befindet er sich in der Ausbildung zum SPC-Trainer. Auch ist Kurt seit 2018 zertifizierter SAFe Release Train Engineer (RTE). In den letzten 10 Jahren hat er agile Transitionen bei Audi, BMW, Bosch, Continental, CompuGroup Medical, CosmosDirekt, Deutsche Bahn, Deutsche Bank, Generali, GfK, Roche, Schufa, SAG, SAP, Siemens und Société Générale beraten und begleitet.


Kategorien


Top-Artikel



Newsletter

Bleiben Sie immer informiert