Agile Softwareentwicklung ist empirisch. Wenn möglich, werden Entscheidungen auf der Grundlage von Fakten getroffen.  Die benötigten Fakten werden an erster Stelle durch Verhaltens- und Ergebnisbeobachtungen erhoben. Aber was bedeutet Beobachtung im Kontext agiler Organisationen? Worauf sollten wir achten, damit Messungen nicht unseren Blick auf das Große und Ganze verschleiern, sondern zum Erfolg unserer Vorhaben beitragen?

Der empirische Charakter agiler Softwareentwicklung wird im Mantra “Inspect and Adapt” deutlich. Häufig wird das übersetzt als “Beobachtung und Anpassung” oder “Überprüfung und Anpassung”. Genau genommen sind Beobachtung und Überprüfung unterschiedliche Dinge und es ist hilfreich, das genauer zu verstehen.

Etwas zu beobachten bedeutet, im Zustand geduldiger Aufmerksamkeit eine Szene oder einen Sachverhalt zu verfolgen. Die Beobachtung bezieht harte Daten, vage Informationen und Emotionen mit ein. Beobachtung ist eher weit gefasst und kann mit abstrakten und verdichteten Sachverhalten ebenso zu tun haben wie mit sehr feinen Details. Zu interpretieren, Einsicht zu gewinnen, Verbindungen herzustellen, sind Merkmale der Beobachtung. Beobachtung fordert Offenheit für Neues und Wachheit oder Wachsamkeit, also die Bereitschaft zur Wahrnehmung. Man versucht,  mit allen Sinnen ein zweckdienliches Bild, ein Modell, erwachsen zu lassen, zu bestätigen oder zu falsifizieren. Beobachtung ist ein komplexer Vorgang. Was man beobachtet, ist gar nicht so einfach zu beschreiben, weil die Natur der Beobachtung qualitativ ist.

Die Messung steht im Dienst der Beobachtung. Parameter werden auf einer Skala, am besten einer metrischen Skala, gemessen. Im Unterschied zur Beobachung ist das Ergebnis einer Messung  einfach zu benennen, da sie quantitativ ist. Man erhält harte Daten und bei Zeitraumbetrachtungen die Entwicklungsrichtung der gemessenen Werte. Messungen sind Indikatoren, sie sollen uns beispielsweise Informationen über Qualität und Fortschritt geben. Wir versuchen auf der Grundlage von Messungen Vorhersagen abzuleiten und Entscheidungen zu treffen. Messungen machen Dinge sichtbar, die nicht-gemessen unsichtbar wären. Dadurch lenken sie unser Verhalten.

Messbarkeit führt zur Püfbarkeit. Wir stellen der gemessenen Größe eine Soll-Größe gegenüber und treffen eine Aussage, wie gut oder schlecht der Soll-Wert erreicht wird.

Die Änderung des eigenen Verhaltens durch individuelles und soziales Lernen, findet in Folge von Beobachtungen, Messungen und Prüfungen statt. Wenn sich hierdurch entweder ein Widerspruch zwischen dem eigenen Denkmodell und der Wirklichkeit abzeichnet, oder eine Bestätigung dieses Denkmodells möglich wird, sind wir bereit, uns an die Wirklichkeit anzupassen. Jede Metrik hat Einfluss auf das Verhalten der Menschen, die durch die Metrik berührt werden. Wenn zum Beispiel die Einhaltung eines geschätzten Aufwandes im Rahmen der Projektarbeit genau geprüft wird und einen hohen Stellenwert hat, werden die Projektmitarbeiter sich entsprechend verhalten – Vorhersagbarkeit ist dann wichtig und es wird möglicherweise hohe Aufwandsschätzungen geben, deren Einhaltung gut sichergestellt werden kann.

In einem agilen Umfeld wird unser Beobachten durch das Wertesystem des agilen Manifests geleitet. Diese Werte fordern uns auf, Menschen und ihren Interaktionen einen hohen Stellenwert zu geben, auf Veränderlichkeit zu reagieren, funktionierende und nutzenstiftende Software in den Mittelpunkt unseres Handelns zu stellen und Zusammenarbeit mit dem Kunden hoch zu schätzen.

