Das PI-Planning in SAFe als Remote-Event

Veröffentlicht am 22. April 2020

Behandelte Themen

Einführung von Matthias Rauer

Wozu dient SAFe und was bezweckt das Konzept? (Begriffe Skalierung und Agile)

Die Rolle des PI-Plannings im Kontext von SAFe

Wie läuft ein PI-Planning im Normalfall ab?

Tools und digitale Unterstützung für Scaled Agile

Kurzer Überblick über das Tool Agile Hive

Tools um ein PI-Planning digital durchführen zu können

Änderung der Schritte für ein digitales PI-Planning

Ablauf eines Remote PI-Plannings

Persönliche Tipps von Peter

Transkription des Podcasts

Mit: Matthias Rauer und Peter Weingärtner von Seibert Media

Matthias: 

Hallo und Willkommen zu einem neuen Podcast von Seibert Media. Auch in dieser Folge wollen wir uns mit einem Aspekt der Remote-Zusammenarbeit beschäftigen, diesmal im Hinblick auf die Organisation agiler Prozesse auf Unternehmensebene. Konkret, es geht um PI-Plannings in verteilten Konstellationen. Tja, die Beschränkungen und Auswirkungen der Corona-Pandemie sind eigentlich in jedem Unternehmen zu spüren und sie treffen bekanntlich vor allem die physische Zusammenarbeit und Abstimmung von Menschen und die Situation tangiert eben nicht nur die agilen Prozesse auf Teamebene, wie Scrum, sondern auch auf höheren Ebenen. In diesen Tagen und Wochen alle für ein bestimmtes Thema relevanten Mitarbeiter physisch an einen Tisch zu kriegen, und das womöglich in einem global verteilten Unternehmen, ist ein Ding der Unmöglichkeit und dementsprechend werden alternative Wege händeringend gesucht. 

Über solche Wege spreche ich heute mit meinem geschätzten Kollegen Peter Weingärtner. Er ist einer unserer ausgewiesenen Experten für das Scaled Agile Framework, abgekürzt SAFe, und Mitglied in unserem Entwicklungsteam für Agile Hive. Hi Peter, schön, dass du dir heute ein bisschen Zeit nimmst!

Peter:

Hallo Matze, sehr gerne. Danke dir!

Matthias:

Ich bin Matthias Rauer und Peter, lass uns doch mal an dieser Stelle zwar keine umfangreiche Einführung zum Scaled Agile Framework geben. Das könnten wir in einem kommenden Podcast vielleicht einmal ausführlich tun. Aber vielleicht kurz zum Einstieg um einen kleinsten gemeinsamen Nenner für unsere Zuhörer zu schaffen, wozu dient SAFe und was bezweckt dieses Konzept? Also die Begriffe Skalierung und Agile lächeln einen ja schon an. 

Peter:

Ja, genau, da sagst du genau das Richtige. Skalierung und Agile, es geht tatsächlich um die Skalierung agiler Methoden, insbesondere in der Produktentwicklung, aber mittlerweile auch darüber hinaus ins gesamte Unternehmen und da ist SAFe eigentlich so der Platzhirsch als Framework, um das eben für große Unternehmen, ja, stemmen zu können, auf Basis von Erfahrung und vielen Informationen. So das Herz des Ganzen ist eigentlich, dass wir davon ausgehen müssen, dass in großen Produkten eben die Teams nicht, wie du es eben schon sagtest, in Scrum unabhängig sind, sondern tatsächlich eben große Abhängigkeiten haben, um große Lösungen auch zu schaffen und in dem Zusammenhang braucht es also irgendwelche Lösungen, um diese Abhängigkeiten, ja, gut zu meistern und trotzdem eben diese großen Lösungen schaffen zu können. Das heißt, wir haben viele voneinander abhängige Teams in der Skalierung und darüber wird im SAFe-Kontext eben als Team auf Agile Teams der sogenannte Agile Release Train gesetzt. Das heißt, das ist also ein Zug, den kann man sich so vorstellen, wo alle Entwickler mit an Bord sind und die haben eben dann gemeinsame Haltepunkte und diese Kadenzen sind dann dazu da, dass man eben Integrationspunkte zwischen den Teams findet, aber eben auch dann eben zu diesen Punkten releasen kann, sofern man sowieso Release on Demand praktiziert und eben dann auch über den gesamten Release Train hinweg Möglichkeiten findet, um im agilen Kontext eben auch Inspectete Debt Workshops zu halten und dergleichen mehr. Und vor allen Dingen dann auch wieder die nächste Kadenz zu planen. 

Diese Kadenzen nennen sich Product Increments, kurz PI, und darüber sprechen wir ja auch heute und innerhalb dieser PI's gibt es eben die Sprints weiter in den Teams, wie gehabt. Allerdings heißen sie im SAFe-Kontext Iterationen. 

