Agile Hive – Redesign und Marketplace Release

Die agile Softwareentwicklung stellt so manches Unternehmen vor große Herausforderungen: Teams arbeiten agil, das Management hingegen oft noch klassisch. Wie gelingt also der einheitliche Wechsel zur agilen Arbeitsweise?

Beispielsweise mit dem marktführenden Rahmenwerk "Scaled Agile Framework for Lean Enterprises" (SAFe®), welches eine Hilfe zur Steuerung aller Ebenen bietet, die im Zusammenhang mit der Softwareentwicklung stehen: Portfolio. Solution, Program und Team.

Die Methode schafft darüber hinaus mehr Transparenz und den Spagat zwischen Geschäftsstrategie und Ausführung. Außerdem hilft SAFe®, qualitativ bessere Ergebnisse und einen höheren Grad der Vorhersehbarkeit zu erzielen.

Agile Hive ist eine etablierte SAFe®-Lösung, die auf den bekannten Atlassian-Tools "Confluence" und "Jira" basiert. 

In den letzten Wochen hat sich einiges getan. Im November wird Agile Hive erstmalig als Gesamtlösung im Atlassian Marketplace veröffentlicht. Die zahlreichen Weiterentwicklungen möchten wir in diesem Blogpost anteasern.


Das Redesign

Wir unterziehen Agile Hive einem ganzheitlichen Redesign, um die Einführung, Benutzung und Wartung wesentlich kundenfreundlicher zu gestalten.

Anders als bisher, wird Agile Hive nicht mehr aus 13 verschiedenen Erweiterungen bestehen, sondern fortan als eine App im Atlassian Marketplace erhältlich sein. Der erste Release ist weniger als einen Monat entfernt und umfasst folgende Highlights:

      • Project Hierarchies - Visueller Editor für die Erstellung von hierarchisch organisierten Projektstrukturen in Jira
      • Context - Automatische Hierarchie-Darstellung der Parent-Child-Beziehungen innerhalb von Vorgängen
      • Team / Program Reports - Automatische Reports für Projekte auf den SAFe®-Ebenen Team und Program

Auf diese drei Highlights gehen wir in diesem Artikel näher ein. Selbstverständlich können weiterhin die bisher eingesetzten Erweiterungen, wie beispielsweise Structure oder AutoPage, verwendet werden. Diese Erweiterungen sind weiterhin voll kompatibel und werden es bleiben.

Die kommenden Releases der Agile Hive-App konzentrieren sich allesamt auf die Entwicklung neuer Features, um die bisherigen Features aus den zahlreich eingesetzten Erweiterungen abzubilden und direkt zu integrieren.


Project Hierarchies

Was sind Project Hierarchies?

Das neue Fundament von Agile Hive basiert auf den "Project Hierarchies". Mit Project Hierarchies können Jira-Projekte (dargestellt als farbige Nodes) in hierarchische Beziehungen (dargestellt als graue Verbindungslinien) gesetzt werden. Diese Beziehungen stellen sicher, dass ausschließlich Vorgänge innerhalb dieser Projekte hierarchisch miteinander verlinkbar sind, und auch nur, wie es die jeweiligen Beziehungen zwischen den Projekten erlauben.

Agile Hive - Project Hierarchies

Project Hierarchies stellt korrekte hierarchische Beziehungen zwischen Vorgängen sicher.

Beispiele:

      • Ein Vorgang im Projekt "DC" kann hierarchisch ausschließlich mit einem Vorgang aus dem Projekt "ART2" verlinkt werden.
      • Ein Vorgang im Projekt "ART2" kann hierarchisch wiederum mit einem Vorgang aus dem Projekt "DC", aber auch mit einem Vorgang aus dem Projekt "SOLUTION1" verlinkt werden.

Grundsätzlich kann jeder Vorgang immer nur mit einem "Vater-Vorgang" hierarchisch verlinkt werden. Hingehen kann ein "Vater-Vorgang" mit beliebig vielen "Kind-Vorgängen" hierarchisch verlinkt werden.

Was bedeutet "hierarchisch verlinkt"?

