Squads

Beginnen wir mit den Squads. Diese sind vergleichbar mit einem Scrum-Team und bilden die Grundlage des Spotify-Modells. Squads sind selbstorganisierte agile Teams, in denen alle notwendigen Ressourcen vertreten sind, die es benötigt, um ein Produkt oder eine Dienstleistung von Anfang bis Ende zu entwickeln. Natürlich verfügt jedes dieser Teams auch über einen Product Owner, der für das Backlog und die Priorisierung verantwortlich ist. Außerdem steht jedem Squad ein Agile Coach zur Verfügung, um das Team methodisch zu unterstützen und Events wie Retrospective oder Planning zu organisieren.

Tribes

Ein Tribe umfasst mehrere Squads, die gemeinsam an einem Produkt oder einer Dienstleistung arbeiten. Es gibt einen sogenannten Tribe Lead, der dafür sorgt, dass die Squads bestmöglich zusammenarbeiten können. Es gibt regelmäßige Treffen, bei denen sich die Squads untereinander austauschen können und ihre Arbeit präsentieren können, sodass alle auf dem aktuellsten Stand sind.

Chapters

Ein Chapter umfasst Mitarbeiter mit demselben Fachwissen. Diese sind verteilt auf die unterschiedlichen Squads innerhalb der Tribes. Auch Chapter verfügen über ein Chapter Lead, der regelmäßige Treffen organisiert um einen Austausch untereinander zu ermöglichen.

Guilds

Guilds wiederrum sind Zusammenkünfte von Mitarbeitern mit denselben Fähigkeiten oder Interessengebieten aus verschiedenen Tribes. Der sogenannte Guildkoordinator kümmert sich darum, dass Treffen stattfinden, bei denen sich die Mitglieder der Guilds austauschen können. Dies hat einen großen Vorteil für die Verbesserung der Organisation.

Nochmal kurz zusammengefasst

Nach dem Spotify-Modell wird eine Organisation in Tribes unterteilt, die verantwortlich für die Entwicklung eines Produkts oder einer Dienstleistung sind. Innerhalb eines Tribes werden Mitglieder mit unterschiedlichen Fachkenntnissen (Squads) zur eigenständigen Entwicklung eines Produktes oder einer Dienstleistung zusammengebracht. Außerdem werden Mitglieder mit denselben Fachkenntnissen zusammengebracht, sowohl innerhalb eines Tribes (Chapter) als auch tribe-übergreifend (Guilds) zum Erfahrungsaustausch zur Weiterentwicklung.

Anders als wir es von Frameworks wie beispielsweise Scrum kennen, gibt es keine Praktiken, die befolgt werden müssen oder verpflichtende Termine, die abgehalten werden müssen. Die Squads organisieren sich selbt, wie sie am besten ihre Arbeit erledigen. Das kann sowohl durch den Einsatz des Scrum-Frameworks, Kanban oder anderen Methoden passieren.

Ebenso bestimmen Chapters und Guilds selbst, wie sie ihre Zusammenarbeit am Besten gestalten möchten.

Jetzt können Sie auf die Frage, ob Ihnen das Spotify-Modell ein Begriff ist, vertraut mit einem Ja antworten.

Beginnen wir mal von Anfang an, was ist Kanban überhaupt und wie ist es entstanden?

Der Erfinder des Toyota-Produktionssystems, Taiichi Ohno, hat 1947 Kanban entwickelt und es handelt sich dabei um eine Umsetzung des als Pull-Prinzip bekannten Steuerungsverfahren in der Produktion.

Inspiriert wurde er dabei durch den Ablauf beim Befüllen der Regale in Supermärkten. Denn im Supermarkt werden gerade so viele Produkte gelagert, um die Nachfrage der Konsumenten zu befriedigen. Die Lagerbestände stimmen mit den Verbrauchergewohnheiten der Kunden überein. Dadurch wird vermieden, dass überschüssige Ware gelagert wird und Platz für benötigte Ware belegt wird. Es ist simpel und führt zu großer Effizienz bei der Lagerverwaltung.

Diesen Prozess hat Taiichi Ohno also nun in die Toyota-Produktion übernommen. Der Zyklus beginnt mit der Anlieferung der benötigten Materialien inklusive Kanban-Karte an die verbrauchende Stelle. Sobald die Materialien aufgebraucht wurden, wird die Kanban-Karte an die zuständige liefernde Stelle zurückgeführt. Hier beginnt die Produktion bzw. Beschaffung der benötigten Materialien in der angegebenen Menge und sobald dies erreicht wurde, werden die Materialien wieder inklusive Kanban-Karte an die verbrauchende Stelle gesendet. Damit wurde ein sich selbst steuernder Regelkreis ohne zentrale Planungsinstanz geschaffen.

Die bei diesem System genutzte Technologie hat sich natürlich in den letzten Jahre weiterentwickelt, aber dennoch bildet es den Kern der sogenannten Just-in-Time-Fertigung.

Wie wird Kanban heute in der Software-Entwicklung angewandt?

Prinzipiell ist die Kanban-Methode in jeder Branche einsetzbar aufgrund seiner zeitlosen Kernprinzipien, die nachfolgend im Detail erläutert werden. Im Bereich der Software-Entwicklung hat die agile Methode jedoch besondere Erfolge erzielt, denn hier sind keine Aufwände zur Umsetzung, wie beispielsweise die Veränderung physischer Prozesse, notwendig. Es wird lediglich ein Board mit Karten benötigt, welches durchaus virtuell abgebildet werden kann.

Übrigens, das Wort Kanban kommt aus dem Japanischen und heißt wörtlich übersetzt visuelles Signal.

Nicht ohne Grund ist Kanban neben Scrum eine der am weitesten verbreiteten agilen Management-Methoden. Damit die agile Methode aber auch richtig funktioniert, gehört doch etwas mehr als nur ein Board und Karten dazu.

Das Kanban-Board steht natürlich im Mittelpunkt. Es ist dafür da, die Aufgaben zu visualisieren und den Workflow des Teams zu optimieren. Ein einfaches Kanban-Board besteht aus den drei Schritten To-Do, in Progress, Done. Je nach Größe, Struktur und Ziele eines Teams kann der Workflow entsprechend erweitert oder angepasst werden. Die Kanban-Karten bilden die zu erledigenden Aufgaben ab und deren Fortschritt wird transparent am Board abgebildet. Die Kanban-Karten liefern Informationen zu der Art der Aufgabe, wer ist verantwortlich für die Aufgabe, wie lange dauert diese schätzungsweise etc.