Matthias:

Welche Rolle spielt denn dieses PI Planning über das wir heute unterhalten wollen, im Kontext von SAFe?

Peter:

Ja also, das PI Planning ist tatsächlich eigentlich so das zentrale Planungs-Meeting. Das findet in der Regel, vereinfacht gesagt, sage ich mal so, jedes Quartal statt, also es ist tatsächlich so, dass man hier so ein bisschen aus der alten Business-Welt kommt, Dinge wiederfindet und das in das agile überträgt, dass auch hier eine große Passung da ist. Aber grundsätzlich geht es erstmal darum, dass man eine Anzahl von Interationen hintereinander hat, um halt große Lösungen hintereinander zu schaffen. Zum Beispiel vier, fünf, sechs, sieben Stück und danach hat man eben ein PI geschafft. Und dieses Planning ist eigentlich so das, was im Endeffekt das Agile nach SAFe überhaupt reinbringt, denn die Idee ist tatsächlich, dass alle ART-Mitglieder, inklusive der Stakeholder aus dem Management zusammenkommen und gemeinschaftlich, kollaborativ, agil, planen, was eben zu tun ist und alle eben auf einem großen Alignment-Level eben sind. Dass alle wissen, woran eigentlich gearbeitet wird.           

Matthias: 

Du hast eben schon von Zusammenkommen gesprochen, wie sollte denn so ein PI Planning im Normalfall oder besser gesagt, im Idealfall, ablaufen, bzw. stattfinden. Offenbar ja, alle auf einem Fleck versammeln.

Peter:

Genau, das ist eigentlich die große Hürde und aber auch gleichzeitig die große schöne Aufgabe im Zusammenhang mit SAFe, dass man davon ausgeht, dass so ein PI Planning tatsächlich, wie es ja ein agiler Grundsatz will, von Angesicht zu Angesicht stattfindet. Das heißt, die Organisation scheuen oftmals keine Kosten und Mühen, um wirklich alle Personen in dem Zusammenhang eines ARTs oder sogar einer ganzen Solution, das ist dann nochmal größer gedacht, eben zusammenzubringen in einer Location und über zwei Tage hinweg in einem großen Lokal-Event dann eben mit Bewegung zwischen den Teams, ganz agil, wie man es sich eben so vorstellen kann, untereinander zu planen und so halt eben auch halt eine Wertschätzung und einen Gemeinschaftssinn herzustellen. 

Matthias:

Ist das denn die Regel, dass Unternehmen, in denen SAFe etabliert ist, die Leute tatsächlich auf diese Art und Weise zusammenbringen? Ich meine, die Probleme, die wir jetzt sehen, bestehen ja nicht nur jetzt angesichts der Corona-Krise, sondern grundsätzlich. Es ist also auch unter normalen Umständen sicherlich schon eine gewisse Herausforderung vielleicht sogar als global verteiltes Unternehmen alle relevanten Leute zu so einer Veranstaltung an einen Tisch zu bekommen. Ist das so, oder machen Unternehmen, die SAFe einsetzen wirklich konsequent, die fliegen alle Leute aus der ganzen Welt zusammen, um sich dann zu treffen?

Peter:

Also, im Idealfall ist es natürlich so, dass man sich trifft, denn, wie schon gesagt, agiler Grundsatz, von Angesicht zu Angesicht, kriegt man am besten Informationen halt eben aus anderen heraus, in andere rein, zwischen den Teams irgendwie bearbeitet und auch dieses menschliche Miteinander führt natürlich auch zu einer viel höheren Akzeptanz. Gleichzeitig ist es natürlich so, dass wir auch im Zusammenhang mit Agile Hive schon die ein oder anderen Kunden haben und hatten, die gesagt haben, ja wir schaffen das nicht mit einem Vororttermin. Das kostet natürlich unglaublich viel Zeit, das kostet viel Geld, das ist ein Riesen Aufwand, das regelmäßig tatsächlich durchzusetzen, aber es ist auch eben auch ein Herzstück von SAFe. Insofern ist es auf jeden Fall natürlich wünschenswert, dass die Leute zusammenkommen und dann auch Aufgabe der verantwortlichen eben auch die Teams, beziehungsweise die Release Trains, kurz ARTs, so zu schneiden, dass nach Möglichkeit eben die Aufwände nicht so groß sind. Aber, ja die Realität holt einen dann natürlich öfter mal ein, insofern, die Anforderung gibt es schon häufig, dass man eben auch so etwas auch komplett remote machen kann. Und, jetzt brauchen wir uns im Moment schon gar keine Gedanken mehr drüber zu machen, was halt eben schön und wünschenswert wäre, sondern wir stecken halt eben in der Situation, dass wir halt jetzt remote arbeiten müssen. 

