Verloren im Jira Dschungel

Auf der Suche nach Unterstützung für die agilen Entwicklungsteams haben viele Unternehmen in den letzten Jahren Jira eingeführt. Während die Akzeptanz bei den Entwicklern im Allgemeinen gut ist, habe ich in persönlichen Gesprächen mit Projektmanagern (PM), Product Ownern (PO), Business Analysten (BA) und Requirements Engineers (RE) oft „Schmerzen“ wahrgenommen. Fast alle äußerten sich etwa so: „Die Zahl der Jira Issues wächst und wächst. Wir verlieren uns in einem Dschungel aus Details und erkennen das große Ganze nicht mehr. Wo stehen wir eigentlich? Sind wir noch auf dem richtigen Weg? Bauen wir wirklich das, was die Stakeholder wollen und brauchen, um ihre Ziele zu erreichen? Wir wissen es nicht.“

Nachfolgend stelle ich Ihnen ein Mittel gegen diese Schmerzen vor. Zuvor aber müssen wir eine grundlegende Frage beantworten:

Wo ist aus organisatorischer Sicht eine geeignete Schnittstelle zwischen den Planungsaufgaben von PM, PO, BA, RE und der Arbeit agiler Entwicklungsteams?

Natürlich ist jede Organisation anders. Aber in den Organisationen, die Business Agilität anstreben, findet man wiederkehrende Vorgehensweisen und Ergebnisse. Ein Beispiel dafür ist die iterative Entwicklung einer Business Strategie, die die wichtigsten strategischen Themen der Organisation beschreibt. Die Business Strategie steckt den Rahmen für die Planung innovativer Produkte und Services ab. An ihrer Entwicklung sind vor allem in großen Organisationen häufig Business Analysten beteiligt. Um die Business Strategie umzusetzen, werden Projekte, Programme oder Portfolios aufgesetzt – ich möchte hier allgemeiner von Initiativen sprechen.

Zu einer Initiative gehört immer eine Vision der angestrebten Lösung. Sie dient als roter Faden für alle, die an einer Initiative beteiligt sind. Zusätzliche Orientierung schafft die Definition des Lösungskontextes und die Beschreibung der angestrebten Ziele der Stakeholder. Beides sind Bestandteile des Big Picture der Lösung. Darüber hinaus gehören zum Big Picture gelegentlich Business Use Cases und – häufiger –Epics, also Stakeholder-Anforderungen an die Lösung auf hohem fachlichem Niveau einschließlich ihrer Beziehungen und Abhängigkeiten untereinander. Beteiligt an der Entwicklung des Big Picture sind vor allem der PM bzw. PO unterstützt durch REs. In einigen Organisationen gehört auch der Entwurf der Makro-Architektur der Lösung zum Big Picture. Hier sind die Solution Architects gefordert.

Sobald das Big Picture stabil ist, geht es darum, die Release-Strategie festzulegen. Dazu gehören unter anderem die Entscheidungen darüber, welche Features in welchem Release geliefert werden sollen. Mit diesem Schritt werden vom PM bzw. PO unter Mitwirkungen von REs die Weichen für die Entwicklung gestellt. Benötigt werden dazu das Product Backlog, die Release Backlogs und ein einheitlicher, nachvollziehbarer Planungsworkflow.

Sind erste Entscheidungen über die mit einem Release zu liefernden Features gefallen, ist die Basis für die Iterations- bzw. Sprintplanung und die anschließende Realisierung der Features gegeben. Das heißt, hier beginnt die Verantwortung der agilen Entwicklungsteams. Aus organisatorischer Sicht ist dies ein sinnvoller Startpunkt für den Einsatz von Jira. Damit verbunden ist allerdings die Frage:

Wie kann man die Planungsaufgaben von PM, PO, BA und RE bis zu diesem Punkt so unterstützen, dass beim Übergang zum Einsatz von Jira das Big Picture nicht verloren geht und der gesamte Weg nachvollziehbar bleibt?

Die kurze Antwort: mit objectiF RPM.

Im Langtext lautet die Antwort: Als PM, PO, BA und RE finden Sie in objectiF RPM alles, was Sie für den Weg von der Vision über das Big Picture bis hin zur Release Planung brauchen, also Artefakte, grafische Modelle, Backlogs, Workflows und unterstützende Funktionen. Außerdem können Sie Stand und Fortschritt einer laufenden Initiative in Echtzeit auswerten.

Bleibt noch die Frage zu beantworten, wie sich Zusammenarbeit mit den Entwicklungsteams gestaltet. Also:

Wie sieht die Schnittstelle zu Jira inhaltlich aus?

Bei der Release Planung mit objectiF RPM zerlegen Sie Epics und Feature Requirements in Stories einer von Ihnen bestimmten Granularität. Diese Stories übergeben Sie den Entwicklungsteams für die Iterationsplanung in Jira und die anschließende Realisierung. Dazu legen Sie die Stories in einem speziellen „Austauschordner“ ab. Aus Sicht von objectiF RPM bedeutet die Übergabe den Export der Stories im Austauschordner nach Jira.

Entsprechend funktioniert auch der Rückweg, also die Rückmeldung aus Jira über den aktuellen Entwicklungsstand der Stories.

Die Synchronisation zwischen objectiF RPM und Jira können Sie nach einem festen Zeitplan steuern oder spontan durchführen. Die Frage „Wo stehen wir im Projekt?“ können Sie als PM bzw. PO in objectiF RPM per Echtzeitauswertung und mit einem Blick auf Ihr Projekt-Dashboard sofort beantworten. Darüber hinaus ist die Traceability vom Big Picture bis zur Jira Story jederzeit gegeben.

Im nachfolgenden Video zeige ich Ihnen, wie die Arbeit mit objectiF RPM in Kombination mit Jira konkret aussieht.

 

Das knappe Fazit lautet …

Keine Angst vor dem Jira Dschungel. Stattdessen objectiF RPM kennenlernen.

 

Quelle:

[POA2021]  Die Darstellung der agilen Planungshorizonte orientiert sich an der Begriffsbildung des International Institute of Business Analysis IIBA und speziell am Guide to Product Ownership Analysis, herausgegeben vom IIBA 2021