Nachdem wir verstanden haben, welche Prinzipien hinter Kanban stecken, schauen wir uns nun die sechs Praktiken an, die uns dabei helfen, große Erfolge mit der Kanban-Methode zu erzielen.

1. Machen Sie die Arbeit sichtbar
   Um die Arbeit, den Workflow und Risiken zu visualisieren, dient das Kanban-Board. Die Arbeit wird durch die Karten am Board dargestellt, der Workflow wird durch die Spalten von links nach rechts beschrieben und die Risiken sind oft im Detail der Karten zu erkennen, aber oftmals auch visuell, wie beispielsweise durch zu viele Tickets in der Doing-Spalte.
2. Limitieren Sie den Work-in-progress (WIP)
   Die Begrenzung des WIP führt dazu, dass nie zu viel und nie zu wenig Arbeit vorhanden sind, sodass genau die richtige Anzahl an Karten von den vorhanden Ressourcen bearbeitet werden kann. Erreicht wird das durch das Pull-Prinzip, bei dem neue Arbeit nur dann gezogen wird, wenn ausreichend Kapazitäten vorhanden sind. Damit dies funktioniert, muss das WIP-Limit gesetzt und angepasst werden.
3. Manage Flow
   Flow meint die Bewegung der Arbeit durch den Workflow von links nach rechts. Der Projektmanager ist dafür verantwortlich, einen schnellen Durchfluss zu gewährleisten und gleichzeitig Blockaden und Risiken im Auge zu behalten. Je besser der Flow, desto effizienter arbeitet das Team.
4. Machen Sie Prozessregeln explizit
   Damit alle in dieselbe Richtung blicken und Diskussionen rational und objektiv geführt werden können, braucht es Richtlinien. Diese müssen dokumentiert und mit allen geteilt werden.
5. Führen Sie Feedback-Mechanismen ein
   Feedback und kontinuierliche Verbesserung sind ausschlaggebend bei Kanban wie auch bei allen anderen agilen Frameworks. In der Kanban-Methode eignen sich dafür die Meeting-Kadenzen, die Sie für sich angesetzt haben. Das einzig obligatorische Meeting ist das Daily Kanban. Hier geht es darum, täglich einen Blick auf den Flow zu werfen und Blockaden und Hindernisse zu erkennen und aus dem Weg zu räumen. Weitere Meetings, wie beispielsweise Refinement, Retrospective, Planning, oder Review werden bei Bedarf geplant.
6. Gemeinsam verbessern, experimentell weiterentwickeln
   Bei Kanban gehen Zusammenarbeit und Experimente Hand in Hand, solange es Klarheit und Konsens darüber gibt, wie an Arbeit und Probleme herangegangen werden soll.

Also, starten Sie genau da wo Sie gerade sind, achten Sie auf die Prinzipien, wenden Sie die Praktiken an und erzählen Sie uns von Ihren Erfolgen!

Was ist eigentlich ein PI Planning?

Kurze Begriffsdefinition

Grundsätzlich steht der Begriff „PI Planning“ für „Program Increment Planning“. PI Planning Sessions sind regelmäßig abgehaltene Events, die das ganze Jahr über stattfinden und bei denen sich mehrere Teams innerhalb eines Agile Release Trains (ART) treffen, um eine gemeinsame Vision zu finden, Features zu besprechen, die Roadmap zu planen und teamübergreifende Abhängigkeiten zu identifizieren.

Die wesentlichen Elemente eines PI Plannings sind:

• Zwei ganztägige Events, die alle acht bis zwölf Wochen stattfinden (je nach Länge deiner Increments aka Planungsabschnitte)
• Produktmanager arbeiten daran, die geplanten Features für das Increment im Voraus zu priorisieren
• Entwicklungsteams sind für die Planung und Bewertung der User Story zuständig
• Engineers und UX-Teams validieren die Planung
• Ziel ist es, die Teams auf die Mission und aufeinander abzustimmen
• Jeder nimmt (sofern möglich) persönlich teil
• Technologie wird (falls notwendig) verwendet, um verteilten Teams die Teilnahme zu ermöglichen

Wenn Sie SAFe zum ersten Mal anwenden, beginnen Sie vermutlich mit dem PI Planning. Das liegt daran, dass dieser Planungsansatz die Grundlage für das Scaled Agile Framework™ bildet.

Tipps an verteilte Teams und Remote PI Planning

Falls Ihr Team nicht bei jedem vierteljährlichen PI Planning Meeting persönlich anwesend sein kann, sollten Sie sich mit der Umsetzung eines Remote-PI Planning Events befassen. Keine Sorge – auch das ist problemlos machbar und ideal für Unternehmen mit verteilten Teams oder flexiblen Arbeitsregelungen. Außerdem sind solche Meetings viel günstiger, als alle Teilnehmer alle paar Monate einfliegen zu lassen.

Wenn Sie über die richtigen Tools und Technologien verfügen, können Sie PI Planning Events veranstalten, an denen jeder teilnehmen kann – egal, ob vor Ort oder auf der anderen Seite der Welt.

Hier einige Tipps, die Ihnen dabei helfen:

Nutzen Sie die Cloud

Verwenden Sie gemeinsam nutzbare Online-Planungstools, damit Ihr Team so schnell wie möglich auf Informationen zugreifen und mit ihnen interagieren kann – im Idealfall sogar in Echtzeit. Indem Sie sicherstellen, dass jeder Teilnehmer die Informationen sofort einsehen kann, lassen sich Abhängigkeiten leichter identifizieren und das unnötige Speichern der Infos an zehn oder mehr Orten vermeiden.

Finden Sie sich vor Ort zusammen

Versuchen Sie, dass sich alle Beteiligten soweit möglich an einem Standort versammeln und sich dann gemeinsam einwählen (anstatt jeweils von ihren eigenen Locations aus remote teilzunehmen). Sie könnten etwa im Hauptsitz die Führungsgruppe sowie die Teams aus der Nähe zusammenbringen und dann Mitarbeiter an anderen Orten zu ihrem nächstgelegenen Remote-Standort einfliegen lassen. So profitiert jeder vom Aspekt der persönlichen Zusammenarbeit.

