Inside
26. September 2019

SupplyOn schwört agile Entwicklungsteams auf die nächsten sechs Sprints ein

Passende Themen: agile Organisation, Lace Team, SAFe

Engagierte Zusammenarbeit und Diskussionen bilden den Kern der vierteljährlichen PI Plannings, die die Weichen für unsere agile Softwareentwicklung in den kommenden Wochen stellen
Engagierte Zusammenarbeit und Diskussionen bilden den Kern der vierteljährlichen PI Plannings, die die Weichen für unsere agile Softwareentwicklung in den kommenden Wochen stellen

„Ich habe hier noch zwei User Stories mit insgesamt 12 Story Points, die ich in meinem Team nicht unterbringe“ äußert Martin Weber, Product Manager, gegenüber seinem Kollegen. „Das gehört zu einem Feature von SupplyOn Project Management, dein Team kennt sich damit doch auch aus. Geht bei dir noch etwas?“

Unterhaltungen wie diese sind der Herzschlag unserer PI-Plannings (PI = Product Increment). Erst kürzlich trafen sich wieder rund 100 Kollegen aus 16 agilen Scrum-Teams in der Nähe des Münchner Flughafens, um die Softwareentwicklung der nächsten zwölf Wochen zu planen.

Mehr als 100 internationale Kollegen aus 16 agilen Teams kommen zum PI Planning
Mehr als 100 internationale Kollegen aus 16 agilen Teams kommen zum PI Planning

Im Frühjahr diesen Jahres ist SupplyOn in die nächste Stufe der agilen Softwareentwicklung eingestiegen, um die zahlreichen Scrum-Teams noch besser übergreifend koordinieren zu können. Seitdem nutzen wir das branchenerprobte Scaled Agile Framework SAFe, das meine Kollegin in einem anderen Blog-Beitrag bereits beschrieben hat.

Klare Strukturen sorgen für klare Orientierung

So haben die Product Manager nun schon zum dritten Mal in diesem Jahr die Kundenanforderungen in weit mehr als 100 Features heruntergebrochen, um diese in den agilen Teams zur Umsetzung einzuplanen. Die konkrete und verbindliche Planung dieser Features erfolgt dann anhand von User Stories in dem so genannten PI Planning, einem zweitägigen Event. PI steht dabei für das in sechs jeweils zweiwöchige Sprints aufgeteilte Program Increment. Das PI Planning hat eine feste, immer wiederkehrende Agenda, wie alles bei SAFe. Cadence, der feste Rhythmus, spiegelt sich in SAFe im Ablauf der Wochen und der Termine wieder. Er bietet Mitarbeitern einen klaren Rahmen und unterstützt die Konzentration auf den Inhalt.

Startschuss für das PI Planning

Stefan Brandner eröffnet das PI Planning
Stefan Brandner eröffnet das PI Planning

Die Wiedersehensfreude unter den Teilnehmern, die normalerweise über viele Länder verteilt arbeiten, ist immer groß. Nach Kaffee, süßen Teilchen und Obst eröffnet Dr. Stefan Brandner, Mitglied des Vorstands der SupplyOn Gruppe das PI Planning pünktlich um 9:00 Uhr. Nachdem er beim letzten Mal einem Vortag zu den aktuellen Herausforderungen unserer Kunden gehalten hatte, erläutert er dieses Mal die vier Säulen von SAFe und deren Nutzen für SupplyOn und die Kunden. Natürlich kennen alle diese Säulen aus den SAFe-Schulungen der letzten Monate. Aber sich diese Kernbotschaften kurz vor der Planung der nächsten 12 Wochen nochmals ins Gedächtnis zu rufen, gibt der Veranstaltung den richtigen Schub.

Es schließen sich die Business Owner an, die die Entwicklungsschwerpunkte in ihren Bereichen vorstellen. Danach präsentieren die einzelnen Product Manager ausgewählte, vornehmlich übergreifende Features.

Applaus – großes Programm für die nächsten Wochen!

PI Planning – Tag 1

Angeregte Diskussionen an den Team Boards...
Angeregte Diskussionen an den Team Boards…

10:55 Uhr: Der Release Train Engineer (RTE) beendet nach einigen Hinweisen zum weiteren Ablauf die gemeinsame Auftaktveranstaltung. Die Teams sammeln sich um ihre Tische. Die Product Manager erläutern weitere Features, bevor es in die Team Breakouts geht. Hier bewertet dann jedes Team die in einzelne User Stories runtergebrochenen Features und plant diese in die jeweiligen Sprints auf seinem Team Board ein.

... und vor den Rechnern
… und vor den Rechnern