Jira-Vorgänge können grundsätzlich mit allen vorhandenen "allgemeinen" Verlinkungstypen, wie beispielsweise "relates to" oder "is blocked by", verlinkt werden. Mit Agile Hive führen wir einen neuen Verlinkungstyp ein. Die Optionen dieses Verlinkungstyps sind "parent of" und "child of". Diese beiden Optionen werden für die "hierarchische Verlinkung" genutzt und können, wie oben beschrieben, nur im validen Fall gesetzt werden. Alle anderen "allgemeinen" Verlinkungstypen können weiterhin unabhängig von der Hierarchie gesetzt werden.

Agile Hive - hierarchisierte Vorgänge

Project Hierarchies - eine neue Projektstruktur, welche die Verlinkungstypen "parent of" und "child of" einführt.

Wie erstelle ich Project Hierarchies?

In drei einfachen Schritten:

      1. Der visuelle Editor erlaubt dem Jira-Admin, beliebig viele Ebenen (Layers) zu erstellen, zu betiteln und mit Farben zu versehen.
      2. Diesen Ebenen können anschließend den gewünschten Jira-Projekten zugeordnet werden.
      3. Letztlich können die Beziehungen der Projekte zueinander hinterlegt werden.
Wie man Project Hierarchies erstellen kann

Die Konfiguration der Ebenen, die eine Projekthierarchie bilden.


Context (visuelle Parent-Child-Beziehungen)

Was stellt die Context-Ansicht dar?

Die "Context-Ansicht" stellt alle Vater-Vorgänge des geöffneten Vorgangs hierarchisch dar. Darüber hinaus wird auch der Ebenen-Name, samt seiner Farbe, dargestellt. Somit ist der Kontext, bzw. die Zugehörigkeit, des jeweiligen Vorgangs klar ersichtlich. Die Navigation zu den Vater-Vorgängen wird hierdurch deutlich erleichtert.

Wann wird diese Ansicht dargestellt?

Vorgänge aus Projekten, die in den "Project Hierarchies" hinterlegt sind, stellen automatisch die Beziehungen zu den Vater-Vorgängen in dem Reiter "Context" dar. Hierfür ist keine weitere Konfiguration notwendig.

Agile Hive - Context

Die "Context-Ansicht" stellt den Usern auf den ersten Blick die "Vater-Vorgänge" des geöffneten Vorgangs hierarchisch dar.


Team Reports

Was stellen die Team Reports dar?

Die Team Reports stellen relevante Team-Metriken dar. Dies geschieht, nach der Vorgabe von SAFe®, in Form von Kacheln in einer einzigen Übersicht . Diese Ansicht wird für jedes Team automatisch im jeweiligen Team-Projekt erzeugt und mit Echtzeit-Daten gepflegt.

User können das zu betrachtende Program Increment (PI) über ein Dropdown-Menü auswählen. Hierdurch können User beispielsweise historische Daten aus vergangenen PIs betrachten. Es ist keinerlei Konfiguration für diese Ansichten erforderlich.

Im Folgenden werden die verschiedenen Metriken, die in den kommenden Monaten Stück für Stück released werden, erläutert.

Ansicht der Team Reports

Die volle Ausbaustufe der Team Reports, die wir mit den kommenden Releases erreichen werden.

Team Member

Darstellung aller Team-Mitglieder. Die Team-Mitglieder werden samt Avatar, Vorname und Rolle dargestellt, damit man Ansprechpartner schneller identifizieren kann.

Overall Team PI Progress

Fünf wichtige (teils aggregierte) Kennzahlen, um Fortschritt, Performance und Planung auf einen Blick einzusehen:

      1. Velocity - Vergleich der derzeitigen Velocity (im Kreisinneren) mit der Velocity der letzten 5 Sprints.
      2. SP Burned - Gesamtfortschritt über alle abgeschlossen (burned) Story Points (SP) des Teams innerhalb eines PIs.
      3. Days Passed - Gegenüberstellung der Gesamt-Tage mit den noch verfügbaren Tagen.
      4. Business Value - Werterreichung auf Basis des Business Values aus den Team PI Objectives.
      5. Load vs. Cap - Vergleich der geplanten Story Points mit der verfügbaren Kapazität.
