PI-Planung in Jira mit Agile Hive

Ist es dir aufgefallen? In Meetings, im Intranet, in der Teeküche, gefühlt überall fällt immer mal wieder beiläufig – und immer häufiger – ein Stichwort: SAFe®. Mehr noch: Es sieht ganz so aus, als würde deine Organisation sich damit beschäftigen, sich auf dieses “Scaled Agile Framework” umzustellen.

Dein Unternehmen nutzt Atlassian-Produkte, darunter Confluence und Jira, und nach allem, was du gehört hast, lässt sich SAFe® innerhalb dieses Software-Ökosystems implementieren. Du hast jedoch auch gehört, dass diese Umstellung mit einigen Herausforderungen verbunden ist.

Aber was genau ist denn SAFe®? Und warum wird darüber diskutiert? Möchtest du im Bilde sein und wissen, was es mit SAFe® konkret auf sich hat? Dieser Beitrag will dir dabei helfen.

Zuerst ein paar Hintergrundinformationen

Das Scaled Agile Framework wurde in seiner ersten Version im Jahr 2011 veröffentlicht. Seine Schöpfer Dean Leffingwell und Drew Jemilo wollten eine Methodik entwickeln, die sich von den damaligen Projektmanagement-Praktiken unterschied. Denn die Geschwindigkeit, mit der sich die Marktbedingungen und der Wettbewerb in vielen Branchen veränderten, hat die Grenzen der gängigen Methoden und Praktiken in großen Unternehmen deutlich aufgezeigt.

Scaled Agile ist ein Ansatz, der – unabhängig von der spezifischen Methodik – eine Reihe von Prinzipien, Prozessen und Best Practices umfasst, die es größeren Unternehmen ermöglichen, agile Methoden auf höhere organisatorische Ebenen auszuweiten und zu skalieren. Dazu gehört alles – von Lean über Kanban bis hin zu Scrum –, was die Entwicklung und Auslieferung hochwertiger Produkte und Dienstleistungen in einem schnelleren Tempo ermöglicht. Alle Teams wissen, was zu liefern ist, und die Kunden haben klare Erwartungen, die erfüllt werden müssen. 

SAFe® ermöglicht jeder Organisation eine unikale Implementierung und Konfiguration der kombinierten Vorteile von Agile-, Lean- und DevOps-Frameworks. Viele Unternehmen tun sich jedoch aus unterschiedlichen Gründen schwer mit der Implementierung: Führung und Belegschaft sind nicht bereit, bestehende Verhaltensweisen und Praktiken zu ändern; sie tragen Bedenken, dass SAFe® auf ihre spezifischen Bedürfnisse zugeschnitten und konfiguriert werden kann; sie haben das Gefühl, dass es an Anleitung oder Unterstützung mangelt. Und dies sind nur einige der am häufigsten auftretenden Bedenken und Missverständnisse im Hinblick auf die Einführung von SAFe®. 

Der Weg zum modernen Softwareunternehmen

Es gibt eine Vielzahl großer und mittelständischer Unternehmen aus fast allen Branchen, die SAFe®  erfolgreich eingeführt haben: FedEx, Chevron, Nokia Software, American Express, Allianz, TV Globo, MetLife, Lockheed Martin und Bosch, um nur einige wenige zu nennen.

Millionen Menschen in über 20.000 Organisationen haben sich SAFe® zu eigen und zum bevorzugten Ansatz für die Skalierung agiler Methoden gemacht.

Die aktuelle Version des Frameworks basiert auf sieben Kernkompetenzen:

• Lean-Agile Leadership
• Team- und technische Agilität
• Agile Product Delivery
• Enterprise Solution Delivery
• Lean Portfoliomanagement
• Organisatorische Agilität
• Kultur des kontinuierlichen Lernens
  
  

SAFe® gibt als Rahmenwerk sehr spezifische Empfehlungen für die Einführung. Zertifizierte SAFe® Program Consultants (SPCs) und Release Train Engineers (RTEs) sind die ersten Ansprechpartner für die richtige Implementierung. Ein Team aus mehreren agilen Teams, bekannt als Agile Release Train oder ART, agiert nahe an der ursprünglichen PDCA-Methode (Plan, Do, Check, Act oder Adjust). Der ART setzt die Räder in Gang und hält sie während des gesamten Prozesses in Bewegung: Definition, Entwicklung, Validierung, Auslieferung – je nach Bedarf wiederholt.