Matthias:

Ja, spätestens jetzt merken wir es alle, wenn Menschen remote zusammenarbeiten, und das ist offenbar eine Tatsache, braucht es Tools. Und das legt auch den Schluss nah, dass Scaled Agile auf jeden Fall digitale Unterstützung braucht. Ist das richtig?

Peter:

Ja, also wenn wir von agil sprechen, sprechen wir auch immer von viel Kommunikation, Dokumentation, Austausch und ich sage mal, in einem Scrum-Team kann man sich sicherlich noch mit einem Whiteboard an der Wand behelfen, aber wenn wir halt eben hier von mehreren hunderten oder mehreren tausend Leuten sprechen, ist natürlich digitale Unterstützung gefragt, ganz klar. Und insofern setzt jetzt dieses Remote, diese Herausforderung an das Remote natürlich noch einmal eine neue Dimension oben drauf, eine Herausforderung, die man halt auch noch irgendwie lösen muss, ja. 

Matthias:

An dieser Stelle kommen wir nicht drumherum, Tools auch einmal beim Namen zu nennen. Wir wollen jetzt hier kein auditives Teleshopping machen, aber du bist im Team für unser Produkt Agile Hive. Gib doch einmal einen kurzen Überblick, was Agile Hive ist und kann und erreichen will.

Peter:

Sehr gerne. Wir haben ja eben schon gesagt, Produktentwicklung ist natürlich sehr komplex. Wenn man zusammenarbeiten möchte, braucht man in irgendeiner Form ein Tool. SAFe ist auch noch einmal sehr komplex und um ein bisschen die Komplexität aus der Sache herauszuholen, nutzen viele Unternehmen Jira oder beziehungsweise generell Atlassian Tools, um eben ihre Produktentwicklung oder halt eben auch anderen Prozesse zu steuern. Und da ist natürlich die Frage, wie kriege halt eben aber auch so ein Framework, das bestimmte Regeln und ja, Events und alle möglichen Dinge eben mitbringt, tatsächlich nach Jira rein? Wer schon einmal probiert hat, SAFe mit Jira-Bordmitteln umzusetzen, wird wahrscheinlich über die ein oder andere Herausforderung gestolpert sein. Eines der größten Dinge ist es, dass häufig Hierarchie-Ebenen fehlen. Das ist einfach in Jira historisch so gewachsen, dass wir eben die Stories haben, dann eventuell darüber noch das Epic und dann schon die Projekte und je nachdem, welche Konfiguration von SAFe man eben fährt im Unternehmen, da gibt es unterschiedliche, stellt man sehr schnell fest, dass man hier recht schnell in eine Sackgasse gerät. 

Dann gibt es auch in Jira eine abweichende Nomenklatur, weil es ist ja nicht ein SAFe-Tool und insofern, gerade, wenn man sich eben diese Framework angelernt hat, ist es natürlich sehr Akzeptanz-fördernd und auch einfacher, wenn die Nomenklatur stimmt. Eine andere Herausforderung ist die Unterteilung in PI’s, während Jira natürlich sehr gut ist eben auch in Scrum-Teams die einzelnen Sprints zu unterteilen, fehlt so eine übergeordnete Kadenzen-Unterteilung in diese PI’s. Da gehen viele Administratoren hin und nutzen dann die Version oder Releases eben in Jira dazu, aber das ist natürlich auch nur eine Notlösung und ja, zu guter Letzt fehlt einem bei jedem Workaround eigentlich auch noch die inhaltlich-methodische Unterstützung. Und das sind jetzt einmal so vier Punkte, die uns dazu bewogen haben, eben für die Atlassian-Tools Jira und Confluence eine gemeinschaftliche Lösung mit Fokus auf Jira für das Prozessmanagement zu schaffen, um eben SAFe in seiner Gänze abzubilden und die Unternehmen und die Teams dabei zu unterstützen, aus ihrem geliebten Jira-Tool eben nicht rauszumüssen und auch Confluence in Kombination, da nicht rauszumüssen, sondern eben all das innerhalb dieser beiden Tools abbilden zu können. 

Matthias: 

Kommen wir auf unser PI-Planning noch einmal ganz konkret zu sprechen. Neben Agile Hive und Jira, welche digitalen Tools benötigen wir denn grundsätzlich, umso ein PI-Planning remote möglichst effektiv und effizient durchführen zu können?

Peter:

