Jira und Confluence oder auch MS Azure DevOps, sind derzeit (Stand Mai 2021) die bevorzugten Werkzeuge zur technologischen Unterstützung des agilen Projektgeschehens. Nur selten trifft man heute auf andere Werkzeuge in Scrum-, LeSS- oder SAFe-Projekten. Nachdem Methoden aber nur einen Framework – ein Skelett / eine mehr oder minder grobe Vorgehensbeschreibung – darstellen, werden sie auch in unterschiedlichen Projekten immer ein wenig verschieden zur Anwendung gebracht. Sollen die Werkzeuge – die Tools – die Methode in optimaler Art und Weise unterstützen, sollte deren Setup an die jeweilige Vorgehensweise angepasst werden.
Ergo:
Wenn der Tool-Setup die Methode nicht in optimaler Art und Weise unterstützt, leidet der Output darunter.
Wovon SAFe spricht, was Jira dazu sagt und was die Praxis zeigt
SAFe spricht von Epics, Features und Capabilities, von Objectives und auch von User Stories; vom Portfolio Backlog, Program Backlog, von Team Backlogs und noch vielem mehr.
Jira sagt dazu: Du kannst Projekte und Boards anlegen, so viel Du brauchst und möchtest.
Die Praxis zeigt, dass man mit den Mengen an Projekten, Boards und Confluence-Seiten kaum mehr den Überblick behalten kann. Dabei sind Verlinkungen – von Epics, Features, Objectives, User Stories, etc. – häufig nur unübersichtlich dargestellt und mangelhaft gepflegt werden.
Von Top-down und Bottom-up
Laozi sagt:
„Nur wer sein Ziel kennt, findet den Weg.“
Watts Humphrey erwidert darauf:
„If you don’t know where you are, a map won’t help.“
Laozi‘s Zitat besagt, dass man ohne (zumindest grobe) Zielvorgabe kaum die Richtung finden kann, in die man entwickeln muss. Mr. Humphrey meint dagegen, dass eine Karte kaum hilft, wenn man gar nicht weiß wo man sich gerade befindet. Beide Zitate können ohne Einschränkungen auf Projekte angewandt werden.
Das Epic beschreibt das große, strategische Ziel, Objectives stellen Zwischenziel – sogenannte Milestones – dar, Dagegen beschreiben Features einen Service und User Stories stellen die (weitgehend) konkrete Beschreibung dessen dar, was die Development Teams / der Developer am Ende umzusetzen hat.
Top-down vom Epic zum Objective zur User Story und dann …. äh ja, wo gehören denn jetzt die Features hin? Auf ein eigenes Board? Und wo werden die Objectives administriert?
Eines steht fest: Werden User Stories auf der Teamebene nicht adäquat umgesetzt, werden Zwischenziele – Objectives – nicht erreicht und wenn die nicht erreicht werden, gibt es auch auf der Epic-Ebene kein Goal Achievement. Bottom-up.
Empfehlung
Der Tool Setup – Jira und Confluence – sollte einen Bottom-up-Ansatz folgen, …
… denn der Erfolg eines jeden agilen Projekts hängt im Wesentlichen von der Erreichung der Sprint-Ziele der Scrum Teams der Agile Release Trains (ARTs) ab.
Insofern bedarf es eines Höchstmaßes an Transparenz und Objektivität bei den Artefakten Objective u. User Story (und auch Task).
Konkret: Objectives, User Stories, Tasks und Bugs sollten auf den Team Boards der jeweiligen Scrum Teams administriert werden. Auf einem Board lassen sich entsprechende Verlinkungen transparent darstellen, ohne das man dazu erst das entsprechende Issue (Ticket) öffnen muss. Mit einer „eleganten“ und gekonnten Konfiguration des Systems – Jira und Confluence – erhält man ein sehr hohes und wenig fehleranfälliges Maß an Transparenz über das Projektgeschehen.
Und wo passt da Confluence ins Bild?
Confluence führt in vielen Organisationen ein darbes Leben. Nicht selten sind darin viele Informationen in einer schier endlosen Unordnung optisch erschreckend hässlich niedergelegt.
Ohne Konzept und zumeist ohne klare Ownership sind Informationen auf Seiten geschrieben worden, nach denen man häufig mühselig suchen muss, wenn man sie denn braucht.
Produktdokumentation – also die Dokumentation der Solution, wie das Produkt des Projekts in SAFe genannt wird – wird häufig in Jira abgelegt und da gehört die nun wahrlich nicht hin. Kaum jemand weiß von der Mächtigkeit und Einfachheit des Werkzeugs Confluence und so wird der Nutzen dieses Tools oftmals nicht erkannt.
Konkret: Die gesamte Dokumentation der Solution – des / der Produkte – sollte in Confluence erfolgen. Angefangen von der Solution über die Features bis hinunter zu den einzelnen Funktionen der Solution / Anwendung selbst.
Conclusio
Mit einem Tool-Setup, der die Methode in optimaler Art und Weise unterstützt, lassen sich Transparenz ins Projektgeschehen bringen und Optimierungspotenziale ausschöpfen.
Wenn Sie wissen wollen, warum man Epics besser in Confluence verwaltet und nicht in Jira und wie man zudem aus Confluence heraus das über Jira administrierte Geschehen transparent beobachten kann,
Wenn Sie Ihre Werkzeuge Jira und Confluence für eine optimale Tool-Unterstützung einrichten wollen,