"Das Erreichen von Business Agility und das Ausschöpfen der Vorteile der Lean-Agile-Entwicklung in großem Maßstab ist kein triviales Unterfangen, daher ist SAFe® auch kein triviales Framework. Bevor sie die Vorteile von SAFe® ernten können, müssen Unternehmen ein Lean-Agile-Mindset annehmen und die Lean-Agile-Prinzipien verstehen und anwenden. Sie müssen Wertströme und Agile Release Trains (ARTs) identifizieren, ein Lean-Agile-Portfolio implementieren, Qualität als native Voraussetzung einbauen und die Mechanismen der kontinuierlichen Auslieferung von Wert und von DevOps etablieren. Und natürlich muss sich auch die Kultur weiterentwickeln." Quelle.

Ein genauerer Blick auf die PI-Planung

Um das Framework wirklich zu implementieren, muss regelmäßig das zentrale SAFe-Event stattfinden, das sogenannte Program-Increment-Planning (PI). Traditionell finden diese Plannings vor Ort statt und dienen als Grundlage für den Agile Release Train (ART), um die Teams auf die Vision und die Ziele sowie die Schritte zur Erreichung dieser Ziele auszurichten.

Doch spätestens seit 2020 ist klar, dass es manchmal nicht möglich und praktikabel ist, dutzende oder hunderte Menschen aus aller Welt physisch zusammenzubringen. Diese Veranstaltung geht auf das Agile Manifest zurück, in dem es heißt: "Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht."

Wie erwähnt, findet das PI-Planning traditionell im persönlichen Rahmen statt. Doch in mehr als zwei Jahren Pandemie haben die Leute gelernt, entweder vollständig remote oder in einer hybriden Umgebungen erfolgreich zusammenzuarbeiten – und auch das PI-Planning hat sich weiterentwickelt, um ein Setting zu schaffen, in dem persönliche und virtuelle Zusammenarbeit in Einklang gebracht werden können.

Während die Inputs für die PI-Planung variieren können, gibt es zwei primäre Outputs:

Committed PI Objectives: Dies sind die geschäftlichen und technischen Ziele für jedes Team, die mit Zustimmung und Wertzuweisung durch die Business Owner die Arbeit des Teams für das nächste PI leiten.

Program Board: Dabei handelt es sich um einen “visuellen Strahler", der die Feature-Ausliefertermine, die Feature-Abhängigkeiten zwischen Teams und anderen ARTs sowie relevante Meilensteine beleuchtet.

Die Herausforderungen der Agile-Skalierung in Jira

Bekanntermaßen ist Jira eines der führenden Tools für die agile Softwareentwicklung – eine großartige Lösung, die bei der Umstellung auf die SAFe®-Methodik jedoch ein paar Einschränkungen aufweist. Auf Teamebene funktioniert Jira wunderbar, aber auf der ART-Ebene ist es nötig, die Artefakte Features und Enabler abzubilden. Einfach ausgedrückt, geht es dabei um Dienste oder Produkte, die die Anforderungen von Stakeholdern erfüllen. 

Features bieten Substanz oder einen spürbaren Wert für die User. Enabler legen den Grundstein für die Erweiterung zukünftiger Business- und Feature-Funktionen.

Jira bietet am oberen Ende der Vorgangshierarchie allerdings nur Epics. Deshalb werden Jira-Epics häufig zur Abbildung von Features verwendet. Enabler werden überhaupt nicht unterstützt. Diese Gemengelage hat eine Reihe von Nachteilen. Beispielsweise existiert die SAFe®-Nomenklatur nicht in Jira. Außerdem fehlen wichtige SAFe®-Artefakte, sodass die hierarchische Verknüpfung auf Jira-Epics und ihre Stories beschränkt ist. Mindestens zwei SAFe®-Ebenen werden überhaupt nicht unterstützt. Große Organisationen, die SAFe® einsetzen, sind auf einen starken hierarchischen Kontext angewiesen, um das Alignment des gesamten Unternehmens von der Strategie bis zur Ausführung zu fördern. Kurz: Die Jira-Struktur mit Stories, Epics und Projekten reicht für das Scaled Agile Framework einfach nicht aus.

SAFe® in Jira

Wie oben erwähnt, ist das PI-Planning auf Enterprise-Ebene das zentrale Ereignis, wenn man mit SAFe® arbeitet. Das Event folgt der PI-Kadenz, wobei der Release Train Engineer (RTE), der als eine Art Scrum Master für die gesamte ART fungiert, das Planning moderiert. Weit verbreitet ist ein Zehn-Wochen-Rhythmus.

Nach SAFe® setzt sich ein zweitägiges PI-Planning aus den folgenden Agendabausteinen zusammen:

Quelle

