Kürzlich fand in der Dübendorfer Samsung Hall die "Zwei in einer"-Konferenz Agile Leadership Day statt. Mehrere hundert Besucher trafen sich an diesem wunderschönen Herbsttag, um sich mit Themen rund um die digitale Transformation und den Einsatz Agiler Methoden weit über den Bereich Softwareentwicklung hinaus zu befassen.

Einen Überblick über die insgesamt drei Keynotes und 24 Vorträge in vier Tracks geben zu wollen, wäre vermessen. Darum picken wir hier einen einzelnen heraus: "Misstrauensvotum: Wie Sie Ihre Organisation mit Metriken und Bonus zu Tode steuern." Misstrauen? Tod? Natürlich lockt das einen Journalisten an. Aber nicht nur Journis, der kleine Saal, in dem die beiden Finnova-Leute Sebastian Friedsam und Dominic Wolf ihren Vortrag hielten, war gerammelt voll und viele Zuhörer mussten mit Stehplätzen Vorlieb nehmen.

Der Lenzburger Kernbankensoftwarehersteller Finnova, so erklärte der Release Train Engineer Friedsam eingangs, begann seine eigene Agile Transformation vor drei Jahren, basierend auf dem "Scaled Agile Framework" (SAFe). Danach sei aber die Frage aufgekommen: "Wie messen wir den Erfolg?" Uuund… Wie verteilen wir den leistungsbezogenen Bonus?

In der Branche der Softwareentwickler, führte Friedsam aus, findet man eine ganze Reihe von Metriken, mit denen versucht wird, die Leistung von Agilen Teams beziehungsweise deren Mitgliedern zu messen. Sie alle könnten aufschlussreiche Informationen liefern. Sie mit Leistungsboni zu verknüpfen, berge aber durchgehend Gefahren.

Da gibt es beispielsweise die individuelle oder Team-"Velocity" und deren Entwicklung über die Zeit. Um sie zu messen muss aber allerdings die geschätzte, innerhalb einer bestimmten Zeit umgesetzte Komplexität eines Projekts einfliessen.

Koppelt man die Velocity an den Bonus, wird dies mit grosser Wahrscheinlichkeit dazu führen, dass Teams die Komplexität höher schätzen als sie eigentlich ist, so Friedsam. Zudem könne eine "Illusion von Vergleichbarkeit" entstehen, auch wenn die Vergleichbarkeit kaum vorhanden ist.

Gemessen werden gerne auch "Lines of Code" beziehungsweise die schiere Menge von produziertem Software-Code, anhand von Zeilen oder Zeichenzahlen oder manchmal auch der Menge von Check-Ins in ein Repository. Insbesondere wenn es Abweichungen vom normalen Schnitt gibt, kann dies ein Indikator für Probleme sein.

Wenn damit aber Teams oder Personen verglichen werden, kann dies laut Friedsam unfair sein. Unterschiede in Programmiersprachen verhindern direkte Vergleiche, genauso wie die Komplexität einzelner Module innerhalb einer Software.

Die Verknüpfung mit Geld wiederum kann Mitarbeitende unter anderem dazu verlocken, Code redundant zu erstellen und somit die Qualität und Wartbarkeit zu gefährden. Auch bestehe ein Anreiz, Good Practices und Coding Guidelines zu umgehen, um möglichst viel zu produzieren.

Wer "technische Schulden" misst, versucht die Menge von "Altlasten" in einem Code abzuschätzen, die in Zukunft beseitigt werden sollten, oder immer wieder Mehrarbeit beim Programmieren verursachen können. Sie entstehen unter anderem durch "Quick" oder "Dirty Fixes" bei denen sie zugunsten eines schnellen Resultats bewusst in Kauf genommen werden. Für die Messung sollten sie von den Entwicklern selbst markiert werden.

Wenn eine solche Markierung allerdings negative finanzielle Folgen für die Entwickler hat, tendieren die Schulden allerdings dazu, auf mirakulöse Weise zu verschwinden. Nicht, weil sie wirklich nicht mehr eingegangen werden, sondern weil sie nicht mehr geflaggt werden.

Mit der Zahl der "Ticket-Abschlüsse" kann man versuchen, Kunden, behobene Fehler oder dem Kunden gelieferten Mehrwert zu messen.

Wenn man sie aber mit einem Bonus verbindet, so Friedsam, würden oft Kompromisse bezüglich der Qualität beobachtet. Auch würden Tickets beziehungsweise User-Stories oft in kleinere Elemente aufgeteilt.

Unternehmen versuchen manchmal auch, die Wertschöpfung eines Features, beziehungsweise den dadurch generierten Umsatz im Verhältnis zum Aufwand zu messen. Eine Auswirkung davon kann sein, dass "wertvolle" Vorhaben auch attraktiver für die Mitarbeitenden werden.

Allerdings warnt Friedsam, dass Architektur, Aufwendungen für Wartbarkeit und Qualität gerne in den Hintergrund geraten, wenn die Entwickler vom Bonus motiviert selbst an der Wertschöpfung schrauben. Ausserdem gebe es, wie bei allen Profit-Center-Ansätzen, zusätzliche Probleme falls Zulieferungen durch andere Teams verrechnet werden sollen.

Und wie steht es mit etwas harmlos Tönendem, der Zahl der "Kudos" beziehungsweise Dankeschöns, die Entwickler erhalten, wenn sie anderen helfen und ihr Wissen teilen?

Auch diese Metrik ist laut Friedsam nicht so harmlos, wenn sie mit einem Bonus verbunden wird, denn dadurch kann das Einheimsen von Kudos das Ziel werden, und nicht mehr das Erreichen eines Sprint Goals.

Was also misst man nun bei Finnova, um Boni zu verteilen? Die schlichte Antwort laut Dominic Wolf, Abteilungsleiter und stellvertretender Bereichsleiter ist: Nichts.

Finnova selbst wolle aus dem geschilderten Erkenntnissen Konsequenzen ziehen und vom variablen und individuellen Bonus wegkommen. Ersetzt werden soll er durch ein "faires und marktgerechtes" Fix-Salär sowie eine Beteiligung der Mitarbeiter am Unternehmenserfolg. Individuelle Anreize sollen trotzdem durch eine konsequente Trennung der Leistungsbeurteilung und der Personal-Entwicklung gegeben werden. Dies soll die Aufmerksamkeit auf die persönliche Weiterentwicklung und nicht das Geld lenken und gleichzeitig die Angst vor der klassischen "Bonus-Strafe" reduzieren.

Aber dieses Ziel ist leichter geschildert, als erreicht, Finnova befindet sich erst auf dem Weg dahin.

So könne man zwar relativ leicht herausfinden, so Wolf, was ein marktgerechter Lohn sei. Aber was ist ein "fairer" Lohn? Dies sei, abhängig von einer Vielzahl von Faktoren wie Ausbildung, Alter, Erfahrung, Position und so weiter sehr individuell. So lange keine Lohn(modell)transparenz herrsche, werde es immer Diskussionen darüber geben, was fair ist.

Und auch die Beteiligung der Mitarbeitenden am Unternehmenserfolg ist nicht trivial. Gegenwärtig versucht es Finnova mit einem Teambonus. Die Teammitglieder selbst sollen entscheiden, wie dieser verteilt wird oder was sonst damit gemacht werden könnte. (Hans Jörg Maron)