Performance eines agilen Teams mit Balanced Scorecard messen

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.

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)

Ausrichtung auf die Benutzer (User Orientation)

Geschäftswert (Business Value)

Ausrichtung auf die Zukunft (Future Orientation)

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!