Wie der Workflow unkompliziert und mit nur wenigen Anpassungen mit Hilfe einer elektronischen Umgebung umgesetzt wird, zeigen wir anhand eines Beispielprojekts in Azure DevOps. Die Konzepte, die wir vorstellen, lassen sich aber ebenso in anderen Tools nutzen.

Nachdem wir uns in dieser Artikelserie bisher angeschaut haben, was es mit Kanban und den Flow-Prinzipien auf sich hat, warum diese wichtig sind und wie wir Metriken nutzen können, um den Flow zu verbessern, wollen wir uns im letzten Teil die konkrete Umsetzung am Beispiel von Azure DevOps vornehmen. Die beschriebenen Konzepte lassen sich im Wesentlichen auch auf andere Tools übertragen. Dabei betrachten wir sowohl die elektronische Abbildung des Workflows als auch die Erhebung und Visualisierung von Metriken.

Aufbau eines Workflows

Das Herzstück hinter Kanban und Flow ist der Workflow, der die verschiedenen Stationen abbildet, die eine Veränderung der Software durchläuft. Zuerst muss hier der Start- und Endpunkt des Workflows definiert werden. Wir starten in unserem Beispiel an der Station, an der die beabsichtigten Veränderungen gesammelt werden, also mit dem Product Backlog. Enden soll der Workflow mit der Auslieferung in die Produktivumgebung.

Das von uns erwünschte Ergebnis zeigt Abbildung 1. Die Konfiguration dieses Workflows gehen wir nun Schritt für Schritt durch.

Abbildung 1 - Der fertige Workflow

In Azure DevOps nutzen wir dafür den Bereich Azure Boards, mit dem das Product Backlog sowohl in Listenform als auch in einer Board-Ansicht dargestellt werden kann. Starten wir ein neues Projekt, ist hier bereits eine simple Board-Ansicht zu sehen (Abbilung 2). Für die Konfiguration wird über das Zahnradsymbol der Einstellungsdialog geöffnet.

Abbildung 2 - Initiale Ansicht des Boards mit Azure Boards

Hier werden im Bereich „Columns“ die einzelnen Spalten für den Workflow definiert. Für jede Spalte kann ein Name und das Work in Progress (WIP) Limit festgelegt werden. Übersteigt die Anzahl der Elemente in einer Spalte dieses Limit, wird das durch eine farbliche Hervorhebung angezeigt (Abbildung 3).

Abbildung 3 - Einstellungen für das Kanban Board

Hier werden auch weitere wichtige Einstellungen vorgenommen.

• Split Column into doing and done:

  Eines der wesentlichen Prinzipien für Flow ist das Pull-Prinzip. Es besagt, dass Elemente nicht einfach zur nächsten Station weitergeschoben werden, sobald ein Teilschritt abgeschlossen ist. Stattdessen „pullt“ die folgende Station die Elemente - holt sie sich also aktiv -, wenn dort Kapazität dafür vorhanden ist. Das erreicht man, indem einzelne Spalten, für die das Pull-Prinzip genutzt werden soll in einen Doing“ und in einen „Done“ Bereich unterteilt werden. Elemente, die in einem Schritt abgeschlossen sind, werden im „Done“ Bereich für das Pulling bereitgestellt. Die Unterteilung ist vor allem für Spalten sinnvoll, bei denen die Bearbeitung einen gewissen zeitlichen Umfang aufweist. Bei automatisierten Aktivitäten dagegen, die nur angetriggert werden müssen, kann man auf die Unterteilung auch verzichten. In unserem Beispiel trifft das etwa auf die Spalte „Deployment“ zu.