Ja, die Antwort ist natürlich ein bisschen schwierig, weil es sicherlich von Unternehmen zu Unternehmen variiert, welche Tools da zum Einsatz kommen oder kommen sollten. Von unserer Seite würden wir natürlich Agile Hive empfehlen. Agile Hive ist in erster Linie eine Jira-App mit einer Confluence-Anbindung und dort eben auch einigen Elementen, die sich in Confluence dann wiederfinden. Darüber hinaus braucht man sicherlich ein gutes und mächtiges Video-Conferencing Tool, das im Endeffekt eben alle Menschen hilft, miteinander zu verbinden. Im Idealfall auch eben so, dass man sich in die Augen schauen kann. Weil wenn wir uns schon nicht wirklich von Angesicht zu Angesicht in Person an einem Ort treffen, dann ist es sicherlich sehr hilfreich, wenn man halt auch ein paar Gesichter hat. Und darüber hinaus gibt es sicherlich noch eine ganze Bandbreite an weiteren Apps, innerhalb von Jira und Confluence, die hilfreich sein können und/oder eben auch weitere Online-Tools, wie zum Beispiel Miro, Metimeter, Retromat, da gibt ganz viele Dinge, die wirklich sehr sehr gut funktionieren mittlerweile und auch wirklich Spaß machen in der Handhabung.

Matthias:

Um daran anzuknüpfen, ob nun physisch oder verteilt, auf jeden Fall muss so eine Veranstaltung geplant und vorbereitet werden. Welche Planungsschritte ändern sich denn jetzt im Vorfeld, wenn wirklich ein Unternehmen so ein PI-Planning ausschließlich remote durchführen will?

Peter:

Also Scaled Agile liefert schon einmal eine sehr gute Checkliste für den sogenannten ATE, also den Release Train Engineer, der die Verantwortung trägt…

Matthias:

Also das Framework an sich bringt so eine Checkliste mit, ja?

Peter:

Genau, das Framework selber bringt schon so eine Checkliste mit und die ist jetzt aber erstmal, historisch bedingt, für das Vorort-Planning gedacht. Scaled Agile macht sich aber auch sehr viel Mühe gerade, das eben auch zu aktualisieren, um der blöden Situation jetzt eben auch gerecht werden zu können. Aber kurz gesagt, wir haben diese Checkliste auch angepasst, die ist auch bei uns in Confluence hinterlegt im Tool. Mit ein paar Empfehlungen zumindest, ganz grob kann man mal sagen, alles was Location-Planung angeht, fällt natürlich weg. Das heisst, den Veranstaltungsort selbst muss man nicht buchen. Man muss nicht fürs Catering sorgen, zumindest nicht dort. Hotelübernachtungen und so weiter, das fällt eben alles weg. Das ist natürlich ein erheblicher Bestandteil. Dafür kommt etwas ganz Neues, sehr erhebliches dazu. Vor Ort braucht es natürlich auch eine gewisse Technik, aber so ein Remote Planning funktioniert natürlich nur dann, wenn wirklich die Technik funktioniert. Das heisst, wir würden dringend empfehlen, sehr früh die IT zu involvieren und auch mit in die Verantwortung zu nehmen. 

Dann wäre es sicherlich sehr sinnvoll, früh darüber nachzudenken, welche Kommunikations-Szenarien gibt es denn eigentlich. Das ist sicherlich auch von ART zu ART, von Unternehmen zu Unternehmen individuell, aber das früh zu durchdenken ist sicherlich sinnvoll. Das heisst, zum Beispiel wird es sicherlich so etwas geben, wie einen Plenum, wo eben alle zusammenkommen und in erste Linie vielleicht vorne etwas präsentiert wird. Also vorne, digital, was präsentiert wird und die anderen eher einmal zuhören und man sich zwischendurch noch einbringen kann. Dann gibt es sicherlich ganz wichtig, diese Breakout-Sessions für die Teams, wo wirklich die Teams wieder innerhalb voneinander eben arbeiten. Dann aber auch die Möglichkeit wieder, zwischen den Teams zu kommunizieren ist ganz wichtig. Und darüber hinaus gibt es eben noch so Konstellationen, wie das Scrum-of-Scrums oder auch so die Management-Abstimmung für das Review und so weiter. Also, dass man darüber nachdenkt, welche Konstellationen gibt es und dafür sehr früh auch schon die Technik prüft, Regeln etabliert, die vielleicht auch im Unternehmen früh kommuniziert und halt eben auch von den Erfahrungen anderen zu profitieren und auch darüber diskutieren zu können, um auch die Akzeptanz zu fördern und nachher wirklich ein gutes Setting zu haben. 