Die Kunst besteht darin, mit Metriken zu arbeiten, die diese agilen Werte unterstützen, so dass die qualitativen Aussagen des agilen Manifests durch Messungen quantitativ unterstützt werden und sich die Prüfungen der gemessenen Werte normierend auf individuelles und soziales Handeln auswirken. Dahinter steht auch die Frage, wie in der Organisation Erfolg definiert ist und wie der Fortschritt auf dem Weg zum Erfolg sichtbar gemacht wird. Vielfach werden die gemessenen Sachverhalte auf die Arbeitsprozesse bezogen sein, da agile Arbeiter nach der schrittweisen Verbesserung ihres Arbeitsverhaltens streben.

Die OLUPCAT-Merkmale, durch die  Metriken in agilen Umfeldern gekennzeichnet sein sollten, geben eine Orientierung:

• On demand: Es wird erst gemessen, wenn der Bedarf für die Messung klar ist. Zum Beispiel wenn ein Problem erkannt ist und der Weg zur Besserung gemessen werden soll. Oder wenn man sich ein Ziel gesetzt hat und mit einer Metrik den Fortschritt oder Zielerreichungsgrad ermitteln will. Daten zu erheben, nur weil man es kann, bringt niemanden weiter.
• Lightweight: Agile Metriken haben einen kleinen Fußabdruck. Sie sind methodisch einfach zu ermitteln und ohne hohen Aufwand im Rahmen der Arbeitsprozesse zu erheben.
• Understandable: Jeder in der Organisation versteht die Metrik und weiß, warum sie angewendet wird, also welches Ziel durch die Metrik unterstützt wird.
• Measure short periods continuously: Um kurze Rückkopplungsschleifen zu haben, wird kontinuierlich in kurzen Zeiträume gemessen, wie zum Beispiel in Arbeitstagen oder Iterationen. Die Auswertung der Messung steht unmittelbar nach der Messung zur Verfügung.
• Foster collaboration: Agile Metriken unterstützen die Zusammenarbeit. Das bedeutet, es werden nicht Sachverhalte gemessen, die im direkten Einflussbereich einer Person oder eines Teams liegen, sondern Sachverhalte, die eine Ebene oberhalb des Einflussbereichs der Akteure liegen, so dass Verhaltensanpassungen auf dem Wege der  Zusammenarbeit stattfinden müssen. Dieses Vorgehen schützt  davor, dass Individuen und Teams sich lokal optimieren und dadurch möglicherweise einer globalen Optimierung entgegenwirken. [vgl. Poppendieck 2003]
• Accessible: Die Metrik wird nicht nur durch einen kleinen Kreis von Mitarbeitern ausgewertet, sondern alle betroffenen Mitarbeiter haben jederzeit Zugang zu den aktuellen Daten. Nur so kann sich die Lenkungsfunktion einer Metrik entfalten.
• Trend-oriented: Wenn Metriken unser Verhalten beeinflussen und ändern, werden sich in der Umkehr auch die gemessenen Werte ändern. Die Entwicklungsrichtung und Geschwindigkeit dieser Änderung sind wichtiger als absolute Zahlen.

Die Frage, was und wie gemessen wird ist, zentral für das Verhalten der Akteure in einer Organisation, wodurch sich die Frage erhebt, wo Metriken herkommen und wer über ihren Einsatz und den Umfang sowie die Form der Anwendung entscheidet. Einige Ansätze:

Produktmanager oder Product Owner: Ist eine Messung sinnvoll, von der die Kunden oder Nutzer nichts haben, oder die dem eigenen Wirtschaften nicht zuträglich ist? Wenn sich eine Metrik durch Geschäftsziele begründen lässt ist schon viel gewonnen. Umgekehrt muss man sich fragen, warum es eine Metrik gibt, wenn sich diese Verbindung nicht herstellen lässt. Aus diesem Grund sollten die angewandten Metriken mit dem Product Owner abgestimmt sein.

Team oder größere Organisation: Der Entscheidungsprozess für den Einsatz bestimmter Metriken orientiert sich an der Aufbau- und Ablauforganisation des Vorhabens und des Unternehmens. Solange es nur ein Umsetzungsteam gibt, ist die Entscheidung über den Einsatz von Metriken vergleichsweise einfach auf der Ebene des Teams zu organisieren. In der größeren Organisation, die aus mehreren Teams besteht, wird das natürlich schwieriger. Ein möglicher Ansatz lässt sich aus der von Henrik Kniberg skizzierten Entwicklungsorganisation ableiten, die sich bei Spotify etabliert hat [Kniberg und Ivarsson 2012].