• State Mapping:

  Hierbei handelt es sich eher um einen technischen Aspekt von Azure DevOps, der erst später bei der Ermittlung von Metriken für das Thema Kanban relevant wird. Vereinfacht gesagt, hat jeder Work- Item -Typ in unserem Projekt ein definiertes Statusmodell. Dieses wird üblicherweise eher stabil gehalten, da Änderungen daran alle Teams in unserem Projekt, Auswertungen und andere Bereiche betreffen würden. Um den Boards der einzelnen Teams dennoch eine hohe Flexibilität zu ermöglichen, wird hier ein Metastatusmodell hinzugefügt. Jede Spalte in dem Board repräsentiert einen Metastatus, der für dieses eine Board konfiguriert und verändert werden kann. Die Metastatus werden nun auf das Statusmodell der Work - Item -Typen gemappt. Dadurch wird definiert, welchen Status ein Work Item einnehmen soll, wenn es in eine bestimmte Spalte verschoben wird. Dabei können mehrere Spalten auf denselben Status mappen. Somit haben wir ein relativ einfaches Statusmodell, das über die Metastatus feiner aufgeteilt werden kann.

Damit wurde bereits die grundlegende Struktur des Workflows angelegt (Abbildung 4). Bevor es nun um weitere Einstellungen geht, soll das Board mit Inhalten gefüllt werden. Je nachdem, welcher Prozess beim Anlegen des Projektes ausgewählt wurde, stehen hier verschiedene Work - Item - Typen zur Verfügung. Sie können auch noch ergänzt und angepasst werden. Das Vorgehen zum Anpassen des Prozesses unterscheidet sich je nach der eingesetzten Version von Azure DevOps. Für Azure DevOps Services und Azure DevOps Server 2022 finden sich Beschreibungen in der entsprechenden Microsoft Dokumentation. Diese Definition der verschiedenen Work - Item - Typen ist Teil der Definition des Kanban Workflows, da damit explizite Regeln für die Organisation der Arbeit festgelegt werden.

Abbildung 4 - Die grundlegende Struktur des Workflows mit ersten Inhalten

Für das Beispiel wurde der Scrum Prozess genutzt, weshalb im Product Backlog sogenannte Product Backlog Items und Bugs angelegt werden können. Nutzt man einen anderen Prozess, haben diese Items andere Bezeichnungen. Die unterschiedlichen Work - Item - Typen werden durch entsprechende Icons und Farbcodes dargestellt.

Nun wollen wir weitere Kanban - spezifische Einstellungen am Board vornehmen.

Blocker markieren

Aus einer Flow-Perspektive muss ein besonderes Augenmerk auf geblockte Elemente gelegt werden. Schließlich ist jeder Blocker eine Störung des Flows. Blocker entstehen etwa durch Abhängigkeiten, bzw., wenn auf andere gewartet werden muss oder wenn unvorhergesehene Probleme entstehen. Diese Elemente wollen wir in besonderer Weise markieren.

Ein möglicher Ansatz hierbei ist die Nutzung Tags. Damit werden zunächst die entsprechenden Work Items markiert.

Abbildung 5 - Taggen eines Work Items

Tags können frei definiert werden, indem ein beliebiger Text eingegeben wird. Ab diesem Zeitpunkt steht der Tag als Auswahl zur Verfügung. Einem Work Item können auch mehrere Tags zugeordnet werden. Die so getaggten Elemente sollen nun im Board hervorgehoben werden. Dafür können entsprechende Styles definiert werden.

Abbildung 6 - Definieren von Styles

Im Board werden die Elemente mit dem Tag „Blocked“ nun mit der definierten roten Hintergrundfarbe angezeigt. Es ist auch möglich, lediglich das Label für den Tag auf der Karte einzufärben. Dies kann über die Einstellung „Tag-Colors“ im Konfigurationsdialog erreicht werden. Da hier die Hintergrundfarbe genutzt wird, benötigen wir das Tag für diesen Zweck nicht mehr. Andere hilfreiche Informationen werden uns bislang noch nicht angezeigt. Deshalb konfigurieren wir nun die Informationen auf den Karten.

Felder auf den Karten konfigurieren