Übertragen Sie das Event als Livestream

Persönliche Zusammenarbeit ist natürlich immer vorzuziehen. Falls das nicht möglich ist, sollten Sie auf einen Audio- und Video-Livestream des Events und der Teilnehmer setzen. Das bedeutet auch, dass alle verteilten oder Remote-Teams ihre Kameras und Mikrofone während des Events nutzen sollten. Es ist zwar nicht ganz dasselbe wie ein physisches Meeting, kommt dem aber schon ziemlich nahe.

Zeichnen Sie das Event auf

Im Idealfall nimmt jeder live am PI Planning teil. Allerdings kann es vorkommen, dass Teams über mehrere Zeitzonen verteilt sind oder bestimmte Teilnehmer aus Krankheits- oder anderen unvorhergesehenen Gründen nicht dabei sein können. Daher ist es sinnvoll, das Event aufzuzeichnen. Davon profitieren auch Teammitglieder, die selbst teilgenommen haben, aber ihr Gedächtnis auffrischen möchten.

Passen Sie sich an

Einige Teams werden die standardmäßige PI Planning Agenda anpassen, damit sie mit mehreren Zeitzonen kompatibel ist. Das kann bedeuten, dass das Event für manche früher oder später beginnt oder sogar über drei statt zwei Tage verteilt stattfindet.

Legen Sie Regeln fest

Häufig kommt es bei verteilten Teams, die sich remote per Video und Audio einwählen, zu Störungen und Hintergrundgeräuschen. Kommunizieren Sie vor der ersten Session, wann Teams sprechen dürfen und wann sie ihr Mikro stummschalten sollten. So stellen Sie sicher, dass jeder aktiv teilnehmen kann und Ihr Team nicht abgelenkt wird.

Warum ein PI Planning?

Ein PI Planning ist für große und zudem agile Unternehmen von unschätzbarem Wert. Sehen wir uns einige Zahlen an, um uns die Bedeutung vor Augen zu führen.

Nehmen wir als Beispiel etwa Organisationen mit 200 bis 300 Teams und 10.000 Entwicklern: In der Vergangenheit hatten diese Teams meist nie Kontakt miteinander (zumindest nicht, bis ein größeres Problem auftrat, das die Kommunikation untereinander zwingend notwendig machte).

Früher fand die Abstimmung auf Ebene der Führungsteams statt. Dazwischen gab es mehrere Managementebenen, welche die Informationen kaskadenartig nach unten weitergaben. Die Mitarbeitenden in den Teams haben jedoch meist nicht direkt miteinander gesprochen. Es gab einen ständigen Kampf um Ressourcen, Budget und Möglichkeiten, an den attraktivsten Projekten zu arbeiten. Apropos Projekte – hier kam es nicht selten zu Konflikten: Ein Team veröffentlichte etwas, und plötzlich funktionierte aufgrund dessen etwas im Projekt eines anderen Teams nicht mehr.

Beim PI Planning werden die Teams dieser wirklich großen Unternehmen erstmals in einem Raum oder im selben Call versammelt und können sich untereinander austauschen. So haben sie Gelegenheit, die so wichtigen Gespräche darüber zu führen, wer woran arbeitet.

Das ist ziemlich wichtig, denn:

• Wenn Sie etwas an einem System oder einem Code-Repository ändern, müssen Sie wissen, wie sich dies auf ein anderes Team auswirkt.
• Es kann sein, dass Sie zuerst etwas erledigen müssen, bevor ein anderes Team an seinem Feature arbeiten kann (und umgekehrt).

Was sollte in die PI Planning Agenda aufgenommen werden?

Die Standardvorlage einer PI Planning Agenda, wie sie auf der SAFe-Website zu finden ist:

Tag 1

• 08:00 – 09:00 Uhr Businesskontext
• 09:00 – 10:30 Uhr Produkt-/Lösungsvision
• 10:30 – 11:30 Uhr Architekturvision und Entwicklungspraktiken
• 11:30 – 13:00 Uhr Planungskontext und Mittagessen
• 13:00 – 16:00 Uhr Team-Breakouts
• 16:00 – 17:00 Uhr Review des Planentwurfs
• 17:00 – 18:00 Uhr Managementreview und Problemlösung

Tag 2

• 08:00 – 09:00 Uhr Planung von Anpassungen
• 09:00 – 11:00 Uhr Team-Breakouts
• 11:00 – 13:00 Uhr Abschließende Planreview und Mittagessen
• 13:00 – 14:00 Uhr Programmrisiken
• 14:00 – 14:15 Uhr Confidence Vote
• ab 14:15 Uhr Nachbearbeitung des Plans (falls erforderlich)
• wenn bereit: Planungsretrospektive und Zukunftsaussichten

Quelle der Agendavorlage: Scaled Agile Framework™

Vielleicht passt diese Agenda für Sie bereits perfekt, oder Sie möchten sie den Bedürfnissen Ihres Teams entsprechend anpassen. Beides ist selbstverständlich in Ordnung: Verteilte Teams, sehr große Agile Release Trains und andere Faktoren haben gegebenenfalls zur Folge, dass Sie mit der Planung etwas kreativer werden müssen. Es kann sein, dass einige Sessions mehr Zeit erfordern, während andere gekürzt werden können.

Falls es sich um Ihr erstes PI Planning Event handelt, probieren Sie einfach die Standardagenda aus, holen Sie Feedback bei Ihrem Team ein und experimentieren Sie beim nächsten Mal mit verschiedenen Formaten.

Betrachten wir nun die einzelnen Punkte der Agenda etwas genauer – insbesondere die ersten Stunden einer PI Planning Session an Tag 1.

Was wird im ersten Teil des PI Planning Meetings erreicht?

Tag 1 beginnt normalerweise mit der Präsentation eines Senior Executives oder des Business Owners. Die Agenda sieht eine Stunde für die Besprechung des aktuellen Geschäftsstands vor. Im Rahmen dessen werden spezifische Kundenbedürfnisse aufgezeigt. Daneben wird erläutert, wie die aktuellen Produkte diese abdecken, und gegebenenfalls werden potenzielle Lücken aufgedeckt.

