Fortschritt messbar machen bei agiler Entwicklung
20.02.2020 | Oliver Seitz | 9 min Lesezeit
merken
Stern Icon
Stern Icon
Briefumschlag Iconper E-Mail erinnern X Icon
Ladekreisel
Bitte geben Sie eine E-Mail Adresse ein!
Das Datum darf nicht in der Vergangenheit liegen!
Stern Icondiesen Artikel merken
Stern Icondieser Artikel ist auf der Merkliste

Wie wird agile Entwicklung gemessen?

-

Auf dem Weg hin zu agiler Softwareentwicklung haben wir bereits erfahren, dass Agilität nicht ganz so schnell erreicht ist wie es sich manch einer vielleicht vorstellt. Neben wichtiger Grundpfeiler agiler Softwareentwicklung, beispielsweise nach Methoden wie SCRUM, wurde auch die große Bedeutung guter Kommunikation und effektiver Zusammenarbeit im Entwickler Alltag thematisiert. Dieser Teil der Artikelreihe widmet sich vor allem der Messbarkeit agiler Projekte durch die Analyse von KPIs (Key Performance Indicators) und befasst sich darüber hinaus mit der Bedeutung eines konstanten Tempos sowie technischer Exzellenz bei der Entwicklung. Somit richtet sich dieser Beitrag nicht nur an Entwickler sondern ist auch für diejenigen interessant, die täglich mit Entwicklern zusammenarbeiten.

Metriken und Analysen

-

Eines der Prinzipien des Agilen Manifests definiert „funktionierende Software als wichtigstes Fortschrittsmaß“. Was erneut einfach klingt, entpuppt sich oftmals als nicht in vollem Umfang verstanden. Warum ist funktionierende Software eigentlich das wichtigste Fortschrittsmaß für agile Entwicklung?

Zuerst muss geklärt werden, was funktionierende Software ausmacht. Um im Rahmen zu bleiben, definieren wir sie entlang drei zentraler Kriterien:

 

  • Die Software enthält keine Fehler, die die Arbeit behindern
  • Die Software läuft in dem Maße performant, welches die zu verrichtende Arbeit erforderlich macht
  • Die Software liefert für den Anwender einen realen, messbaren Mehrwert

 

Um diese Kriterien messbar zu machen, gibt es viele mögliche Fortschrittsindikatoren. Hier ein paar als Beispiel:

 

  • Abgeschlossene Tickets / Tasks
  • Abgeschlossene Story Points
  • Gebuchte Zeiten
  • Projektlaufzeit
  • Anzahl der stattgefundenen Meetings
  • Ausgelieferte Softwareversionen

 

Klingt gut, oder? All das sind messbare Kriterien, die erfasst und ausgewertet werden können. Abgeschlossene Tickets geben an, wie viele neue Features der Kunde erhalten hat. Gebuchte Zeiten offenbaren, wie viel Arbeit bereits an einem Projekt verrichtet wurde. Je länger ein Projekt dauert desto mehr Fortschritt ist sichtbar. Genauso verhält es sich mit den Meetings, denn mehr Meetings klären potenziell mehr Sachverhalte als wenige Meetings. Wie viele Softwareversionen ausgeliefert wurden ist fast schon analog wie die Anzahl abgeschlossener Tickets zu sehen.

Bemerkt man den ironischen Unterton bereits? Wir Menschen neigen dazu liebevoll und mit viel Mühe Metriken, Analysen und Dashboards zu erstellen. Ob das Ganze auch noch einen kausalen Zusammenhang hat, hinterfragen wir eher selten. Aber wie genau misst man funktionierende Software? Sicherlich kann die Anzahl der abgeschlossenen Tasks ein sehr guter Erfolgsindikator sein. Allerdings sollte dazu auch betrachtet werden, wie viele der abgeschlossenen Tasks für den Kunden und Anwender einen realen Mehrwert liefern oder wie viele überhaupt fehlerfrei umgesetzt wurden, eben ob es sich um funktionierende Software handelt.

Ich fasse zusammen: Metriken sind großartig, allerdings sollten wir dazu übergehen die Kausalität unserer Metriken kritisch zu hinterfragen, um nicht am Ende ein trügerisches Gesamtbild zu erhalten oder sogar die falschen Gegenmaßnahmen einzuleiten.

Gleichbleibendes Tempo

-

Ein guter Zeitpunkt die eigenen Auswertungen zu hinterfragen ist immer dann, wenn man eine Verbesserung erkennt. Warum? Nun, nehmen wir an, ein Team schafft pro Woche durchschnittlich 10 Tasks (für alle die bereits erkennen, dass die Maßeinheit „Task“ überhaupt nicht geeignet ist: stimmt, darauf komme ich auch gleich zurück).

Nach einigen Wochen erledigt das Team zunächst 11 und dann 12 Tasks pro Woche. Ist die Performance jetzt gestiegen? Oder hat das Team vielleicht nur damit begonnen generell kleinere Tasks zu schätzen? Sind nur kleine Tasks angefallen? Oder ist vielleicht die Qualität der Arbeit gesunken und es werden nur deshalb mehr Tickets erledigt? Die genaue Auswertung fällt schwer und ist vermutlich sogar unmöglich.

