Produktivitätsmetriken in der Softwareentwicklung: Von der Messung zur Verbesserung

Mit „Wie können wir die Produktivität unserer Entwicklungsteams messen?“ fängt es oft an. Doch eigentlich sind eingangs zwei andere Fragen viel wichtiger.

Denn bevor es um das „Wie?“ geht, sind die beiden zielführendsten Fragen „Wozu wollen wir die Produktivität messen?“ und „Was passiert mit den Messungen?“

Schließlich verschlingt die Einführung und Durchführung von Messungen wertvolle Ressourcen: Es braucht Mitarbeitende, welche die Daten erfassen oder die Systeme dafür vorbereiten, die Ergebnisse analysieren und diese im Unternehmen kommunizieren. Zudem kann der Messprozess selbst aufwendig sein und die Entwicklungsarbeit verlangsamen.

Selbst wenn dies nicht der Fall ist, kann die Beobachtung des Fortschritts das Verhalten der Entwicklerinnen und Entwickler verändern. Möglicherweise in einer Weise, die die eigentlichen Probleme verdeckt oder anderweitig Widerstände hervorruft.

Also sehen wir uns zunächst mal an, was wir eigentlich erreichen wollen und ob sich der Aufwand lohnt.

Lohnt sich das Messen überhaupt?

Für eine erste grobe Iteration der Messfrage bieten sich einige (vermeintlich) einfache Fragen an. Ein guter Start ist:

1. Was ist die konkrete Fragestellung? Je konkreter die Frage, desto wahrscheinlicher ist es, dass das Team vom Messprozess profitiert. Und ein wichtiger Hinweis: Eine gute Problembeschreibung nimmt nicht die Lösung vorweg.
2. Welches Ergebnis erwarten wir und warum? Menschen machen Annahmen über das, was passieren sollte. Indem diese von Anfang an auf den Tisch kommen, lassen sich voreilige Tendenzen ansprechen und nachträgliche Erklärungsversuche der Ergebnisse vermeiden.
3. Welche Maßnahmen werden ergriffen, wenn die Daten unsere Erwartungen bestätigen? Wenn hinterher nichts passiert, hat das Messen keinen Sinn. Beachte, dass eine Maßnahme durchaus „es bleibt, wie es ist“ sein kann – nur dann eben untermauert mit Daten statt aus dem Bauch heraus.
4. Werden bei einem negativen Ergebnis entsprechende Maßnahmen ergriffen? In vielen Fällen wird ein negatives Ergebnis keine Entscheidung ändern. Es können andere Faktoren eine Rolle spielen, die jedes negative Ergebnis überstimmen würden.
5. Wer entscheidet über Maßnahmen aufgrund der Ergebnisse? Und wann? Wichtig ist, dass der Mensch, der die Messung anfordert, auch befugt ist, Maßnahmen zu ergreifen. Und dass diese Maßnahme auch zeitnah ergriffen werden. Denn das Ziel der Messung der Entwicklungsproduktivität ist letztlich, nachhaltige Veränderung herbeizuführen und Geschäftsentscheidungen positiv zu unterstützen.

Je nach Antworten auf diese Fragen kann es sein, dass hier bereits Schluss ist mit dem Thema Messungen. Einige dieser „stoppenden“ Punkte werden im Folgenden behandelt.

Gründe, warum Messungen nicht sinnvoll sein könnten

Es gibt legitime Gründe, die Produktivität eines Entwicklungsteams oder -prozesses nicht zu messen:

1. Wir können es uns derzeit nicht leisten, den Prozess, die Tools oder das Team zu ändern. Zeit- oder finanzielle Einschränkungen können hier Gründe sein. Beispielsweise könnten wir feststellen, dass ein schnelleres Build-Tool zwar wöchentlich Stunden sparen würde, aber die Umstellung die Entwicklung unterbrechen würde – und vor einem wichtigen Meilenstein könnten wir uns diese Unterbrechung nicht leisten.
2. Die Ergebnisse werden bald durch andere Faktoren ungültig. Beispiele hierfür könnten die Messung des Softwareprozesses einer Organisation kurz vor einer geplanten Umstrukturierung sein. Oder die Messung der technischen Schulden für ein veraltetes System, das nur noch rudimentär gepflegt und/ oder abgelöst werden soll.
3. Die Entscheidungsträger haben starke Meinungen. Manchmal treffen wir auf Menschen mit unerschütterlichen Überzeugungen. Manche Stakeholder vertrauen niemals Umfragedaten. Andere lassen sich am besten durch eine überzeugende Erzählung beeinflussen, die auf wenigen Interviews basiert. Und wieder andere vertrauen nur genauen Analysen.
4. Die Ergebnisse werden nur als Prestigemetriken verwendet. Dies ist vielleicht der häufigste Grund, warum eine Messung keinen nachhaltigen Sinn hat. Oft haben Menschen Entscheidungen aus mehreren Gründen geplant, und die Verbesserung des Softwareentwicklungsprozesses ist nur ein Ziel von vielen.
5. Die verfügbaren Metriken sind nicht präzise genug. In manchen Fällen sind die benötigten Metriken einfach nicht verfügbar. Es kann verlockend sein, andere, weniger präzise Metriken zu verwenden (z. B. Lines of Code). Die Ergebnisse werden jedoch kaum „actionable“ sein.

Nachdem wir nun verstanden haben, wann Messungen sinnvoll sind – und wann wir uns den Aufwand sparen können – widmen wir uns der Frage: Welche Metriken kommen zum Einsatz?

Auswahl passender Metriken