Für die Karten auf dem Board können wir festlegen, welche Felder dort angezeigt werden sollen. Diese Konfiguration kann pro Work -Item -Typ unterschiedlich festgelegt werden, da verschiedene Typen auch verschiedene Felder haben können. Deshalb muss im vorliegenden Beispiel die Einstellung sowohl für Product Backlog Items als auch für Bugs vorgenommen werden. In Abbildung 7 ist zu sehen, dass dort die Anzeige von „Effort“ und den Tags deaktiviert wurde. Diese Felder wurden zuvor immer dann angezeigt, wenn sie nicht leer waren. Zusätzlich werden nun auch die Felder „Activated Date“ und „Closed Date“ angezeigt. Dies ist nützlich, um das Work Item Age und die Cycle Time zu bestimmen. Dabei wird das „Activated Date“ automatisch auf den Zeitpunkt gesetzt, zu dem ein Element in den Status „Commited“ wechselt. Für welche Spalten das der Fall ist, kann über das State Mapping konfiguriert werden.

Abbildung 7 - Konfiguration der Felder

Work Item Age visualisieren

Das Work Item Age der Elemente kann nun aus den angezeigten Feldern ermittelt werden. Das ist allerdings recht mühsam und auch nicht besonders visuell. Doch dafür können weitere Styles definiert werden. Das Work Item Age kann man herausfinden, indem man schaut, wie weit das „Activated Date“ in der Vergangenheit liegt. Dafür können verschiedene Zeitabschnitte definiert werden. Jeder Zeitabschnitt legt dabei eine Farbe für die Karte fest, so dass die Farbe umso kräftiger wird, je älter das Element ist (Abbildung 8). Für die Styleregel kann das aktuelle Datum mit dem Makro „@Today“ genutzt werden und von diesem ein Zeitraum in Tagen abgezogen werden (z.B. @Today – 7). Über einen zweiten Eintrag wird festgelegt, dass diese Regel nicht für Elemente im Status „Done“ gelten soll.

Abbildung 8 - Visualisierung des Work Item Age

Des Weiteren ist zu beachten, dass, wenn mehrere Styles vorhanden sind, diese in einer festgelegten Reihenfolge ausgewertet werden, sobald sie definiert sind. In diesem Beispiel könnte ein Element geblockt sein und bereits ein Alter haben, das über die entsprechende Hintergrundfarbe angezeigt wird. Hier muss festgelegt werden, welcher Style Priorität haben soll. Dazu wird einfach in der Style Übersicht die Reihenfolge per Drag & Drop angepasst. Das Element, das zuoberst in dieser Liste steht, hat die höchste Priorität (Abbildung 9). In dem gezeigten Beispiel wird also zuerst geprüft, ob das Element geblockt ist. Wenn ja, erhält die Karte einen roten Hintergrund, andernfalls wird geprüft, ob es älter als sieben Tage ist. Und nur, wenn das auch nicht der Fall ist, erfolgt die Prüfung auf ein höheres Alter als drei Tage.

Abbildung 9 - Prioritäten der Styles

Exit Criteria / Definition of Done festlegen

Als letzten Punkt sehen wir uns an, wie für die einzelnen Spalten eine Definition of Done festgelegt werden kann. Die Definition of Done legt fest, welche Kriterien erfüllt sein müssen, bevor ein Element in die nächste Spalte bzw. in die Done-Subspalte weitergeschoben werden kann. Da der Begriff „Definition of Done“ im Scrum-Kontext eine stehende Wendung ist und dort eine andere Bedeutung hat, wird im Kontext von Kanban oft auch der Begriff „Exit Criteria“ genutzt. (Abb.10)

Für jede Spalte kann eine entsprechende Definition angegeben werden. Dabei kann sowohl reiner Text als auch das Markdown-Format genutzt werden. Spalten, für die eine entsprechende Definition vorgenommen wurde, erhalten in der Board-Ansicht ein kleines i-Symbol. Wird dieses angeklickt, werden die hinterlegten Exit Criteria angezeigt.

Abbildung 10 - Exit Criteria festlegen

Metriken und Diagramme