Danach stellt das Produktmanagementteam die aktuelle Vision für das Produkt oder die Lösung vor. Es bespricht alle Änderungen, die seit der letzten PI Planning Session (in der Regel etwa drei Monate zuvor) eingetreten sind. Es folgt ein Ausblick auf die Zukunft, mitunter auf die Meilensteine und die nächsten zehn Features. Diese Session sollte etwa 1,5 Stunden dauern. Im ersten Teil des PI Planning Meetings geht es allein um das große Ganze. So wird ein wichtiger Kontext für die Planung geschaffen, die im Anschluss folgen muss.

Springen wir als nächstes etwas nach vorn und betrachten wir einen wichtigen Schritt am Ende des Meetings.

Warum wird am Ende des PI Planning Meetings ein Confidence Voting abgehalten?

Das Confidence Voting ist ein scheinbar kleiner, aber doch sehr wichtiger Teil des PI Planning Meetings. Das Confidence Voting wird am Ende beinahe jedes PI Planning Events abgehalten. Der Release Train Engineer fragt: „Werden wir die Ziele erreichen?“

Jeder im Raum muss per Handzeichen (und mit seinen Fingern) abstimmen. Beträgt die durchschnittliche Stimmzahl im Raum mindestens drei Finger, so erhält der Plan grünes Licht. Sind es weniger, muss er überarbeitet werden (bis ein höheres Vertrauenslevel erreicht wird). Wer nur mit einem oder zwei Fingern abstimmt, erhält die Gelegenheit, eine Begründung für diese Entscheidung mitzuteilen.

Beim Confidence Vote geht es darum, sicherzustellen, dass die Teilnehmer sich einig sind, den Plan in seiner aktuellen Form innerhalb des vorgegebenen Zeitrahmens umsetzen zu können.

Apropos Timing: Sprechen wir darüber, wie und wo das PI Planning in den Unternehmenskalender passt.

Wann findet ein PI Planning statt?

Viele Unternehmen sind der Ansicht, dass acht bis zwölf Wochen (was vier bis sechs zweiwöchige Iterationen ergibt) die richtige Dauer für einen Planungsabschnitt sind. Andere Unternehmen führen hingegen vierteljährlich ein PI Planning Meeting durch, beispielsweise:

• Q4 PI Planning: September
• Q1 PI Planning: Dezember
• Q2 PI Planning: März
• Q3 PI Planning: Juni

Zeitpunkt und Häufigkeit hängen davon ab, wie lange die einzelnen Program Increments dauern sollen (und müssen ggf. mit Feiertagen in Einklang gebracht werden). Der Vorteil von PI Planning Events ist, dass sie regelmäßig nach einem festen Zeitplan stattfinden.

Das bedeutet, dass man sie weit im Voraus planen kann – was wiederum dazu führt, dass die Teams und Business Owner ausreichend Zeit haben, um ihre Anwesenheit sicherzustellen. Entsprechend sind die Vorbereitungen für das PI Planning ebenso entscheidend wie das Event selbst.

Was ist ein Pre-PI Planning Event und wann ist es notwendig?

Die Vorbereitung in Form eines Pre-Planning-Events – zusätzlich zum PI Planning – hat einen wichtigen Hintergrund: Sie soll sicherstellen, dass der ART im Rahmen des weiteren Solution Train ausgerichtet ist, bevor ein PI Planning durchgeführt wird. Es geht darum, sich mit den anderen ARTs abzustimmen, um sicherzustellen, dass das Projekt und das Unternehmen sich gemeinsam auf eine Ausrichtung fokussieren.

Ist ein Pre-PI Planning für Sie sinnvoll?

Sie sollten ein Pre-PI Planning Event organisieren, wenn Sie auf Ebene der Large Solution, des Portfolios oder von Full SAFe arbeiten. Essential SAFe ist eher rudimentär ausgerichtet und verfügt über keinen Solution Train. Wenn Sie also auf dieser Ebene agieren, ist kein Pre-PI Planning erforderlich.

Normalerweise finden sich die Schlüsselpersonen aus dem Solution Train mit den Vertretern der Agile Release Trains und den relevanten Suppliern zusammen. Hier einige Personen, die Sie auf dem Planning-Event antreffen werden:

• Solution Train Engineer
• Solution Management
• Solution Architect/Engineering
• Solution System Team
• Release Train Engineers
• Produktmanagement
• System Architects/Engineers
• Kunden

Diese Personen werden gemeinsam die zentralen Potenziale des Solution Backlog, des Solution Intent, der Vision und der Solution Roadmap näher betrachten. Das Ganze ähnelt dem PI Planning sehr, findet aber auf einer höheren Ebene statt und deckt die gesamte Lösung und nicht nur den individuellen ART ab.

Das Event beginnt damit, dass jeder ART sein vorheriges Program Increment und seine Leistungen zusammenfasst, um einen Kontext zu schaffen. Anschließend informiert ein Senior Executive die Teilnehmer über die derzeitige Situation, bevor das Solution Management die aktuelle Lösungsvision und etwaige Änderungen gegenüber den vorherigen Mitteilungen diskutiert.

Zu den weiteren Aspekten, die im Rahmen des Events oft diskutiert oder finalisiert werden, zählen mitunter:

• Roadmaps
• Meilensteine
• Solution Backlogs
• künftige PI-Features aus dem Program Backlog

Kehren wir nun zum regulären PI Planning zurück: Es ist an der Zeit, einige bereits angesprochene zentrale Begriffe genauer zu definieren.

Was hat SAFe mit PI Planning zu tun?

Wie bereits erwähnt steht die Abkürzung SAFe für „Scaled Agile Framework™“.

Was ist der Unterschied zwischen einer PI Roadmap und einer Solution Roadmap?

Es gibt verschiedene Arten von Roadmaps im Rahmen von SAFe, und es ist wichtig, die Unterschiede und Funktionen zu verstehen.

Die PI Roadmap wird vor dem PI Planning erstellt und nach Abschluss des Events vom Produktmanagement überprüft sowie aktualisiert. Sie umfasst in der Regel drei Program Increments:

• das aktuelle Increment (festgelegte Arbeit)
• das nächste prognostizierte Increment (geplante Arbeit auf Grundlage der prognostizierten Ziele)
• das darauffolgende Increment (weitere geplante Arbeit auf Grundlage der prognostizierten Ziele)