Mit Regeln meine ich zum Beispiel auch so etwas wie, gerade in so einem Plenum, mit, ich sage jetzt mal, 120 Leuten, ist natürlich anders arbeiten, als zum Beispiel in einer Breakout-Session von einem Team. Die Teams innerhalb voneinander sind oftmals sehr gut darin, miteinander zusammenzuarbeiten, das ist unproblematisch, aber jetzt plötzlich ist unter Umständen so ein Unternehmen erstmalig in der Situation, mit über 100 Leuten in einer Videokonferenz zu sein. Das sollte eben gut durchdacht sein, dass man vielleicht das technisch so löst, dass jeder, der neu dazu kommt, automatisch erst einmal stumm geschaltet ist. Weil es gibt nichts nervigeres, als Störgeräusche. Oder, dass man sich vielleicht gar nicht laut stellen kann und alle Fragen und Anmerkungen nur über einen Chat stellen kann. Das sind alles so Sachen, die sollte man sich tatsächlich gut überlegen. Da haben wir auch schon ein paar Erfahrungen gemacht und da muss man eben gucken, was für das Unternehmen dann auch passt. 

Und dann noch zu guter Letzt, was auch sicherlich nicht doof ist, ist so etwas, wie die Hardware für die Präsentatoren. Wie eben schon gesagt, im Team reicht sicherlich dann auch die Kamera vom Laptop und das Mikrofon, aber wenn ich vor 120 Leuten eben irgendwie ein Business-Kontext präsentiere, wäre es schon ganz gut, wenn ich eine vernünftige Kamera habe, ein vernünftiges Mikrofon habe und im Idealfall eben auch weiß, wie das Ding funktioniert, in dem Moment, wo es dann halt eben darauf ankommt. Das heißt, auch so ein bisschen Schulung im Vorfeld ist sicherlich nicht doof. Je nachdem, wie erfahren man da eben in den Unternehmen ist. Und dann, zu letzter Letzt gilt, testen, testen und testen. Also jetzt nicht an dem Tag der Tage dastehen und irgendetwas funktioniert nicht. 

Matthias:

Jetzt plauder doch einmal ein bisschen aus dem Nähkästchen. Wie läuft denn so ein Remote PI-Planning ab? Welches Tool unterstützt denn an welcher Stelle? Erzähl einmal ein bisschen!

Peter:

Ja, okay, ich habe es ja eben schon einmal erwähnt. Also wir haben in Confluence selber eine Checkliste. Für den Release Train Engineer, beziehungsweise das Planungskomitee, wer auch immer den Hut aufhat eben für die Planung des Events, der kann sich hierdran entlang hangeln. Dann können die, nennen wir sie jetzt einmal Content-Lieferanten, Business-Owner, Produktmanagement, Architekten, was auch immer, können im Vorfeld eben auch Confluence nutzen, und auch schon auf vorgefertigte Template zurückgreifen, und dort ihre Inhalte im Vorfeld erarbeiten. Das ist natürlich im Idealfall kollaborativ, man tauscht sich aus und mit den Fähigkeiten von Confluence. Oftmals ist es ja so, dass man hierbei den ein oder anderen vielleicht erstmals zu motivieren muss, überhaupt in Confluence zu arbeiten, weil gerade im Management ist man häufig ja gewöhnt, eher mit anderen Tools zu arbeiten. Aber das ist natürlich schön, wenn man hier alles zusammen in einem Tool hat und dann halt eben dokumentiert für das gesamte PI danach, ich also keine Arbeit doppelt habe.

Ja, und die Ergebnisse, die dann eben hier erarbeitet werden, die können dann in erster Linie, das ist sicher einer der wichtigsten Seiten, in dem Zusammenhang, auf so einer Overview-Page zusammengeführt werden. Da sollten dann alle zentralen Infos drauf sein. Was dieses Planning halt eben angeht, für alle Beteiligten und das auch mit Direktzugriff auf die entsprechende Kanäle, die wir eben angesprochen haben. Das ich also von dort aus nur irgendwo draufklicken muss und lande sofort im entsprechenden Video-Call und muss nicht noch irgendwo rumsuchen, wo waren denn nochmal die Einwahldaten. Und, aus dieser Overview-Page, wenn wir das so gestalten, wie wir das vorbereitet haben, kann man auch direkt Einladungen versenden, an alle Beteiligten, man kann die Anmeldung nachhalten, gucken, wie viele Leute haben sich denn angemeldet und haben da vor zu kommen. Das ist natürlich schon einmal ganz praktisch, dass man das alles aus einem Tool heraus machen kann. 

Dann ist es sicherlich auch sinnvoll eben, Wissens-Kontext, Produktversionen, alles, was wir da in diesem Zusammenhang haben, als, ja, Zielsetzung und als Hintergrundinformation das schick aufzubereiten, dass man es halt nachträglich auch immer wieder weiterverwenden kann. Zumindest alternativ zur PowerPoint. Die kann man immer noch an die Seite dranhängen, wenn es sein muss. Dann geht es eben weiter. Also die sonstige Vorbereitung der Entwicklung, die passiert eigentlich wie gehabt in Jira. Da ist jetzt nichts besonders, wenn man es remote macht, würde ich jetzt einmal so ganz vereinfacht sagen. Wenn ich mir ein Beispiel zum Tag 1 der Agenda mir anschaue, dann würde so dieser gesamte Hintergründe-Ziele-Teil sicherlich in so einem zentralem Videokonferenz-Kanal, im Plenum eben, stattfinden, wo dann alle, hoffentlich zur selben Zeit, wenn sie gut informiert sind, eben dabei sind und eben darüber informiert werden können, woran arbeiten wir denn eigentlich. Was sind die, was ist der Business-Kontext, und so weiter, damit wir halt eben dieses Alignment schaffen können, was die nächsten Monate denn für uns dann eben so spannend machen.