Azure DevOps unterstützt von Haus aus verschiedene Diagramme zur Visualisierung. Zum Glück sind einige dabei, die im Kontext von Kanban sinnvoll sind, auch wenn ihre Funktionalitäten und Möglichkeiten begrenzt sind. Für eine verbesserte Visualisierung stehen im Marketplace aber auch Erweiterungen zur Verfügung. Sehen wir uns zuerst an, was bereits mit Bordmitteln möglich ist.

Cumulative Flow Diagram

Das Cumulative Flow Diagramm (CFD) (Abb.11) wurde, wie die anderen hier vorgestellten Diagramme, im zweiten Teil der Artikelserie besprochen. Dort wurde auch erläutert, wie die jeweiligen Diagramme interpretiert werden können.

Das CFD kann direkt über den Analytics-Tab aus der Board-Ansicht heraus geöffnet werden. Hier kann neben dem Zeitraum, den das Diagramm umfassen soll, auch festgelegt werden, welche Spalten aus dem Board angezeigt werden sollen.

Abbildung 11 - Cumulative Flow Diagramm

Cycle Time Scatter Plot

Am Beispiel des Cycle- Time-Scatter- Plot- Diagramms möchte ich zeigen, wie mit Hilfe von Diagramm-Widgets ein Dashboard aufgebaut werden kann. Im Bereich „Overview“ gibt es einen Unterbereich „Dashboards“. Hier können beliebig viele Dashboards pro Team angelegt werden. Im Bearbeitungsmodus können dann verschiedene sogenannte Widgets auf dem Dashboard platziert werden. Es steht eine Auswahl an Widgets zur Verfügung, weitere können über eine Extension Gallery installiert werden (Abb.12). Über das Zahnradsymbol können Einstellungen am jeweiligen Widget vorgenommen werden.

Abbildung 12 - Platzierung des Cycle Time Diagramm Widgets

Die im Widget dargestellte Cycle Time wird aus der Differenz zwischen den Feldern „Closed Date“ und „Activated Date“ ermittelt. Activated Date wird von Azure DevOps automatisch auf die aktuelle Uhrzeit gesetzt, wenn ein Work Item in den Status „Commited“ übergeht (siehe Beschreibung des State Mappings im Abschnitt „Aufbau eines Workflows“). Dasselbe gilt für das Closed Date. Hier wird der Zeitpunkt der Statusänderung in „Done“ herangezogen.

Work in Process

Eine weitere wichtige Metrik für Flow ist Work in Process. Anhand dieses Beispiels soll eine weitere Möglichkeit zur Visualisierung in Azure DevOps gezeigt werden. Im Boards-Bereich können Queries erstellt werden, deren Ergebnisse auch als Diagramm visualisiert werden. (Abb.13) Eine entsprechende Abfrage für Work in Process ist schnell erstellt. Dazu filtern wir einfach auf den Status „Committed“. Über den Button „Column options“ kann das Feld „Board Column“ hinzugefügt werden, das wir in unserer Visualisierung nutzen wollen. Mit „Run Query“ kann das Ergebnis bereits als Liste angezeigt werden.

Abbildung 13 - Erstellung einer Query

Um das Ergebnis der Abfrage als Diagramm zu zeigen, muss die Query zunächst gespeichert werden. Wenn das Diagramm später auch noch auf dem Dashboard angezeigt werden soll, ist es wichtig, die Abfrage im Bereich „Shared Queries“ zu speichern. Im Gegensatz zu „My Queries“ haben dann alle Teammitglieder Zugriff auf diese Abfrage. Nun kann in den Charts-Tab gewechselt werden. Die Einstellungen hier sollten weitgehend selbsterklärend sein. Beim Diagrammtyp „Stacked area“ wird automatisch die Darstellung eines Werteverlaufs über die Zeit ermöglicht (Abb.14). Der zu betrachtende Zeitraum kann konfiguriert werden. Bei anderen Diagrammtypen wird dagegen lediglich der aktuelle Zustand betrachtet.

Abbildung 14 - Visualisierung der Query als Diagramm