Wenn Sie vierteljährlich ein PI Planning Meeting durchführen, umreißt das die Arbeit für etwa neun Monate. Das zweite und dritte Increment Ihrer PI Roadmap wird sich wahrscheinlich abhängig von Ihren Prioritäten ändern. Doch beide sind dennoch ein wichtiger Teil der Roadmap, da sie einen Ausblick darauf geben, in welche Richtung sich das Produkt entwickeln wird.

Die Solution Roadmap ist ein Tool zur längerfristigen Prognose und Planung eines bestimmten Produkts oder einer bestimmten Dienstleistung. Sie deckt in der Regel mehrere Jahre ab, wobei für das erste Jahr spezifischere (z. B. vierteljährliche Features und Potenziale) und für das zweite Jahr und darüber hinaus allgemeinere Informationen (z. B. Ziele) zur Verfügung stehen.

Jetzt, wo wir Roadmaps, Scrum und SAFe behandelt haben, sollten wir uns eine weitere Definition ansehen, die Ihnen dabei hilft, PI Planning in das Gesamtbild von Agile und SAFe einzuordnen.

Was ist ein Program?

Ein Program fasst mehrere kleinere agile Teams zu einer größeren Gruppe zusammen. Dies wird oft als „Team of Teams“-Ebene bezeichnet. Wenn jemand von „Team of Teams” oder „Scaled Agile“ spricht, meint er, dass Agile über ein einzelnes Team hinausgeht und man weitere Teams zur Mitarbeit einlädt.

Beispiel:
Nehmen wir an, vier Teams arbeiten an einer NASA-Raumschiffmission für die Reise zum Mars. Die NASA beschließt, zu testen, ob der Agile-Ansatz die Arbeit dieser Teams verbessern würde. Daher wird zunächst das Sauerstoffteam vom traditionellen Wasserfallprojektmanagement auf Agile-Prinzipien umgestellt:

• Startteam
• Lebensmittelteam
• Sauerstoffteam (Agile)
• Landungsteam

Nach ein paar Monaten ist die NASA der Ansicht, dass die Arbeitsweise des Sauerstoffteams wirklich gut funktioniert. Daher stellen die drei anderen Teams ebenfalls auf Agile um.

• Startteam – Agile!
• Lebensmittelteam – Agile!
• Sauerstoffteam – Agile!
• Landungsteam – Agile!

Jedes dieser vier Teams organisiert sich selbst und ist damit für seine eigene Arbeit verantwortlich. Da diese Teams nun aber alle auf dieselbe Weise arbeiten, können sie zu einem Programm zusammengefasst werden.

Einfach ausgedrückt ist ein Programm also eine Gruppe von Agile-Teams. Sobald die Business Owner, das Produktmanagementteam, die System Architects bzw. -Engineers und den Release Train Engineer hinzukommen, sind alle Rollen abgedeckt, die für eine kontinuierliche System- oder Lösungsbereitstellung über den Agile Release Train erforderlich sind.

Behandeln wir nun eine letzte Definition.

Was ist ein Program Board?

Program Boards stellen einen wichtigen Teil von SAFe und des PI Plannings dar.

Wer sollte am PI Planning beteiligt sein?

Es gibt fünf Schlüsselrollen, die am PI Planning mitwirken:

• Release Train Engineers
• Produktmanager
• Product Owner
• Scrum Master
• Entwickler

Sehen wir uns genauer an, wofür jede dieser Rollen während des Events verantwortlich ist.

Release Train Engineer

Der Release Train Engineer ist ein Servant Leader und Coach für den ART. Seine Rolle besteht hauptsächlich aus der Planung und Umsetzung des PI Planning Events. Das heißt, Release Train Engineers helfen bei:

• der Erstellung und Kommunikation der Jahresplanung
• der Vorbereitung sämtlicher Aspekte des PI Plannings (einschließlich der Pre- und Post-PI Planning Meetings)
• der Verwaltung der Risiken und Abhängigkeiten
• der Erstellung von Program PI Objectives aus Team PI Objectives und der Veröffentlichung derselben
• der Nachverfolgung des Fortschritts in Richtung der erwarteten Ziele
• der Ausrichtung von Strategie und Ausführung
• der Ermöglichung von Systemdemos

Als „Veranstalter“ des zweitägigen Events stellt der Release Train Engineer den Planungsprozess sowie die erwarteten Ergebnisse vor und ermöglicht die Management-Review, die Problem-Solving-Session sowie die Retrospektive.

Produktmanager

Die Aufgabe eines Produktmanagers besteht darin, die Bedürfnisse der Kunden zu verstehen und Lösungen zu validieren. Gleichzeitig soll er Portfolioarbeit nachvollziehen und unterstützen.

Welche Rolle spielt ein Produktmanager nun beim PI Planning?

Er präsentiert die Vision des Programms (d. h. die zehn wichtigsten anstehenden Features) sowie alle kommenden Meilensteine. Er überprüft den Planentwurf und legt sämtliche Änderungen an der Planung selbst sowie an deren Umfang auf Grundlage der Management-Review sowie der Problem-Solving-Session dar. Auf diese Weise kann der Produktmanager den Arbeitsfluss steuern und Prioritäten setzen. Nach Abschluss des PI Planning Events verwendet er die Program Objectives des Release Train Engineers, um die Roadmap zu aktualisieren.

Es sollte darüber hinaus erwähnt werden, dass der Produktmanager auch am Pre- und Post-PI-Planning beteiligt ist. Vor dem eigentlichen PI Planning findet ein Pre-PI Planning Meeting statt, bei dem der Produktmanager und andere ART-Vertreter, die Teil desselben Solution Train sind, die Beiträge, Ziele und Meilensteine für ihre nächsten PI Planning Events diskutieren und definieren.

Im Rahmen des Post-PI Planning Meetings treffen sich die Vertreter des ART erneut, um den Verlauf ihrer PI Planning Events zu diskutieren und die Ergebnisse in den Solution PI Objectives zusammenzufassen. Produktmanager spielen eine zentrale Rolle bei der Kommunikation der Ergebnisse und der Erstellung der Ziele.

Product Owner

Die Product Owner sind für die Wartung und Priorisierung des Team Backlog sowie für Iteration Planning verantwortlich. Sie haben die Autorität, während der PI Planning Team Breakout Sessions Entscheidungen auf der Ebene der User Story zu treffen.