Dabei werden Abhängigkeiten zu anderen Teams geklärt und auf dem Program Board mit Fäden visualisiert. Alle 75 Minuten treffen sich die Scrum Master der Teams um mit dem RTE die Fortschritte der Planung zu besprechen und möglichst schnell Lösungsmöglichkeiten zu finden.

Die Product Manager planen die nächsten Schritte mit ihren Teams
Die Product Manager planen die nächsten Schritte mit ihren Teams

15:30 Uhr – Draft Plan Review: Die Teams stellen dem Business Owner ihre Planungen vor, adressieren Risiken und fordern Entscheidungen ein.

17:00 Uhr: Die Teams machen sich auf den Abend gemeinsam zu verbringen, in München, Landshut, oder wo immer es der Product Owner geplant hat. Die Business Owner und Product Manager müssen bleiben und die angeforderten Entscheidungen treffen – auch wenn es länger dauern kann. Aber die Teams müssen am nächsten Tag planen können. Heute sind die Alternativen in zweieinhalb Stunden bewertet und entschieden.

PI Planning – Tag 2

Plananpassungen am zweiten Tag
Plananpassungen am zweiten Tag

9:00 Uhr: Die Product Manager stellen dem Plenum die getroffenen Entscheidungen vor und die Teams starten unmittelbar damit, diese in ihre Planungen einzuarbeiten.

Die Zeit drängt, nur noch bis 14:00 Uhr ist Zeit.

Ein Timer zeigt an, wieviel Zeit noch bleibt
Ein Timer zeigt an, wieviel Zeit noch bleibt

Bis dahin müssen auf den Team Boards die User Stories in die sechs Sprints eingeplant, die Risiken klar formuliert und zugeordnet sowie Business Objectives formuliert sein. Die vom Team formulierten Business Objectives sind eine konsolidierte Rückmeldung an den Business Owner, um sicherzustellen, dass das Team die Erwartungen auch richtig verstanden hat.

Letzte Änderungen
Letzte Änderungen

Außerdem müssen noch die Abhängigkeiten auf dem Program Board und die übergreifenden Risiken auf dem Risk Board vermerkt werden.

Die letzten Minuten laufen und die letzten Anpassungen auch.

Nun ist es 14:00 Uhr und der Final Plan Review startet.

Aufmerksame Zuhörer: Die Business Owner während der Vorstellung der finalen Pläne
Aufmerksame Zuhörer: Die Business Owner während der Vorstellung der finalen Pläne

Wie beim Draft Plan Review stellen die Teams dem Business Owner die nun fertigen Pläne vor. Die anderen Teams hören zu und prüfen, ob es doch noch unerkannte Abhängigkeiten gibt.

Anschließend werden die Program Risks durchgesprochen und die PI Confidence Vote veröffentlicht. In der Confidence Vote gibt jedes Team auf einer Skala von 1 bis 5 an, für wie gut umsetzbar sie den Plan für ihr Team halten. Je größer die Zahl, desto besser. Im Schnitt hat der SupplyOn Release Train dieses Mal eine 3,4 erreicht. Eine Wertung unter Drei würde einen bedeuten, dass der Plan noch einmal überarbeitet werden müsste. Doch das ist hier bei keinem Team der Fall. Das dritte PI Planning bei SupplyOn kann also erfolgreich geschlossen werden.

Jedes PI Planning endet mit einer Feedbackrunde. Hier besprechen wir ganz offen, was gut lief und wo und wie wir uns das nächste Mal verbessern können
Jedes PI Planning endet mit einer Feedbackrunde. Hier besprechen wir ganz offen, was gut lief und wo und wie wir uns das nächste Mal verbessern können

Das Ende ist der Anfang

Aufbruchstimmung.

Aber langsam, vorher noch alle Boards fotografieren und dann zusammenpacken. In den nächsten Tagen müssen die Teams die Planung in Jira, ein Planungssystem, überführen und das PI mit seinen sechs Sprints kann starten.

 

Florian, Mitglied des LACE-Teams (Lean-Agile Center of Excellence), dem agilen Transformationszentrum für die SAFe-Implementierung bei SupplyOn

florian

Florian Rotter

Senior Manager Product Development SRM & Portal

Mit meinem Team bin ich für die Konzeption und Umsetzung der Lösungen auf der Internet-Plattform SupplyOn im Bereich Einkauf, Lieferantenqualitätsmanagement, Lieferantenmanagement und Portal zuständig. Unser Anspruch ist dabei, dass unsere Kunden mit diesen Lösungen ihre Prozesskosten in der Zusammenarbeit mit Ihren Lieferanten signifikant reduzieren und gleichzeitig die Prozessqualität steigern. Ich schreibe über die Anforderungen unserer Kunden und mit welchem Nutzen wir sie abgebildet haben sowie unsere Transformation zu agilen Entwicklungsprozessen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Zum Seitenanfang