Scaled Agile Framework (SAFe) mit Jira umsetzen

Workflows, Bildschirmmasken (Screens) und Vorgangstypen (Issuetypes) müssen gemäß dem SAFe-Framework so konfiguriert werden, dass SAFe in allen Bereichen der Organisation, Solution etc. berücksichtigt wird. Hierbei sollte auch der Einsatz verschiedener Tools wie „Roadmaps“ und „Structure“ beachtet werden. Das ist vor allem deshalb wichtig, weil es eine Entscheidung darüber erfordert, ob der Issuetype „Epic“ oder zusätzlich ein eigens nach SAFe-Prinzipien erstellter Issuetype, „Feature“, genutzt wird. Die Frage, die also primär gestellt werden muss, lautet:

Welche Hierarchie nutzen wir für unsere SAFe-Struktur in Jira?

• Die von Jira vorgegebene (Initiative, Epic, Story, Subtask)
• Eine gemäß SAFe konfigurierte Lösung (Epic, Feature, Story)

Zudem sollte die Aufteilung der Jira-Projekte die Bereiche der SAFe-Organisation widerspiegeln. Eine Möglichkeit besteht darin, für jeden Release Train ein eigenes Projekt einzurichten, in dem es für die untergeordneten Teams eigene Boards gibt. Durch eine gut durchdachte Konfiguration der Bildschirmmasken und angezeigten Felder können die Aufgaben der Teams in den Boards klar voneinander getrennt werden (siehe unten).

In die Status-Quo-Analyse sind, besonders für den Fall, dass es bereits Jira-Strukturen vor der speziell nach SAFe ausgerichteten Konfiguration gab, ebenfalls die Arbeitsweisen der Teams und Release Trains einzubeziehen. Hierunter ist zu verstehen, dass z. B. Felder, die für bestimmte Teams bei der Angabe ihrer Informationen als essenziell angesehen werden, in der Konfiguration berücksichtigt werden. Dies kann ebenfalls einen Status in bisher genutzten Workflows betreffen, der im geplanten SAFe-Rahmen eventuell keinen Platz findet. Falls solche teaminternen Besonderheiten in der neuen SAFe-Struktur nicht implementiert werden können, weil ihre Solution-weite Standardisierung Komplexitäten aufweist, liegt es am Berater- und Changemanager-Team, Alternativen zu finden.

Bei der Konfiguration der neuen SAFe-Umgebung ist mit den Stakeholdern (z. B. auf Solution-Ebene und weiteren Verantwortlichen, die eine Arbeit nach SAFe-Prinzipien sicherstellen) abzustimmen, welche Workflows als Standards für die Vorgangstypen gewählt werden, um eine einheitliche Arbeitsweise zu schaffen.

Da in SAFe-Organisationen Rollen-Hierarchien existieren, sind ebenfalls Konfigurationen zu wählen, die eine adäquate Berichterstattung ermöglichen. Ein Beispiel ist die Implementierung von Feldern innerhalb der SAFe-Vorgangstypen, die genau angeben, welches Team bzw. welcher Release Train an einer Aufgabe oder einem Aufgabenpaket arbeitet. Bei der Einrichtung von Dashboards und Filtern zu anderen Zwecken können dadurch präzise Aufgaben der verschiedenen Arbeitsbereiche der SAFe-Organisation herausgelesen werden.

Auch wenn eine Organisation bereits nach SAFe gearbeitet hat, kann die Umstellung der Atlassian-Produkte auf das SAFe-Framework viele Veränderungen mit sich bringen. Hierbei sollten die User in ihren Teams und Release Trains langsam an die neuen Strukturen herangeführt werden. Da es in der Organisation entsprechende „Agile Coaches“ gibt, die für die Einhaltung der SAFe-Strukturen zuständig sind, ist es ratsam, mit diesen zusammenzuarbeiten.

In Meetings mit den Atlassian-Administratoren bzw. den Changemanagern sollten im Laufe der Einführung der neuen SAFe-Umgebung auch Solution/Release Train Engineers sowie Scrum Master einbezogen werden. Da es nach dem SAFe-Konstrukt die entsprechenden Meetings (SoS und SoSoS) gibt, können genau diese dazu genutzt werden, um Veränderungen zu besprechen, welche die Agile Coaches an ihre Teams weiterleiten.

Um SAFe sicher einzuführen, sollten auf übersichtlichen Dokumentationsseiten in einem Knowledge-Hub wie etwa Confluence sowohl technische als auch inhaltliche Anleitungen gepflegt werden, die die User jederzeit abrufen können. Das eignet sich hervorragend für neue Nutzer, die z. B. in ihren ersten Wochen mit der Arbeitsweise nach SAFe in Kombination mit den Atlassian-Tools geschult werden müssen.