Product Owner unterstützen das Team bei der Definition der Stories, der Einschätzung und der Sequenzierung sowie bei der Ausarbeitung der PI Objectives des Teams und der Teilnahme am Team Confidence Voting. Sie sind auch dafür verantwortlich, dem Team Visionen und Ziele aus den oberen Managementebenen zu vermitteln:

• Berichterstattung über wichtige Leistungskennzahlen
• Auswertung des Fortschritts
• Kommunikation des Status an die Stakeholder

Scrum Master

Scrum Master sind Servant Leader des Product Owner und des Entwicklerteams, d. h. dass sie neben der Verwaltung und Leitung von Prozessen dem Team auch praktisch dabei helfen, Aufgaben zu erledigen.

Sie wirken an der Event-Vorbereitung (einschließlich PI Planning) mit und bereiten Systemdemos vor. Sie helfen dem Team bei der Einschätzung der Iterationskapazität, bei der Festlegung der Team PI Objectives sowie bei der Verwaltung des Zeitrahmens, der Abhängigkeiten und der Unklarheiten während der Team-Breakout-Sessions. Die Scrum Master nehmen auch an Confidence Votings teil, um das Team dabei zu unterstützen, einen Konsens zu erreichen.

Entwickler

Entwickler sind für die Erforschung, den Entwurf, die Implementierung, das Testen, die Wartung und die Verwaltung von Softwaresystemen verantwortlich.

Während des PI Plannings nehmen sie an Breakout-Sessions teil, um (gemeinsam mit ihrem Product Owner) User Stories sowie Akzeptanzkriterien zu erstellen und zu verfeinern. Sie passen darüber hinaus auch den Arbeitsplan an. Die Entwickler tragen zur Identifizierung von Risiken sowie Abhängigkeiten bei und unterstützen das Team bei der Ausarbeitung und Finalisierung der Team PI Objectives, bevor sie am Team Confidence Voting teilnehmen.

Nun kennen Sie die wichtigsten Definitionen. Außerdem wissen Sie auch, was während eines PI Planning Events unternommen werden muss und wer dabei nicht fehlen darf.

Wie bereitet man sich auf ein PI Planning vor?

„By failing to prepare, you are preparing to fail.“ – Benjamin Franklin

Erfolgreiches PI Planning erfordert entsprechende Vorbereitungen, die Sie nicht unter den Tisch fallen lassen sollten! Jedes PI Planning Event fußt auf einer durchdachten Planung. Nur so können Ihr Unternehmen und alle Teilnehmer das Beste daraus machen und die angestrebten Ziele erreichen.

Wie sieht diese Vorbereitung also konkret aus?

Die Teilnehmer selbst (sowie die wichtigsten Stakeholder und die Business Owner) müssen Schlüsselrollen zuweisen, die Ausrichtung an der Strategie sicherstellen und dafür sorgen, dass alle den Planungsprozess richtig verstehen.

Alle Vortragenden müssen einschlägige Inhalte für ihre Präsentationen vorbereiten.

Außerdem müssen Sie dafür sorgen, dass Ihre Räumlichkeit für das Event gewappnet sind – insbesondere, wenn Sie hunderte Teilnehmer erwarten. Hierbei müssen die üblichen Vorbereitungen für eine Veranstaltung getroffen werden, insbesondere dem technischen Aspekt (Audio, Video, Internetverbindung) sollten Sie ein erhöhtes Maß an Aufmerksamkeit zukommen lassen, damit etwaige verteilte Teams am PI Planning Event teilnehmen können. Vergessen Sie darüber hinaus nicht, für genügend Essen zu sorgen (Planen macht hungrig).

Nun wissen wir ziemlich genau, was vor und während eines PI Planning Events geschehen muss, doch wie steht es um die Nachbereitung?

Was macht man nach dem PI Planning?

Im Anschluss an das PI Planning Meeting erstellen die Teams eine Planungsretrospektive und listen auf:

• was gut gelaufen ist („leckere Snacks“),
• was nicht so gut gelaufen ist („nicht genügend Snacks“) und
• was man das nächste Mal besser machen könnte („ehm, bitte lass in Zukunft auch Kekse für die anderen über“).

Anschließend folgt ein Gespräch über die nächsten Schritte. Mitunter zählen hierzu:

• das Einpflegen von Kopien der Objectives, der User Stories und des Program Boards ins Projektmanagement-Tool (z. B. Jira)
• ein Blick auf die Kalender
• die Absprache der Meeting-Zeiten und -orte für Daily Standups und Iterationsplanung
• das Überprüfen der persönlichen Gegenstände und das saubere Hinterlassen des Veranstaltungsorts

Daneben findet nach einem PI Planning Event in der Regel auch ein Post PI Planning Event statt.

Was ist Post PI Planning?

Post PI Planning Events ähneln den bereits besprochenen Pre-PI Plannings. Hierunter fällt die Zusammenführung der ART-Stakeholder über alle Agile Release Trains innerhalb des Solution Train hinweg. Das soll sicherstellen, dass diese aufeinander abgestimmt sind.

Das Post PI Planning findet statt, nachdem sämtliche ARTs ihr PI Planning für das nächste Increment abgeschlossen haben. Sie stellen die Pläne vor, erklären ihre Ziele und teilen Meilensteine und erwartete Zeitpläne mit.

Wie bei PI Planning Events wird auch bei Post PI Planning ein Planning Board verwendet – das jedoch keine Features, sondern Potenziale, Abhängigkeiten und Meilensteine für jede Iteration und jeden ART aufzeigt. Mögliche Probleme und Risiken werden identifiziert, diskutiert und entweder zugeteilt, gelöst, akzeptiert oder entschärft.

Ähnlich wie bei regulären PI Planning Events werden die Pläne mithilfe eines Fist-of-Five-Vertrauensvotums (auch Fist to Five genannt) geprüft, um sicherzustellen, dass sie die Solution Objectives erfüllen. Sie werden so lange überarbeitet, bis im Durchschnitt drei Finger hochgehalten werden.

Häufige Fehler und Herausforderungen

Ein PI Planning verläuft nicht immer … nun ja, nach Plan und auch das Framework als solches kann eine Herausforderung für einige Unternehmen darstellen. Nachfolgend beschreiben wir einige Fehler und Herausforderungen, die Sie im Hinterkopf behalten (und falls möglich vermeiden) sollten:

