Performance eines agilen Teams mit Balanced Scorecard messen

Wie kann man messen, ob sich eine agile Transition erfolgreich verläuft, ob ein agiles Team auf dem richtigen Weg zu Performance ist? Stellt man diese Frage z.B. in einem Scrum-Umfeld, erhält man als Antwort oft: Wir messen die Velocity. Steigt sie, lässt sich daraus eine steigende Performance des Teams ableiten. Dieser Schluss ist gefährlich. Hinweise, wie man es besser machen kann, gibt dieser Artikel.

Was und warum messen?

Warum versucht man in der Regel überhaupt zu messen? Eine sehr allgemeine, jedoch auch plausible Antwort gibt Mike Cohn: Um Unsicherheit zu reduzieren.

Es stellt sich damit die nächste Frage: Welche Unsicherheit möchte ich mit meiner Messung reduzieren? In diesem Artikel geht es um die Unsicherheit, ob eine agile Transition erfolgreich verläuft, also um die Beantwortung folgender beispielhafter Fragen:

  • Hat sich die Investition der Einführung eines agilen Frameworks wie Scrum gelohnt?
  • Entwickeln wie besser Software als vor einem Jahr?
  • Bauen wir bessere Produkte als zuvor?
  • Was sollen wir als nächstes verbessern? Wo haben wir noch Defizite?

Ganz konkret könnte man fragen: Wie entwickelt sich die Performance eines agilen Teams?

Wie die Performance messen?

Wie soll nun so eine Messung aussehen? Wie eingangs erwähnt, halte ich die Standard-Antwort, die ich immer wieder von Teams im Scrum-Umfeld erhalte (siehe oben) für brandgefährlich.

Warum? Eine Messung, die nur auf wenigen – oder wie in diesem Beispiel sogar nur auf einer einzigen – Messgröße basiert, lässt sich sehr leicht manipulieren. Oder wie es Mike Cohn frei übersetzt etwas höflicher ausdrückt: Das Team wird sein Verhalten im Sinne einer optimierten Metrik verändern. Die Teamgeschwindigkeit (Velocity) kann ich als Team ganz leicht optimieren, in dem ich die Komplexität von Backlog Items tendenziell höher einschätze. An der Performance des Teams ändert das jedoch genau gar nichts.

Zielführender ist es, in eine Messung unterschiedliche Sichten einfließen zu lassen; dadurch wird die Messung ausgewogener (balanced), und die Wahrscheinlichkeit von bewusster oder unbewusster Manipulation sinkt.

Hier können wir Anleihe in der Betriebswirtschaft nehmen. Von Kaplan und Norton stammt die Idee der Balanced Scorecard. Sie führen darin die Sichten financial, customer, business processes sowie learning & growth ein. Nun passen diese Sichten nicht optimal, wenn man sie direkt auf einen Organisationsteil anwendet, der Software entwickelt oder den IT-Betrieb gewährleistet.

Balanced Score Card

Feinerweise gibt es eine schöne Anpassung der Balanced Score Card für die Softwareentwicklung bzw. den IT-Betrieb. Sie stammt laut Mike Cohn von Liz Barnett aus einem Artikel für Forrester Research (Metrics for agile Development projects). Dieser Ansatz bezieht folgende vier Sichten in die Messung ein:

  • Betriebliche Exzellenz (Operational Excellence)
  • Ausrichtung auf die Benutzer (User Orientation)
  • Geschäftswert (Business Value)
  • Ausrichtung auf die Zukunft (Future Orientation)

Um eine Balanced Score Card für die eigenen Bedürfnisse zu erstellen, sind nun für jede dieser vier Sichten Ziele zu entwickeln, und für jedes dieser Ziele Indikatoren zu definieren. Bei den Indikatoren erweist es sich als hilfreich, zwischen Früh- und Spätindikatoren zu unterscheiden; mit Hilfe von Frühindikatoren lassen sich schon recht früh erste Messergebnisse erzielen.

Eine Leitlinie bei der Definition von Indikatoren sollte es meiner Meinung nach sein, einfach zu bleiben: Der Aufwand für die Durchführung der Messung muss in einem sinnvollen Verhältnis zu der Unsicherheit stehen, die man mittels der Messung reduzieren möchte.

Mögliche Ziele und Indikatoren

Der Rest dieses Artikels gibt nun Beispiele dafür, was mögliche Ziele bzw. Indikatoren für die oben angeführten vier Sichten sein können; quasi ein Werkzeugkasten, aus dem man für die Erstellung seiner eigenen Balanced Scorecard die passenden Instrumente auswählen kann.

Betriebliche Exzellenz (Operational Excellence)

Ziel Frühindikatoren Spätindikatoren
Produktivität verbessern Anteil von Backlog Items, die je Sprint nicht abgeschlossen werden können Anzahl gelieferter Features je Teammitglied
Anteil der Quellcode-Check-Ins, die in der Nacht oder am Wochenende gemacht werden
Überstunden, die rund um Projektmeilensteine geleistet werden
Voraussagbarkeit verbessern Anzahl von Projekten bzw. Teilprojekten, die innerhalb von +/- einem Sprint gegenüber der Vorhersage zu Projektmitte abgeschlossen werden konnten
Höhere Qualität erreichen Anteil der automatisierten Tests, die in Builds des CI-Systems erfolgreich sind Anzahl der in den ersten vier Wochen nach Release gemeldeten Fehler
Durchschnittlicher Aufwand oder Behebungsdauer für einen Fehler

 