Über die drei Punkte kann das Diagramm dem Dashboard hinzugefügt werden. Wie bereits erwähnt, ist diese Option nur dann verfügbar, wenn die Query unter „Shared Queries“ gespeichert wurde.

Mehr Visualisierungsoptionen

Um mehr Konfigurationsmöglichkeiten zu erhalten, stellt Azure DevOps noch leistungsfähigere Auswertungsmöglichkeiten zur Verfügung.

Excel Integration:

Über ein entsprechendes Office-Plugin können die Ergebnisse von Queries auch direkt in Microsoft Excel geöffnet, aktualisiert und ausgewertet werden. Hier können beispielsweise Auswertungen mit Hilfe von Pivot-Tabellen und -Diagrammen erstellt werden.

Analytics View:

Eine recht neue Möglichkeit stellt die Schnittstelle zu Power BI über die sog. Analytics Views dar. Zum Zeitpunkt der Erstellung dieses Artikels ist dieses Feature noch in Preview. Dabei können in Azure DevOps verschiedene Views als Quelle für Power BI definiert werden. Mit dieser Möglichkeit lässt sich nicht nur der aktuelle Stand der Work Items auswerten, sondern es können auch historische Daten herangezogen und so zeitliche Verläufe visualisiert werden. Die erstellten Reports lassen sich dann beispielsweise in einem Azure- DevOps- Dashboard über das Widget „Embedded Webpage“ integrieren (Abb.15).

Abbildung 15 - Ein Dashboard mit verschiedenen Flow-Metriken

Extensions

Es gibt verschiedene, teils auch kostenpflichtige Extensions für Azure DevOps, die speziell für Kanban und Flow-Metriken interessante Funktionen bereitstellen. Hier ist insbesondere „ActionableAgile Analytics for Azure DevOps“ hervorzuheben, das nicht nur entsprechende Diagramme und Visualisierungen anbietet, sondern auch Simulationen, die auf der Monte- Carlo- Simulation basieren.

Fazit

In den ersten beiden Teilen dieser Serie wurden die Prinzipien hinter Flow sowie die Nutzung verschiedener Flow-Metriken beleuchtet. Hier wurde auch dargelegt, wie diese Prinzipien und Metriken in der Softwareentwicklung nutzbringend eingesetzt werden können. Während die Abbildung des Workflows in Papierform in bestimmten Situationen durchaus praktikabel und empfehlenswert ist, so ist doch in Zeiten von Remotearbeit für viele die Nutzung eines elektronischen Tools die bessere Alternative. Spätestens bei den Metriken wird es sehr mühsam, möchte man sie händisch ermitteln.

In diesem Artikel haben wir gesehen, dass mit einem Tool wie Azure DevOps, eine Umsetzung mit wenigen Handgriffen und Anpassungen möglich ist. Natürlich muss man hier den einen oder anderen Kompromiss eingehen. Azure DevOps ist als Plattform konzipiert, die ein breites Anwendungsfeld abdeckt. Deshalb lassen sich einige Details nur mit sehr hohem Aufwand oder gar nicht umsetzen. Es gibt durchaus auch Tools, die eine stärkere Fokussierung auf das Thema Kanban und damit auch einen reicheren Funktionsumfang in diesem Bereich haben. Allerdings bieten diese keine Unterstützung über die Planungstools hinaus. Gerade hier liegt die Stärke von Azure DevOps. Als integrierte Plattform können hier nicht nur in einem Tool die wesentlichen Funktionen wie Versionsverwaltung, Build und Release Pipelines sowie Test- und Artifact- Management mit der Aufgabenverwaltung abgebildet, sondern auch Informationen aus diesen Bereichen miteinander verknüpft werden. Der Anwender muss hier entscheiden, welche Vorteile für ihn stärker wiegen.

Weiterführende Folgen zur Artikelserie zu Kanban:
Teil 1 - Let there be flow – Die Magie hinter Kanban und Flow -> Hier weiterlesen
Teil 2 - Flow mit Metriken beherrschen -> Hier weiterlesen
Teil 3 - Flow mit Azure DevOps (dieser Artikel)