Lange, langweilige Sessions

Zu den größten Schwachpunkten des PI Planning im Rahmen der vorgeschlagenen Agenda zählen die langwierigen, anstrengenden Sessions direkt zu Beginn. Es lohnt sich eventuell, nach kreativen Möglichkeiten zu suchen, wie diese Sessions interessanter gestaltet, die Informationen zum Businesskontext in einem anderen Format präsentiert oder die veranschlagten Zeiträume verkürzt werden können. Auf diese Weise bleibt mehr Zeit für die Teamplanung und Zusammenarbeit.

Technische Probleme

Jedes Event ist anfällig für technische Pannen. Aber wenn Sie Audio- und Video-Streams an ein verteiltes Team übertragen, können derartige Störungen den Ablauf des gesamten Meetings maßgeblich beeinflussen. Es ist ratsam, alle Geräte und Verbindungen im Vorfeld sorgfältig zu testen, um das Risiko potenzieller Probleme zu minimieren.

Confidence Voting

Einige Teilnehmer tun sich mit dem Konzept des Confidence Votings schwer. Möglicherweise fühlen sie sich von den anderen Anwesenden unter Druck gesetzt, für einen Plan zu stimmen, anstatt ihre Bedenken zu äußern. Das sollten Sie beachten.

Zeitbeschränkungen

Wenn ein ART aus – sagen wir mal – zwölf Teams besteht, müssen eine ganze Menge Pläne präsentiert und überprüft werden. In solchen Fällen ist es wahrscheinlich, dass die Qualität des Feedbacks schlechter ausfällt als bei einem kleineren Agile Release Train mit acht Teams.

Sich nicht auf den Prozess einlassen

Weder SAFe noch das PI Planning sind perfekt. Doch der Prozess hat sich in zahlreichen Unternehmen bewährt. Es ist wichtig, sich an das Framework zu halten und Ihr PI Planning Event gemäß den Empfehlungen durchzuführen. Halten Sie sich unbedingt an den anschließenden Prozess.

Beibehalten alter Tools

Wenn etwas nicht funktioniert, dann sollten Sie sich des Problems annehmen. Beispielsweise halten viel zu viele Teams an traditionellen SAFe Program Boards fest, obwohl diese nicht immer sinnvoll sind. Wenn die Haftnotizen ständig verloren gehen, die in Jira eingegebenen Daten ein wenig daneben zu liegen scheinen oder Sie ein verteiltes Team haben, das sich eine digitale Teilnahmemöglichkeit für Ihr PI Planning Event wünschen … dann ist es an der Zeit, auf ein digitales Program Board wie Easy Agile Programs zu wechseln.

Apropos Software: Nun ist (endlich) Jira an der Reihe!

Einsatz von Jira im PI Planning

Jira ist das beliebteste Projektmanagementtool für Agile-Teams. Wenn Sie agil sind, setzen Sie es wahrscheinlich bereits auf Teamebene ein. Jira eignet sich perfekt für Einzelteams.

Wenn Sie Agile jedoch auf Skalierungsebene als Teil eines ART implementieren möchten, kann die korrekte Visualisierung der Arbeit über mehrere Teams hinweg ein Problem darstellen. Die einzige Möglichkeit, dies in der nativen App von Jira zu realisieren, ist die Erstellung eines Multi-Projekt-Boards, welches allerdings ziemlich unübersichtlich ist.

Wie passt Jira also mit SAFe und dem PI Planning zusammen?

Das PI Planning bringt diese Teams zusammen, um auf Grundlage gemeinsamer Ziele die Arbeit für das nächste Increment zu planen. Während des PI Plannings verwenden die Teams ein Program Board, um ihre Arbeit zu organisieren und Abhängigkeiten zu identifizieren. Traditionell wird dazu ein physisches Board mit Haftnotizen und einer Schnur verwendet. Nach der Session werden die Notizen und die Schnur in Jira für das gesamte Team nachgebildet. Das kann mühsam und zeitaufwändig sein und lässt oft einen Großteil des Kontexts außer Acht.

Der beste Weg, Jira für das PI Planning zu verwenden, ist der Einsatz einer App wie Easy Agile Programs, die Sie bei der Durchführung deiner PI Planning Sessions unterstützt.

Die integrierten Features ermöglichen es Ihnen:

• ein digitales Program Board einzurichten (nie wieder Schnur und Haftnotizen!),
• teamübergreifend zu planen,
• teamübergreifende Abhängigkeiten zu visualisieren und zu verwalten,
• sich an den festgelegten Zielen für das Program Increment auszurichten,
• eine Increment Feature Roadmap zu visualisieren und
• Jira von einem Tool auf Teamebene zu einem Werkzeug für den gesamten ART zu transformieren.

Puh, das war jetzt ganz schön viel Inhalt.
Sie haben weitere Fragen? Dann kommen Sie gerne auf uns zu.

Bessere Ergebnisse durch agile Softwareentwicklung

Scrum findet insbesondere (aber längst nicht mehr nur) in der agilen Softwareentwicklung Einsatz. Dort gibt die Methode als Rahmenwerk feste Rollen und Abläufe für den Prozess der Softwareentwicklung vor. Das Ziel ist klar: schnellere Ergebnisse erzielen und verwendbare Software produzieren. Um das zu erreichen, definiert der Scrum Guide drei Rollen: den Scrum-Master, den Product Owner und die Entwickler:innen.

Kurz gesagt,

• verantwortet der PO Definition- und Verfolgung der Produktziele, den Produktnutzen sowie Priorisierung und Kommunikation des Backlogs,
• sorgt der Scrum Master für die Einführung und Einhaltung der Scrum Regeln
• und setzen die Entwickler:innen die vom Product Owner vorgegebenen Produkteigenschaften um.

In Summe bilden diese Funktionen das Scrum-Team. Was dabei auffällt: Ein Proxy PO ist hier nicht vorgesehen.

Rolle und Grenzen des Product Owners