Es bieten sich bewährte und fundierte Sets an, wie die vier DORA-Metriken. Ebenso denkbar ist die Nutzung von Denkwerkzeugen wie dem SPACE-Framework, um eine vollumfängliche Auswahl zu treffen.

Zusätzlich hilft es, über zwei Dimensionen nachzudenken:

1. Was ist der Einsatzbereich? Eine Entwicklungsorganisation nutzt beispielsweise Metriken, um die eigene Produktivität zu bewerten und kontinuierliche Verbesserungen auf Organisationsebene voranzutreiben. Daten dienen in diesem Kontext dazu, um die Ausrichtung auf Geschäftsziele sicherzustellen, die Qualität zu erhöhen und die Entwicklungsgeschwindigkeit zu verbessern. Systemteams nutzen Metriken, um zu verstehen, wie Entwicklungsteams mit internen Systemen interagieren. Diese Metriken sind für diese Teams existenziell, da sie damit die Auswirkungen ihrer Arbeit aufzeigen und den Erfolg ihrer Investitionen messen.
2. Welcher Aktivität dient die Metrik? So sind Diagnosemetriken übergeordnete Metriken, die Einblicke in Trends im Laufe der Zeit bieten. Sie werden mit geringerer Frequenz erfasst und eignen sich für richtungsweisende oder strategische Entscheidungen. Verbesserungsmetriken treiben Verhaltensänderungen an. Sie werden mit höherer Frequenz erfasst und konzentrieren sich auf kleinere Betrachtungsgegenstände.

Der Weg von einer übergeordneten diagnostischen Metrik zu einer handlungsorientierten Verbesserungsmetrik kann durch ein Metrik-Mapping unterstützt werden:

• Wir beginnen mit der Auswahl einer Diagnosemetrik
• Im zweiten Schritt denken wir über die Grenzen dieser Metrik nach: Was ist die große Idee hinter der Metrik? Was sind die Start- und Endpunkte der gemessenen Prozesse? Welche Bereiche des Systems müssten verbessert werden, um diese Metrik zu beeinflussen? Was denken die Entwicklerinnen und Entwickler darüber?
• Die Antworten auf diese Fragen liefern uns kleinere, besser umsetzbare Messungen, die für Teams leichter zu verstehen sind und eher in deren Einflussbereich liegen

Jetzt haben wir gute Gründe für eine Messung, ein passendes Set an Metriken und jetzt stellt sich natürlich die Frage: Was machen wir jetzt damit?

Erste Schritte zur Operationalisierung

Erwartungen für die Verwendung von Metriken managen

Die Schwierigkeit beginnt, wenn Metriken andere lenken und nicht mehr nur Transparenz in unbekannte kollektive Sachverhalte von den Betroffenen für die Betroffenen bringen sollen.

Ein verantwortliches Handeln ist damit zunächst oft wichtiger als die Auswahl der richtigen Metrik. Alles andere beschädigt das Vertrauen in die Hierarchie und führt zu Widerständen.

Ohne klare Erwartungen und ein System der Verantwortlichkeit ist es leicht, dass Metriken und kontinuierliche Verbesserung hinter Lieferdruck, alten Gewohnheiten oder Machtstrukturen zurücktreten.

Deshalb muss die Führungsebene die Bedeutung von Metriken bei der Bewertung des Erfolgs und der Festlegung von Prioritäten betonen.

Ebenso wichtig für die beidseitige Kommunikation und Akzeptanz ist die Integration der Metriken in organisatorische Arbeitsabläufe. Die Ergebnisse der Messungen können z. B. als fester Agendapunkt in Retrospektiven, Planungsmeetings oder Bereichs-Meetings integriert werden.

Schlussendlich müssen die zentralen Botschaften immer und immer wieder wiederholt werden. Und dann gleich nochmal.

Veränderung wird zum Ziel

Wie eingangs beschrieben sind Metriken nur nützlich, wenn sie zu Maßnahmen führen. Dabei kann eine Geschichte helfen, um Kontext zu bieten, anstatt nur nackte Zahlen zu präsentieren.

Ebenfalls denkbar ist der Vergleich der eigenen Metriken mit Branchen-Benchmarks. Das kann zu Handlungen motivieren. Allerdings auch ein Wort der Vorsicht: Benchmarks sollen der Orientierung dienen und nicht selbst zum Ziel werden. „Wir haben Benchmark-Level X erreicht“ wird höchstwahrscheinlich keinen Kunden interessieren.

Und Metriken ermöglichen im Coaching und der Beratung, Fragen stellen zu können – die mindestens zum Nachdenken und Hinterfragen anregen.

Fazit

Das Messen der Produktivität von Entwicklungsteams sollte mit zwei grundlegenden Fragen beginnen: „Wozu wollen wir messen?“ und „Was passiert mit den Ergebnissen?“.

Messungen sind nur sinnvoll, wenn sie zu konkreten Maßnahmen führen und von Entscheidungsträgern unterstützt werden. Anstatt überstürzt zu messen, sollte man zuerst prüfen, ob der Aufwand gerechtfertigt ist, passende Metriken auswählen und diese sinnvoll in Arbeitsabläufe integrieren.

Wichtig ist ein verantwortungsvoller Umgang mit den Daten, klare Kommunikation der Ziele und die Sicherstellung, dass Metriken als Werkzeug zur Verbesserung dienen – nicht als Selbstzweck oder bloßes Prestigeobjekt.

Schnapp Dir die 7 Fragen für hochproduktive Entwicklungsteams und buche Deine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Dich am wirkungsvollsten unterstützen kann.