Das hervorstechende Merkmal dieser Organisation ist ihre Team-Orientierung und ein Matrix-Aufbau mit den beiden Schwerpunkten Produkt und Profession.

Ein Team heißt Squad und ist vergleichbar mit einem Scrum-Team. Jedes Team hat einen Product Owner, ist interdisziplinär besetzt und verfügt über eine langfristige Mission für einen bestimmten Produktbaustein, der durch das Team selbständig entwickelt wird.

Mehrere Teams sind in einer Sippe (Tribe) zusammengeführt. Die Teams innerhalb jeder Sippe arbeiten an Themen, die in enger Beziehung zueinander stehen. Bei Spotify gibt es zum Beispiel eine Sippe für den Music Player und eine andere Sippe für die Backend-Infrastruktur. Eine Sippe besteht aus maximal 100 Menschen.  Das wesentliche Organisationmerkmal für Teams und Sippen ist ihre Produktorientierung.

Zusätzlich zur Produktorientierung gibt es eine Organisationssicht, die sich an den Professionen der Mitarbeiter ausrichtet. Das sind die Verbände (Chapter) und Zünfte (Guilds). Verbände überschreiten die Grenzen ihrer Sippe nicht. In den Verbänden sind Mitarbeiter mit einem ähnlichen professionellen Hintergrund organisiert. Zum Beispiel alle Designer oder die Programmierer einer Sippe. Der Verband hat eine Führungskraft mit Gehalts- und Personalverantwortung. Bei Spotify ist diese Führungskraft auch Mitglied eines Teams, trägt also zur Auslieferung von Produktfunktionen mit bei.

Die Zunft ist eine sippenübergreifende Interessengemeinschaft von Menschen, die ihre Profession weiterentwickeln. Zum Beispiel die Zunft der agilen Coaches. Jede Zunft verfügt über einen Koordinator, den die Zunft selbst bestimmt.

In den Grafiken steht die vertikale Organisation der Teams und Sippen für die Produktentwicklung und die horizontale Organisation der Verbände und Zünfte für die Entwicklung der Profession.

Der Umgang mit Metriken kann sich an vergleichbaren produkt- und professionsbezogenen Strukturen orientieren. Metriken, die aus den Professionen erwachsen und die vielleicht nur  mittelbar mit dem Produkt in Zusammenhang zu bringen sind, können über Verbände und Zünfte für die gesamte Organisation balanciert werden. Gleiches gilt für den Einsatz von klar produktbezogenen Metriken, die über die Teams und Sippen balanciert werden. Dem Führungspersonal (Product Owner, Führungskräfte der Verbände) kommt die Aufgabe zu, das letzte Wort über den Einsatz solcher Metriken zu sprechen und den Ausgleich zwischen produkt- und professionsbezogenen Metriken zu finden. Das wiederum im Rahmen von Beobachtungen und Anpassungen.

Wird eine neue Metrik eingeführt, kann man den Hintergrund und die wesentlichen Fakten dieser Metrik notieren und so ablegen, dass diese Notizen für alle, die es betrifft,  jederzeit zugänglich sind. Zum Beispiel:

Einige Metriken, die nicht per se gut oder schlecht sind und die auch nur einen kleinen Ausschnitt möglicher Metriken darstellen, möchte ich hier noch nennen. Vielfach ermöglicht der Einsatz einer Verwaltungssoftware, wie zum Beispiel memYAK, mit der die Pflege des Product Backlog und die Fortschreibung des Arbeitsstatus durchgeführt wird, die rasche Analyse und Darstellung der benötigten Daten.

Velocity: Die Velocity ist eine weit verbreitete Maßeinheit für die Lieferkapazität eines Teams. Sie zeigt, wie gut ein Team in der Lage ist, Arbeit innerhalb einer Iteration vollständig fertigzustellen und zu integrieren. Lerneffekte des Teams werden in der Zeitraumbetrachtung durch eine erhöhte Velocity sichtbar und die Releaseplanung kann aufgrund empirischer Werte durchgeführt werden. Die Velocity ist vermutlich die bekannteste Metrik in agilen Umfeldern.