Matthias:

Kurz zum Verständnis, das PI-Planning ist grundsätzlich in zwei Tage aufgeteilt? Weil du eben von Tag 1 sprichst, und…

Peter:

Genau, also nach Scaled Agile selbst, ist das PI-Planning für zwei Tage geplant und das würden wir jetzt in dem Zusammenhang jetzt auch remote nicht anders handhaben. Man könnte wahrscheinlich eher fast darüber nachdenken, es vielleicht auch noch einmal auf drei Tage aufzuteilen, weil, wir sind ja jetzt alle ein bisschen leiderprobt. Das Remote-Arbeiten ist unter Umständen deutlich anstrengender, als wenn man irgendwo vor Ort ist, weil es einfach ungewohnt ist, ständig an die selbe Stelle zu gucken und so weiter. Aber grundsätzlich geht Scaled Agile von zwei Tagen aus, und wie die dann eben halt aufgeteilt werden, sollte man sich dann überlegen. 

Genau, also nach der Eröffnung, wo eben die Präsentatoren zur Sprache kommen, hat man anschließend normalerweise das Lunch, da haben wir tatsächlich wenige digitale Tools, die das unterstützen, aber als kleine Idee, vielleicht kann man das irgendwie organisieren, dass alle Beteiligten, keine Ahnung, ohne Schleichwerbung machen zu wollen, einen Lieferando-Gutschein oder irgendwie etwas Gemeinsames haben, dass man auch da das Gefühl hat, an einem Tisch zu sitzen, wenn der auch nur virtuell ist. 

Dann anschließend kommen die Team-Breakouts. Und die werden eigentlich innerhalb von Agile Hive an einem Jira-Board gemacht. Also das ist ein besonderes Board, wo ich eben als Team dann die Kapazitäten meines Teams planen kann. Wo ich die Features, die ich halt eben übernehme herunterbrechen kann in Stories und diese Stories eben auch aufteilen kann, in die verschiedenen Sprints, beziehungsweise Iterationen. Und da würden wir auf jeden Fall dazu raten, dass das eben auch ein Scrum-Master zum Beispiel als Moderator übernimmt und alle auf dessen Screen gucken und man das dort gemeinschaftlich macht, denn tatsächlich muss man in Jira noch manchmal eben nachladen, das passiert dann nicht direkt live. Also da ist noch etwas, woran wir noch arbeiten werden. 

Was dann darüber hinausgeht, sind vor allen Dingen die Identifikationen von Abhängigkeiten zu anderen Teams. Das ist natürlich ganz maßgeblich, dass man hier in der Zusammenarbeit mit den anderen Teams herausfindet, ja, wie müssen wir denn umplanen, denn wir warten hier vielleicht für die eine Story noch auf Daten von euch, wann habt ihr das denn eingeplant. Da würden wir empfehlen, dass entweder man das ganze natürlich über Chat macht oder über eigene Video-Räume, wo man sich halt eben dann verabredet, sozusagen, um das zu besprechen. Von unserer Seite, könnte man das sicherlich auch in Confluence über einen Microblog aus dem Linchpin-Universum, das ist ein anderes Produkt von uns, lösen. Das man dann halt eben wirklich einen eigenen Space für das Team hat und in diesem Microblog die wichtigsten Dinge eben schriftlich dokumentiert und dort auch mit einer einfachen @-Mention andere Leute aus anderen Teams, z.B. den Scrum-Master, was man auch immer im Vorfeld ausgemacht hat, erwähnt, und die Person dann informiert wird, ah, guck mal, hier gibt es eine Abhängigkeit offensichtlich zu uns, lass uns da mal irgendwo verabreden und gucken, wie wir das halt irgendwie lösen. Ob wir jetzt irgendwie umplanen, oder die anderen, oder wie auch immer. 