Ausrichtung auf die Benutzer (User Orientation)

Ziel Frühindikatoren Spätindikatoren
Zufriedenere Benutzer Verbesserungen in der regelmäßigen Befragungen von Kundenfokusgruppen Verbesserungen im Net Promoter Score (Weiterempfehlungsrate)
Verbesserungen in Kundenbewertungen der Software (App Stores, Feedback-Formulare, …)
Zufriedenere Stakeholder Verbesserungen in regelmäßigen Abfragen wichtiger Stakeholder, insbesondere auch an Schnittstellen zu anderen Unternehmensbereichen
Verfügbarkeit der Software Geplante und ungeplante Server Downtime pro Jahr ist weniger als X

 

Geschäftswert (Business Value)

Ziel Frühindikatoren Spätindikatoren
Häufigere Releases Release Burndown Charts für alle Projekte gemacht und für alle sichtbar Zumindest eine Major Release alle drei Monate
Mehr Features je Release Anzahl von für die Benutzer sichtbaren Backlog Items je Release
Verschwendung reduzieren Anteil halbfertiger Arbeitsergebnisse Features, die von Benutzern kaum genutzt werden

 

Ausrichtung auf die Zukunft (Future Orientation)

Ziel Frühindikatoren Spätindikatoren
Zufriedenere Mitarbeiter Trend in regelmäßigen Abfragen in Team-Retrospektiven Ausscheidende Mitarbeiter pro Jahr
Anzahl Beschwerden von Mitarbeitern bei HR
Überstunden, die rund um Projektmeilensteine geleistet werden Verbesserungen in Umfragen zu Mitarbeiterzufriedenheit (intern, extern)
Verminderte psychische Belastung von Mitarbeitern (z.B. aus Erhebungen zum Arbeitnehmerschutz)
Verständnis von Agilität verbessern Besuche von agilen Konferenzen oder Fachtagungen Anteil der Mitarbeiter, die Scrum (oder ein anderes eingesetztes agiles Framework) einem Freund in einem anderen Unternehmen weiterempfehlen würden
Gekaufte Bücher zu Agilität
Anzahl von Weiterbildungsveranstaltungen von Mitarbeitern für Mitarbeiter

Fazit

Bei jeder Messung sollte man sich zunächst die Frage stellen, was man mit der Messung überhaupt bezwecken will. Welche Fragen möchte ich beantworten? Welche Konsequenzen möchte ich aus den erhaltenen Antworten ableiten?

In diesem Artikel habe ich eine auf agile Softwareentwicklung angepasste Form der Balanced Score Card vorgestellt, auf die ich zum ersten Mal im Buch Succeeding With Agile von Mike Cohn gestoßen bin. Ich halte diesen Ansatz für sehr zielführend, weil er in die Messung viele von einander unabhängige Messgrößen einbezieht. Damit sinkt das Risiko der Manipulierbarkeit.

Der Mehrwert dieses Artikels besteht (so hoffe ich) daraus, dass ich eine Vielzahl möglicher Ziele bzw. Indikatoren im Sinne eines Werkzeugkastens zusammengetragen habe.

Haben Sie Ideen für weitere Ziele bzw. Indikatoren, mit denen man den Werkzeugkasten füllen könnte? Oder haben Sie Erfahrung mit dem Ansatz der Agilen Balanced Scorecard bzw. einzelnen Zielen und Indikatoren? Ich freue mich über Ihre Kommentare zu diesem Artikel.

Sie finden diesen Artikel interessant? Bitte teilen Sie ihn in ihrem bevorzugten sozialen Netzwerk. Vielen Dank!

2 Kommentare

  1. Thomas Sonntag, 22. Februar 2015 Antworten

    Hallo Gregor,
    vielen Dank für den interessanten Artikel. Das hilft mir bei meiner aktuellen Arbeit wirklich gut weiter. Insbesondere die Indikatoren für Ziel „Voraussagen verbessern“ finde ich interessant. Aber was genau meinst denn mit „gegenüber der Vorhersage zu Projektmitte“? Ist da die Messung der erfolgreichen Sprints schon während der Projektlaufzeit gemeint?

    lieben Dank für die Info

    Thomas

    • Autor
      Gregor Karlinger Freitag, 6. März 2015 Antworten

      Hallo Thomas,
      danke für Dein Feedback, es freut ich, wenn Dir mein Artikel hilfreich erscheint!
      Zu Deiner Frage: Der Indikator gibt an, ob es in einem Projekt gelungen ist, zur Projektmitte eine treffsichere Prognose zum Fertigstellungstermin abzugeben (+/- 1 Sprint zum tatsächlichen Fertigstellungstermin). Einem Scrum Team sollte es ja mittels seiner Velocity laufend möglich sein, eine Prognose zum Fertigstellungstermin abzugeben. Der Indikator verwendet die Projektmitte, da sich da die Velocity des Teams schon recht gut eingeschwungen haben sollte.
      Ich hoffe, das hilft Dir weiter!
      LG, Gregor

Hinterlasse Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*