Sprints (im ersten Release enthalten)

Darstellung aller geplanten (grau), aktiven (blau) oder abgeschlossenen (grün) Sprints des Teams. Die Programm-Ebene zeigt die Inhalte der Sprints (inkl. der "Vater-Vorgänge") an.

Ein Fortschrittsbalken, die Kennzahlen-Kapazität (Capacity), geplante Story Points (Planned) und abgeschlossene Story Points (Done) runden die Übersicht ab.

Team PI Objectives

Die definierten "Team PI Objectives" werden streng nach SAFe®-Vorgabe dargestellt. Zusätzlich zeigt dieser Reiter die Story Points der Vorgänge, die auf die jeweiligen "Team PI Objectives" einzahlen.

Team PI Objectives

Team PI Objectives nach SAFe®-Vorgaben

Teams Risks

Risiko-Management nach ROAM (Resolved, Owned, Accepted, Mitigated) mit Auflistung aller Team-Risiken. Die Klassifizierung wird anhand der Eintrittswahrscheinlichkeit (Probability) und der Auswirkung (Impact) vorgenommen. "Treatments" sind Vorgänge zur Behandlung der jeweiligen Risiken. Diese werden, samt Status, hinter jedem Risiko dargestellt. Zudem haben Treatments direkte Auswirkung auf die dann noch übrigen Eintrittswahrscheinlichkeit (Residual Probability) und  Auswirkung (Residual Impact).


Program Reports

Program Reports - Darstellung aller Programm-Rollen

Die Programm-Rollen eines Agile Release Trains (ART) werden samt Avatar, Vorname und Rolle dargestellt.

 ART Roles

Darstellung aller Programm-Rollen eines "Agile Release Trains" (ART). Die Programm-Rollen werden samt Avatar, Vorname und Rolle dargestellt, um Ansprechpartner schneller identifizieren zu können.

ART PI Statistics

Fünf wichtige (teils aggregierte) Kennzahlen, um Fortschritt, Performance und Planung auf einen Blick einzusehen:

      1. Velocity - Vergleich der derzeitigen Velocity aller Teams (im Kreisinneren) mit der Velocity der letzten 5 Sprints.
      2. SP Burned - Gesamtfortschritt über alle abgeschlossen (burned) Story Points (SP) aller Teams innerhalb des PIs.
      3. Days Passed - Gegenüberstellung der Gesamt-Tage mit den noch verfügbaren Tagen.
      4. Predictability - Durchschnitt der Werterreichung aller Teams auf Basis des Business Values aus den Team PI Objectives.
      5. Load vs. Cap - Vergleich der geplanten Story Points aller Teams mit der verfügbaren Kapazität.
ART Progress (im ersten Release enthalten)

Darstellung aller geplanten Programm-Vorgänge (Program-Vorgänge Agile Hive) samt Vater-Vorgang (Vater-Vorgang Agile Hive) innerhalb eines PIs. Die Vorgänge werden samt detaillierter Fortschrittsanzeige, in Prozent und Story Points, dargestellt. Ein besonderes Highlight hierbei ist die Darstellung aller ART-zugehörigen Teams und deren Beteiligung an den jeweiligen Programm-Vorgängen.

ART PI Objectives

Die "ART PI Objectives "leiten sich aus den definierten "Team PI Objectives" ab. Diese werden im oberen Teil des Dashboards dargestellt. Darunter kann man alle "Team PI Objectives" der vorhandenen Teams in einer Reiter-Ansicht separat betrachten.

ART Risks

Risiko-Management nach ROAM (Resolved, Owned, Accepted, Mitigated), mit Auflistung aller ART-Risiken. Die Klassifizierung wird durch die Eintrittswahrscheinlichkeit (Probability) und die Auswirkung (Impact) vorgenommen. "Treatments", dagegen, sind Vorgänge zur Behandlung der jeweiligen Risiken. Sie werden (samt Status) hinter jedem Risiko dargestellt. Zudem haben Treatments direkte Auswirkung auf die dann noch übrigen Eintrittswahrscheinlichkeit (Residual Probability) und  Auswirkung (Residual Impact).