In Jira gibt es für die Skalierung von der Teamebene, auf der die Iterationen stattfinden, auf die Program Increments für ARTs keine Entsprechung für dieses "Team von Teams". Agile Produktentwicklung und Business Agility auf großier Skala erfordern ein hohes Maß an inhaltlicher Zusammenarbeit, Dokumentation und Referenzierung. Hier betritt ein weiteres bekanntes Produkt von Atlassian die Bühne, um seine Stärken einzubringen: Confluence.

An dieser Stelle fragst du dich vielleicht: "Wir sind überzeugt, dass unsere Organisation von der Umstellung auf SAFe® in hohem Maße profitieren würde, aber wie fangen wir an, ohne das Rad neu zu erfinden? Und das möglichst mit den Tools, die uns bereits zur Verfügung stehen?"

Es gibt eine Reihe von Anbietern, die in unterschiedlichem Maße SAFe®-Methoden in das Atlassian-Ökosystem integriert haben. Eine davon ist Agile Hive. Diese Lösung, entwickelt von Seibert Media und Deutschlands führendem SAFe®-Beratungshaus KEGON, nutzt eine starke Interaktion zwischen Jira und Confluence, automatisiert die Arbeit, wo immer es möglich ist, und stellt wertvolle Referenzen wie Epic-Hypothesen, Lean Business Cases oder PI-Planning-Checklisten zur Verfügung. So ermöglicht Agile Hive es, SAFe® umzusetzen, ohne zwischen verschiedenen Tools wechseln zu müssen.

Agile Hive unterstützt sowohl die PI-Vorbereitung als auch Durchführung mit den folgenden Ansichten:

• Team Breakouts
• Team Reports
• Program Board
• Program Reports
• Program Roadmap
• Program Kanban Board

PI-Planung in Agile Hive: ein Einblick

Agile Hive bietet anpassbare Vorlagen und Checklisten direkt in Confluence. Hier kann das Planungsteam einfach die Informationen eintragen, die die Teilnehmer für die Vorbereitung eines effizienten PI-Plannings benötigen.

Auf den Agile-Hive-Boards werden sämtliche Informationen des Plannings erfasst, um vollständige Transparenz auf dem Dashboard herzustellen.

Mit den digitalen Breakout und Program Boards können Benutzer Iterationskapazitäten planen, Features in Stories aufteilen, Story Points schätzen und sich einen Überblick über die Zusammenarbeit im Team verschaffen. Das ist von entscheidender Bedeutung, da jedes Team in der Lage sein muss, Abhängigkeiten zu den Aufgaben der anderen Teams zu identifizieren und zu visualisieren. Nur dann sind die Teams in der Lage, effektiv gemeinsam an Lösungen zu arbeiten. Agile Hive bietet den Usern jederzeit einen einfachen Überblick, einschließlich der korrekten hierarchischen Verknüpfung, ohne dass sie von Ticket zu Ticket springen müssen.

Die Program Roadmaps bieten die Möglichkeit, ARTs und PIs auf Programmebene direkt auf der Zeitachse per Drag & Drop zu planen. Das Planen, Verschieben, Sortieren und Definieren von Zeiträumen erfordert nur wenige Klicks. Die PI- und Termindetails passen sich dabei automatisch an und werden entsprechend in den Tickets abgebildet.

Bist du bereit für den nächsten Schritt?

Wenn du genug Vertrauen in die Kraft deiner Organisation hast und sicher bist, dass es sich lohnt, den nächsten Schritt zu machen, stehen dir vielerlei SAFe®-Assets zur Verfügung. 

Die Scaled Agile, Inc. unter der Leitung von Chief Methodologist Dean Leffingwell, dem Schöpfer von SAFe®, hat im Web umfangreiche Ressourcen, Kundenberichte und Schulungsmaterialien rund um das Scaled Agile Framework bereitgestellt. Die Website enthält hunderte, wenn nicht tausende von Seiten mit Informationen und Tipps, die deinem Unternehmen den Einstieg erleichtern. 

Oft ist es sinnvoll und zielführend, bei der SAFe®-Adaption von Anfang an mit erfahrenen SAFe Program Consultants zusammenzuarbeiten, die deine Organisation als Change Agents betreuen und tiefes Wissen über das Scaled Agile Framework einbringen.

Die Implementierung von SAFe® ist ein umfangreiches, fortlaufendes Projekt mit einigen Herausforderungen. Unternehmen, die sich diesem Vorhaben stellen, eröffnet sich die Chance, mehr Dynamikrobustheit zu erreichen und den Weg zu echter Business Agility einzuschlagen.

Wir unterstützen Unternehmen dabei, noch besser zu werden und ihre Ziele noch effektiver zu erreichen. Sie haben konkrete Fragen zum  SAFe® oder wünschen sich eine ganzheitliche Einführung in die Welt der agilen Methoden? Kontaktieren Sie uns für weitere Informationen.