Anzahl der Integrationen in jeder Iteration (erfolgreich, insgesamt): diese Metrik erfüllt viele Ziele. Sie kann selbst in großen Organisationen leicht erhoben werden und ist gerade dort auch besonders nützlich. Wir erhalten eine Kennzahl über die Güte des des Zusammenspiels aus technischer Infrastruktur und den Arbeitsprozessen aller beteiligten Akteure. Ausserdem wir durch diese Kennzahl die Zusammenarbeit gefördert, weil sie übergreifend  funktioniert und nicht nur durch lokale Optimierung einzelner Akteure oder Teams zu beeinflussen ist. Gute agile Organisationen integrieren häufig (z.B. halbtäglich oder täglich).

Dauer einer Integration: Häufige Integrationen sind nur möglich, wenn die Integration zügig von statten geht. Die Dauer jeder Integration sollte also so kurz wie möglich sein. Wenn die Häufigkeit der Integrationen erhöht werden soll, geht das oft einher mit der Verringerung der Dauer für jede einzelne Integration.

Anzahl der Hindernisse (identifiziert, behoben):  Wieviele und welche Hindernisse wurden in einer Iteration identifiziert und behoben? Auf dem Weg der schrittweisen Verbesserung der Arbeitsprozesse ist es entscheidend, Hemmungen zu finden und diese konsequent zu beheben. Es gibt Hindernisse, die jedes Team für sich beheben kann. Das geht häufig schnell. Andere Hindernisse beziehen sich eher auf die Organisation, die das einzelne Team umgibt. Diese Hindernisse können nur durch übergreifende Koordination und Führung behoben werden. Hier ist die Konfliktlinie zwischen Team und Organisation, die zur Verbesserung der gesamten Organisation genutzt werden kann. Die Darstellung solcher Hindernisse, ihre Zuordnung zu einer verantwortlichen Führungskraft und die Visualisierung des Fortschritts bei der Beseitigung der Hindernisse macht deutlich, ob Agilität ernst gemeint ist. Gerade für Führungskräfte ist das ein starker Hebel, der große Wirkung auf jeden Mitarbeiter in der Organisation hat.

Durchlaufzeit (Cycle Time): Diese Kennzahl kommt, ebenso wie die weiter unten aufgeführte Wartezeit, aus der Kanban-Schule. Für jedes Arbeitspaket wird die Zeit des Beginns der Bearbeitung bis zur Fertigstellung gemessen. Kurze Durchlaufzeiten sind besser als lange Durchlaufzeiten. Man kann Durchschnittswerte geordnet nach Prioritätsklassen bilden. Die Durchlaufzeit kann auch in Scrum Teams gemessen werden. Sie sollte in den meisten Fällen kürzer sein, als die Dauer eines Sprints.

Wartezeit (Lead Time): Für jedes Arbeitspaket wird die Zeit des Entstehens des Arbeitspaketes bis zur Fertigstellung gemessen. Diese Zeit ist also mindestens so lange, wie die Durchlaufzeit. Bei Produktvorhaben mit Releaseplanung ist die Wartezeit nicht so aussagekräftig wie die Durchlaufzeit, weil häufig zu Beginn des Vorhabens ein Product Backlog vorbereitet und  im weiteren Verlauf abgearbeitet wird. Je länger das Vorhaben dauert, desto länger werden die Wartezeiten. Diese Metrik hat in diesen Fällen keine Aussagekraft. Daher wird die Messung eher in Umfeldern vorgenommen, in denen keine Releaseplanung nötig ist, weil kontinuierlich neue Arbeitspakete entstehen und nach ihrer Priorität abgearbeitet werden, zum Beispiel bei der Bearbeitung von Fehlertickets. In diesen Fällen ist die mittlere Wartezeit (nach PrioritätsklasseI) ein Indikator dafür, wie lange ein Auftraggeber auf die Behebung seines Tickets warten muss.

Referenzen

[Kniberg und Ivarsson 2012] Henrik Kniberg und Anders Ivarsson, Scaling at Spotify, 2012, siehe: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf

[Kua 2013] Patrick Kua, An appropriate use of metrics, 2013, siehe: http://martinfowler.com/articles/useOfMetrics.html

[Poppendieck 2003] Mary Poppendieck, Measure Up, 2003, siehe: http://www.leanessays.com/2003/01/measure-up.html