Der PO ist verantwortlich für die Wertmaximierung des Produkts und vertritt die Produktvision. In der Regel ist dieser auf Seiten der beauftragenden Firma angesiedelt, während Scrum Master und Development Team auch vom Dienstleister kommen können. In seiner Funktion kümmert sich der PO entsprechend um die Kommunikation mit den Stakeholdern und die fachliche Steuerung des Development-Teams. Eine der wichtigsten Aufgaben ist die Aufbereitung des Product Backlogs, damit dieses jederzeit in einem brauchbaren Zustand ist.

In der Theorie klingt das nach einer übersichtlichen Menge an Tätigkeiten (Spoiler: es ist verdammt viel Arbeit). Hinzu kommt, dass in einer idealen Welt…

• POs 100 % der Arbeitszeit für das Projekt verfügbar sind.
• POs die „Sprache” der Entwickler:innen sprechen.
• es nicht das erste Entwicklungsprojekt als PO ist und er Erfahrung mit Softwareentwicklung hat.
• POs ein entsprechendes Standing, Ansehen und Vertrauen in der Kundenorganisation haben sollten – idealerweise ist der PO produktverantwortlich.

Die Realität ist aber leider oft eine andere und der vom Kunden gestellte PO kann die Rolle nicht voll ausfüllen. Die Ursachen hierfür können viele Hintergründe haben:

• POs haben häufig keine Zeit, um dringende Fragen des Development-Teams zu beantworten und Feedback zu geben.
• POs sind im Fachbereich fit. Es fällt ihnen aber schwer zu vermitteln, was sie möchten. Sie haben weniger Erfahrung mit Priorisierung und wissen schlimmstenfalls nicht, was gebraucht wird.
• Der Titel „Product Owner” wird immer wieder unbedarft vergeben, wenn ein Projekt ansteht – auch zusätzlich zur eigentlichen Aufgabe desjenigen und/oder ohne Weiterbildungsangebot.
• Der Product Owner verfügt über wenig Rückhalt in der Organisation (oder glaubt, keinen zu haben).

Die Auswirkungen eines wenig optimalen PO-Setups sind zahlreich: Zeitdruck gleich zu Projektbeginn, zusätzliche Arbeitslast für das Development-Team sowie unklare Verantwortlichkeiten und eine fehlende Produktvision.

Der Alltag unterscheidet sich also oft von den Idealbedingungen. Nicht umsonst schreibt der Scrum Guide diesen Umstand anerkennend: The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

An dieser Stelle kommt der Proxy PO ins Spiel.

Was ist ein Proxy PO und wie kann er helfen?

Der Begriff „Proxy“ geht auf den lateinischen Ausdruck „proximus“ zurück und bedeutet „der Nächste“, was die Rolle des Proxy PO schon erahnen lässt: Ein Proxy Product Owner befindet sich zwischen denen, die Entscheidungen über ein Produkt treffen und denen, die das Produkt entwickeln. Man betrachtet ihn als eine unvollständige Version des Product Owners.

Ein Proxy PO führt in der Regel Tätigkeiten aus, die normalerweise von einem PO erledigt werden. Dazu gehören:

• Erfassen der Kundenbedürfnisse
• Erstellen von User Stories
• Definition und Priorisierung des Backlogs
• Planung der Umsetzung der Backlog-Items (zusammen mit dem Team)
• Entscheidung, wann die Increments für die Kunden freigegeben werden

Kurzum: Mithilfe des Proxy Product Owners lässt sich die Arbeitslast für den Product Owner erleichtern und die Arbeitsorganisation verbessern. Im besten Falle bildet der Proxy PO mit dem Product Owner ein Team. Wichtig ist aber zu beachten, dass der Proxy PO kein zweiter PO ist!

Der Proxy PO…

• ist nicht der Eigentümer des Produkts. Er trifft weder die Hauptentscheidungen über das Produkt noch ist er wirklich für dessen Erfolg verantwortlich.
• kontrolliert nicht das Produktbudget.
• definiert nicht die Vision oder Strategie des Produkts.
• hat nicht das letzte Wort über das Backlog und seine Items.

Es muss also intern (und extern) Klarheit herrschen, wann das „Original“ und wann der Stellvertreter angesprochen wird, und wie lange die Stellvertretung oder Vermittlung andauert (kurzfristig oder dauerhaft, temporär und situativ oder kontinuierlich).

Ein weiteres Szenario neben einer „Vertretung“ des PO durch den Proxy-Product Owner ist das PO-Coaching. Hier unterstützt der Proxy PO vor allem durch Beratung, gerade bei methodischen Fragen. PO-Coaching ist vor allem dann hilfreich, wenn der Product Owner über Zeit für die Rolle, Fachwissen und eine klare Vision für das Produkt verfügt, aber zu wenig Erfahrung mit den Aufgaben eines POs an sich hat.

So entscheiden Sie, ob ein Proxy PO für dein Projekt Sinn macht

Das Etablieren eines Proxy POs im Projekt kann klare Vorteile für die agile Softwareentwicklung bringen. Die Produktentwicklung lässt sich in einem komplexen Umfeld besser organisieren, der Proxy PO kann seine Fähigkeiten einbringen und der PO seine Skills ausbauen.

Dennoch empfehlen wir, nicht „blind“ auf einen Proxy PO zu setzen. Stattdessen sollte an erster Stelle immer das gemeinsame Gespräch zwischen Kunde und Dienstleister stehen. Die folgenden Themen sollte man klären:

• Welche Aufgaben müssen im Bereich Product Ownership im Verlauf der Produktentwicklung erfüllt werden, damit das Projekt erfolgreich sein kann?
• Inwieweit kann der Kunde diese Erwartungen erfüllen – sowohl bezüglich Befähigung als auch der Verfügbarkeit seines POs?
• Falls Lücken zu erwarten sind, empfiehlt es sich als nächstes, gemeinsam zu definieren, in welcher Form Unterstützung geleistet werden soll. Hier kann der Proxy PO eine Antwort sein.
• Zum Projektstart sollten die Rollen, Verantwortlichkeiten und Erwartungen besprochen und dokumentiert werden.
• Im Verlauf des Projekts ist dann regelmäßig zu prüfen, ob die Vereinbarungen auch erwartungsgemäß erfüllt werden.

Unsere Teams schätzen dieses Vorgehen in Projekten sehr und verhelfen unseren Kunden auch damit zum Erfolg. Wir sind von der agilen Arbeitsweise überzeugt und stellen gern das passende Team für Ihr technisches Vorhaben zusammen.