Ja, dann zu guter Letzt, geht es noch um die Bewertung der Risiken in den Teams. Das ist auch relativ unproblematisch. Auch über Vorgangstypen in Jira gelöst. Das lässt sich also auch direkt kollaborativ lösen und da kann man die anlegen und die auch roamen, wie das so schön heißt im SAFe Kontext, also mit entsprechenden Treatments versehen. Und dann ist zum Abschluss wieder im Plenum eigentlich es so, dass Einzelpersonen, die sollte man auch im Idealfall vorher natürlich schon identifiziert haben. Sage hier, kannst du bitte hier unsere Ergebnisse mal vorstellen im Plenum und dann gibt es eben das sogenannte Draft Plan Review, auf dessen Basis dann im Endeffekt das Management über Risiken, Abhängigkeiten, und so weiter, halt eben sprechen kann und das es eben wieder auch im eigenen abgeschlossenen Kanal, die anderen dürfen in der Zwischenzeit dann schon nach Hause gehen und darüber sprechen, okay, wo müssen wir halt eben vielleicht noch einmal was uns neues überlegen, auch von der Managementebene aus.

Und dann gibt es noch den zweiten Tag, den möchte ich nur kurz erwähnen, denn von den Kommunikations-Settings her ist es eigentlich mehr oder weniger dasselbe. Deswegen glaube ich, braucht man da nicht mehr weiter darauf einzugehen. Ein paar Besonderheiten, es gibt noch die sogenannte Confidence-Vote, ich weiß nicht, ob du das kennst. Da geht es im Endeffekt darum, dass eben wirklich alle Beteiligten, also vorher einmal im Team, das kann man im kleinen Kreis machen, aber dann eben auch im großen, der gesamte ART alle Beteiligten ein Votum abgeben, wie realistisch sie denn die Planung des gesamten ARTs halten und dann im Zweifelsfall eben auch noch mal darüber sprechen zu können. Und normalerweise macht dann das eben einfach, in dem man eine Anzahl von Fingern nach oben hält, zwischen 1 und 5, je weniger, umso unrealistischer hält man das Ganze. Und wenn Leute dabei, die eben nur zwei oder weniger Finger hochhalten, dann sollten die noch einmal zu Wort kommen. Das kann man zum Beispiel lösen über Polls, das ist eine Confluence App, sehr leichtgewichtig, da kann man so etwas aufsetzen oder natürlich auch über so etwas, wie den Mentimeter, ich weiß nicht, ob du den kennst?

Matthias:

Ich persönlich nicht, aber vielleicht einige von unseren Zuhörern…

Peter: 

Bestimmt, denn das ist wirklich ein sehr schönes Tool, sehr easy, man kann da Fragen einstellen und kann eben dann über mobile Device die Abstimmung eben laufen lassen und das…

Matthias:

Und die gehen eben dann live rein sozusagen in dieses…

Peter:

Genau, dann kannst du halt eben wirklich live diese Auswirkung und die Grafen eben ablesen und dann eben im Zweifelsfall noch einmal darüber diskutieren, wenn es halt Leute gibt, die halt eben sagen, nein, das geht überhaupt gar nicht, sie dann eben zu Wort kommen lassen, was sie halt für Bedenken haben. Eventuell umplanen, wie auch immer. Das ist also die Confidence-Vote. Vielleicht noch als kurze Ergänzung. In Pulse ist es tatsächlich so, du hast es in Confluence drin und du kannst auch, je nach Konfiguration eben sehen, wer wie abgestimmt hat und kannst dann eben auch gezielt auf die Leute zugehen. Das ist also ganz komfortabel. 

Ja, und dann für die Retrospektive, die ist ja vor allen Dingen für den ART, da würde man vielleicht zumindest noch für die Teams könnte man noch den Retromat empfehlen. Das ist eine sehr schöne Webseite, wo man eben so ein Retro-Format sich immer zusammenstellen kann. Das ist aber eher für die Teams im Nachgang, für die einzelnen Retros in dem Teams. Und im großen, da müsste man vielleicht die Kapazität des Tools noch einmal prüfen, aber so etwas wie Miro. Das ist ein online Whiteboard, das man da wirklich mit den Leute reingeht und tatsächlich zumindest ein bisschen darüber spricht, was war gut, was könnte noch mal irgendwie besser laufen und worauf müssen wir achten. Da gibt SAFe aber auch ein sehr einfaches Format vor. 

Ja, zu guter Letzt, losgelöst jetzt wirklich von den eigentlichen Scaled Agile Vorgaben und Wünschen, würden wir aus unserer Erfahrung heraus, wir haben ja unseren AEC, das ist ein Event mit ungefähr so vielen Leuten, wie ein ART auch tatsächlich, hat, wir sehr kurzfristig, wie du weißt, auch umplanen mussten, nach remote. Was sich da sehr bewährt hat und das ist eine Empfehlung von unserer Seite, ist Moderatoren einzusetzen. 

Matthias:

Ja.

Peter: 