Das hat mitunter folgende Gründe:

 

  • Die Maßeinheit „Task“ sagt nichts über den Aufwand, das Risiko oder die Komplexität der Aufgabe aus.
  • Eine sinkende Qualität macht sich eventuell erst Wochen später bemerkbar, vor allem dann, wenn nicht kontinuierlich ausgeliefert und getestet wird. Bis dahin wird die Performance des Teams längst als gestiegen angesehen.
  • Es gibt keine Ereignisse, die eine gesteigerte Performance begründen würden. Sinkt die Leistung, wird sofort nach Ursachen geforscht. Wieso nicht bei gestiegener Performance?

 

Das Agile Manifest sagt hierzu in seinen Prinzipien, dass agile Teams in der Lage sein sollten über lange Zeit eine gleichbleibende Performance abzuliefern. Dazu noch eine kleine Anmerkung von mir: Performance darf sich auch steigern, allerdings sollte es dann handfeste Ursachen dafür geben. Dazu können zum Beispiel eine bessere Entwicklungsumgebung oder bessere Tools zum Ausliefern der Software zählen. Hat eine Verbesserung (auf den ersten Blick) keine Ursache, sollte höchste Achtsamkeit bestehen ob nicht etwa die Qualität der Arbeit gesunken ist. Oftmals passiert so etwas unabsichtlich. Wie immer gilt: Wir suchen keine Schuldigen, sondern Ursachen.

Einleitend hatte ich erwähnt, die Einheit „Task“ ist nicht optimal. Mittlerweile verstehen wir, dass diese Einheit aus verschiedenen Gründen nicht nur nicht optimal, sondern sogar grundfalsch ist. Es mag andere Bereiche geben, in denen diese Messeinheit sehr gut funktioniert, agile Softwareentwicklung zählt hier aber nicht dazu.

Jetzt möchte ich allerdings einen kleinen Schwenk machen und von Metriken, Analysen, kausalen und akausalen Zusammenhängen zu einem technischeren Gebiet kommen.

agile Entwicklung digatus

Technische Exzellenz

-

Wir Entwickler neigen zu folgenden Anfälligkeiten: „Premature Optimiziation“ und „Over Engineering“. Ersteres bezeichnet die Tendenz, Dinge zu früh zu optimieren, die zum einen nicht optimiert werden müssen und zum anderen eventuell sowieso wieder gelöscht werden. Over Engineering ist ein natürlicher Prozess im Leben eines Entwicklers, bei dem er eine Lösung so technisch exzellent und ausgefeilt, abstrakt und generisch abliefert, dass die Zeit für eine zweckerfüllende UND technisch exzellente Lösung viel geringer gewesen wäre als für die Abgelieferte.

Während das Agile Manifest in seinen Prinzipien technische Exzellenz explizit fordert, weist es allerdings auch darauf hin, dass die nicht getane Arbeit maximiert werden sollte, eben um die genannten Phänomene zu begrenzen.

Die Aufgabe als Entwickler ist es, Anforderungen von Kunden möglichst präzise und qualitativ hochwertig umzusetzen, ohne sich dabei in unnötigen und keinen Mehrwert liefernden Details zu verrennen.
Die Aufgabe eines guten Product Owner, SCRUM Master oder wie es manchmal noch genannt wird Projektmanager(in) ist es, ein Auge darauf zu haben ob sich ein Team in Details verliert und gleichzeitig Wert auf Code Reviews, Unit Testing usw. zu legen.

In meinen Augen sollten diese beiden Punkte, „technische Exzellenz“ und „Einfachheit der Lösung“ des Agilen Manifests zusammengefasst werden. Etwa so:
„Ständiges Augenmerk darauf, technische Exzellenz und gutes Design mit minimalem Aufwand zu erreichen“

Funktionierende Metriken

-

Was sind denn nun gute Metriken anhand derer agile Teams gemessen werden können? Nun, dafür muss man sich überlegen, was genau gemessen werden soll. Gilt es das gleichbleibende Tempo zu überwachen, ist die sogenannte Velocity eine erprobte Metrik. Dabei wird die Anzahl der pro Sprint erledigten Story Points gemessen. Ziel ist es, diese Zahl über längere Zeit hinweg konstant zu halten. Verwendet man kein Sprint-Basiertes Vorgehensmodell, wie zum Beispiel Kanban, muss die Velocity über selbstgewählte Zeiträume ermittelt werden.

Der Burn Down Chart dagegen gibt an, wie der Fortschritt des Teams im aktuellen Sprint ist. Hier ist kein konstanter Verlauf gewünscht, sondern eine konstante Abnahme der Anzahl an offenen Tasks. Der Burn Down Chart gibt damit an, wie gut die User Stories in Sub Tasks unterteilt wurden und wie gut die Minimierung des Work in Progress funktioniert.

Selbstverständlich sind das nicht die einzigen sinnvollen Metriken, jedoch die wohl am verbreitetsten. Die Anzahl der reklamierten Fehler kann zum Beispiel auch eine gute Aussage darüber sein, wie stabil das Softwareprodukt tatsächlich ist.

Please try this at home or at work!

-

Ich möchte diesen Teil der Artikelreihe jetzt erstmal beenden, bevor ich mich im Over Engineering wiederfinde und verbleibe mit zwei Aufgaben zum Mitmachen:

  1. Analysiert eure Auswertungen, Metriken und KPIs. Gibt es akausale Zusammenhänge?
  2. Versucht die nächste User Story so simpel wie irgend möglich umzusetzen. Sie soll weiterhin die Abnahmekriterien erfüllen! Was hättet ihr normal anders gemacht, wäre das bereits zu viel gewesen?

In diesem Sinne: Please try this at home or at work!

Autor Profilbild

Oliver Seitz

-