Also es gibt zwar den Release Day Engineer, der so für alles verantwortlich ist, aber der hat sicherlich gerade in so einem Remote Setting noch einmal ganz andere Aufgaben. Der muss sicherlich hin- und herspringen und Fragen beantworten. Insofern ist es natürlich nicht schlecht, wenn man jemanden hat, er ein bisschen publikumsgeeigenet ist, vielleicht mal einen flotten Spruch auf den Lippen. Dann aber auch eben wieder Fragen beantworten kann, das könnten ein, zwei Leute sein, die im Zusammenspiel eben das durch diese Gesamtveranstaltung ganz wertschätzend eben durchführen und dann vielleicht auch in diesem Video-Call des Plenums auch immer als Ansprechpartner da sind. Wenn da irgendwie organisatorische Fragen sind oder so, dass man sich damit nicht alleingelassen fühlt. 

Und alleingelassen fühlt, ist vielleicht auch noch einmal ein Stichwort für den letzten Tipp. Wir würden jedem empfehlen, habt einen IT-Support an den beiden Tagen da. Irgend jemand, den ihr anrufen könnt, wenn nämlich irgendwo jemand rausfliegt oder wo nicht reinkommt oder sonst irgendwas. Das da eben schnell jemand auch angerufen werden kann und Antworten gibt.

Ja, das wärs eigentlich so von meiner Seite, wie wir so ein remote PI-Planning empfehlen können, zusammen mit Agile Hive. 

Matthias:

Also, wir sehen schon, es ist eine gewisse organisatorische und technische Komplexibilität, so ein PI-Planning remote durchzuführen, aber es ist auch machbar. Lass uns doch einmal ein paar Ebenen runtersteigen von diesem Unternehmens-Level auf die persönliche Ebene. Peter, du bist jetzt auch seit, na, bestimmt zwei Wochen im Home Office. 

Peter: 

Ja.

Matthias:

Und kennst diese Situation auch standardmäßig auch eigentlich nicht. Wie kommst du denn klar. Hast du vielleicht ein zwei Tipps für Zuhörer? Hast du irgendwie eine Routine entwickelt, die dir dabei hilft, deinen Arbeitstag im Home Office möglichst effizient und gut zu gestalten? Erzähl mal. 

Peter:

Also tatsächlich, die vielbeschworene Routine habe ich noch nicht so richtig für mich gefunden, muss ich ganz offen gestehen, was auch einfach daran liegt, ich habe zwei Kinder und eine Frau, die hat zum Glück gerade Urlaub. Das macht das ganze etwas einfacher. In der Zeit, wo wir beide noch gearbeitet haben, wir arbeiten ja beide bei Seibert Media, deswegen mussten wir zumindest nicht den Arbeitgeber um Verständnis bitten, der hat das verstanden. Das war das Schöne schon einmal. Aber es ist natürlich schon schwer mit zwei Kindern, die plötzlich zu beaufsichtigen sind, auch noch zwei Arbeitstage irgendwie zu füllen. Jetzt wie gesagt, hat sie Urlaub, das macht es deutlich einfacher. Aber ich bin mir sicher, wir werden für die Zeit nach dem Urlaub und je nachdem, wie lange halt eben Situation noch anhält, uns noch ein paar Routinen überlegen müssen. Also, wer auch immer da draußen gute Routinen hat, mit denen man Kind und Arbeit, remote Arbeit, zusammenbringen kann, bitte sehr gerne her damit.

Matthias:

Gut, dann lass uns an dieser Stelle einen Schnitt machen. Vielen Dank für deine Zeit, Peter. 

Peter:

Ja, ich danke dir. War sehr interessant, auch noch einmal über das Thema zu sprechen, weil gerade wenn man so direkt darüber spricht, fallen einem immer wieder so ein paar Sachen auf. Vielleicht kann ich noch dazu sagen, wir haben auch ein paar positive Rückmeldungen bekommen, dass das so, wie wir das jetzt empfehlen, tatsächlich offensichtlich auch ganz gut funktioniert. Aber jedes Unternehmen muss da sicherlich auch seinen eigenen Weg finden. Wir hoffen aber halt eben, unterstützen zu können. Also danke dir.

Matthias:

Okay. Es gibt zu dem Thema PI-Planning remote Konstellation übrigens auch eine Blogpost von dir. Einfach mal nach Corona-Krise und PI-Planning googeln, ich glaube, dann müsste man direkt auf deinem Artikel landen. Auf jeden Fall vielen Dank fürs Zuhören an unsere Hörer. Ich verweise auf die kommende Podcast-Folge. Dann wollen wir ein paar Ebenen tiefer gehen und uns einmal ansehen, wie ein konkretes Team die Herausforderungen annimmt und bewältigt, die die Corona-Krise so mit sich bringt. Ich hoffe, wir hören uns dann wieder. Bis dahin, bleibt gesund. Tschüss!