Software-Engineering-Verantwortliche sollten eine effektive Möglichkeit haben, um den Fortschritt zu visualisieren, Engpässe zu identifizieren und Trends über mehrere Teams hinweg zu beobachten. Nur so können sie rechtzeitig reagieren, bevor eine Deadline verpasst wird. Sie können ausprobieren, welche Struktur und welches Timing am besten für Meetings passen, und aussagekräftiges Feedback geben, ohne sich mit Dingen zu befassen, die in andere Zuständigkeitsbereiche fallen. Anschließend können sie die Auswirkungen dieser Entscheidungen messen.

Manager können den Fortschritt eines Teams anhand verschiedener Kennzahlen beurteilen. Eine davon ist der sogenannte Code-Churn. Von Code-Churn spricht man, wenn ein Entwickler seinen eigenen Code neu schreibt, kurz nachdem er eingereicht wurde (in der Regel innerhalb von drei Wochen). Churn ist ein natürlicher Teil des Engineering-Workflows, denn ein Entwickler wird seine Arbeit immer wieder anschauen, überprüfen und optimieren. Eine ungewöhnlich hohe Churn-Rate oder unerwartete Fluktuationen können allerdings Indikatoren dafür sein, dass etwas nicht stimmt.

Durch Beobachtung der Code-Churn-Entwicklung können Führungskräfte erkennen, wenn ein Termin gefährdet ist, ein Software-Ingenieur Probleme hat und nicht mehr weiterkommt oder es Schwierigkeiten mit externen Stakeholdern gibt.

In diesem Leitfaden geht es darum, was Code-Churn genau ist, was es nicht ist und was Sie bei einem unerwarteten Anstieg tun können.

Unter Code-Churn versteht man Code, der kurz nach der Entstehung neu geschrieben oder gelöscht wird. Das ist normal und gehört zum Entwicklungsprozess. Besonders am Anfang eines Projekts, wenn es für ein Problem noch keine konkrete Lösung gibt, sind Entwickler häufig damit beschäftigt, sich ihre Arbeit wieder anzusehen, zu überprüfen, Überarbeitungen vorzunehmen und verschiedene Lösungen auszuprobieren.

Die Churn-Rate hängt dabei von mehreren Faktoren ab, etwa von den Teams, einzelnen Entwicklern, Projekttypen und davon, wo genau sich das Projekt im Entwicklungslebenszyklus befindet. Unterschiedliche Mitarbeiter und Teams werden unterschiedliche Churn-Raten haben, die für sie „normal“ sind, je nach Workflow und Projekttyp (z. B. neues Problem, bekanntes Problem, schnelle Lösung etc.). Daher sollten Führungskräfte ein Gefühl dafür haben, was „normal“ für ihre Teams ist, damit sie Unregelmäßigkeiten besser identifizieren können.

Nur wenn der Code-Churn unerwartet deutlich über oder unter dem „normalen“ Level des Mitarbeiters oder Teams liegt, besteht Grund zur Sorge. Die Verantwortlichen sollten solche Ausreißer erkennen können, besonders zum Ende einer Deadline hin, da das Projekt in dieser Phase gefährdet sein könnte.

Code-Churn ist ein scheinbar klares Konzept, das allerdings oft missverstanden wird. Viele glauben fälschlicherweise, dass Teams eine niedrige Code-Churn-Rate anstreben sollten und dass Code-Churn ein Hinweis auf einen fehlerhaften Workflow ist. Nichts davon trifft zu. Die Kennzahl ist sehr nützlich für Software-Engineering-Verantwortliche und kann dem ganzen Team zugutekommen. Daher lohnt es, diesen Begriff noch mal genau unter die Lupe zu nehmen.

Tests und Überarbeitungen sind natürliche Schritte im Softwareentwicklungsprozess und je nach Entwickler und Team kann die Churn-Rate variieren. Eine gewisse Churn-Rate ist immer zu erwarten, besonders zu Beginn eines Projekts oder wenn es um neue und komplexe Probleme geht.

Die Alarmglocken sollten nur dann läuten, wenn die Code-Churn-Rate wesentlich über oder unter der Norm liegt – besonders in den letzten Phasen eines Sprints oder kurz vor einer Deadline

Das Data-Science-Team von GitPrime hat die Code-Commit-Muster von über 85.000 Software-Ingenieuren verglichen. Dabei hat es herausgefunden, dass Code-Churn bei 13 bis 30 Prozent aller Code-Commits vorliegt (das entspricht einer Effizienz von 70–87 %); bei einem typischen Team liegt der Code-Churn bei 25 Prozent (Effizienz von 75 %). Ein bestimmtes Churn-Niveau ist also zu erwarten – eine ungewöhnlich niedrige Churn-Rate könnte sogar darauf hinweisen, dass ein Software-Ingenieur zu schnell und dafür ungenau arbeitet.

Je nach Projektphase kann die Churn-Rate variieren. Bei einem planmäßig laufenden Projekt könnte die Churn-Rate zu Beginn höher sein (da Software-Ingenieure hier in der Regel verschiedene Lösungen für ein Problem ausprobieren) und zum Ende hin niedriger, wenn eine passende Lösung gefunden und optimiert wurde.

Wenn Sie eine unerwartete Änderung im Code-Churn bemerken – besonders wenn die Deadline näher rückt –, sollten Sie der Sache auf den Grund gehen. Haben Sie diese Anomalie in der Churn-Rate am Ende des Sprints, bei mehreren Sprints, im selben Team beobachtet? Vielleicht hat der zuständige Produktverantwortliche seinem Team unklare Spezifikationen gegeben. Oder haben Sie es mit einem übertrieben perfektionistischen Software-Ingenieur zu tun, der seinen Code so lange überarbeitet, bis er weit über dem branchentypischen Standard liegt? Teilen Sie Ihren Mitarbeitern mit, was „gut genug“ für Sie bedeutet, oder lassen Sie sie die Arbeit eines anderen Entwicklers anschauen und heben Sie hervor, was Ihnen daran besonders gut gefällt.

Ungewöhnlich hohe Code-Churn-Raten hängen oft mit Faktoren außerhalb des normalen Entwicklungsprozesses zusammen. Setzen Sie sich mit diesen Faktoren auseinander, um Probleme im Entwicklungsprozess zu lösen. So kann sich Ihr Team mehr auf das Wesentliche konzentrieren, anstatt sich mit unklaren Spezifikationen herumzuschlagen oder auf die Hilfe anderer zu warten.

Im Folgenden werfen wir einen Blick auf typische Workflows und Gegebenheiten, die zu einer ungewöhnlich hohen Churn-Rate führen können, sowie auf mögliche Lösungen.

Eine hohe Churn-Rate ist normal, wenn Software-Ingenieure neue Features ausprobieren und verschiedene Lösungen für ein Problem testen. Häufig findet am Anfang eines Projekts das Prototyping statt, vor allem wenn es sich um ein neues oder unbekanntes Projekt handelt (tatsächlich könnte eine ungewöhnlich niedrige Churn-Rate zu Beginn ein Hinweis dafür sein, dass das Projekt nicht nach Plan läuft).

Bei Sondierungsprojekten machen Entwickler oft Abstriche bei den Code-Standards, um schneller zu einem Proof of Concept zu kommen, und überarbeiten den Code später noch mal, sobald eine passende Lösung gefunden wurde. Obwohl die Churn-Rate auf kurze Sicht höher ist, erweist sich diese Vorgehensweise dennoch als produktiv, da neue Ideen schneller erprobt werden. Bei neuen Designs, Prototypen und PoCs ist es nichts Ungewöhnliches, dass große Teile des Codes neu geschrieben werden.

Ist ein Software-Ingenieur mit Prototyping beschäftigt, sollten Sie ihn nicht unterbrechen. Wenn ein Termin ansteht, der nicht absolut dringend ist, sollten sie ihn verschieben – oder teilen Sie Ihrem Ingenieur mit, dass Sie um seinen vollen Terminplan wissen und er nur an dem Meeting teilnehmen soll, wenn er das wirklich möchte.

Sollte der Ingenieur aber wesentlich mehr Zeit und Aufwand in das Prototyping investieren, als Sie normalerweise für diese Aufgabe erwarten würden, sollten Sie lieber nachfragen und sich mit ihm austauschen. Vielleicht ist das Problem komplexer als alles andere, was er bisher hatte. Möglicherweise versteht er bestimmte Aspekte des Problems nicht ganz – oder alles läuft nach Plan und er braucht nur deswegen so lange, weil er besonders präzise arbeitet.

Das Prototyping ist eine gängige und bewährte Vorgehensweise. Wichtig ist, dass man ein Gefühl dafür hat, wann das Prototyping ungewöhnlich lange dauert oder den erwarteten Zeitraum überschritten hat. Stellen Sie sicher, dass die für das Prototyping genutzte Zeit sich in einem angemessenen Rahmen hält – sowohl was das Unternehmensrisiko anbelangt als auch den Nutzen, den Sie sich von diesem Feature erhoffen.

Zu Perfektionismus kann es kommen, wenn ein Ingenieur unter „gut genug“ etwas anderes versteht, als das im Unternehmen der Fall ist. Wenn ein Ingenieur ständig Code überarbeitet oder neu schreibt und dabei keine wesentliche Funktionalität bzw. keinen wirklichen Mehrwert hinzufügt, wirkt sich das negativ auf die Produktivität und somit auf das Ergebnis aus. Wahrscheinlich könnte er seine Zeit anderweitig besser nutzen.

Ein Hinweis auf Perfektionismus ist eine hohe Churn-Rate in den mittleren bis späten Phasen eines Sprints oder Projekts, nachdem die Arbeit eigentlich schon bereit für die Produktion war. Der Ingenieur schreibt große Teile seiner Arbeit um, ohne wesentliche Funktionen oder einen größeren Mehrwert zum ursprünglichen Code hinzuzufügen. Nicht selten zeigt der Ingenieur dieses Verhaltensmuster bei mehreren Sprints. Wenn Sie also mal bei einem Projekt Perfektionismus vermuten, werfen Sie einen Blick auf vorherige Arbeiten, um sicherzustellen, dass es sich nicht um eine einmalige Sache handelt.

Das „Feintuning“ – wenn ein Ingenieur in den letzten Phasen vor einem Release und danach Lösungen für verbleibende Probleme sucht (die manchmal bereits im Review-Prozess identifiziert wurden) und geringfügige, aber häufige Commits mit erhöhter Churn-Rate durchführt – kann manchmal in Perfektionismus ausarten. Woran Sie Perfektionismus erkennen? Wenn die Verbesserungen ein aus Sicht des Unternehmens angemessenes Maß übersteigen, ohne dass ein wesentlicher Mehrwert erzielt wird.

Was Sie tun können:

• Prüfen Sie, ob die Arbeit den üblichen Teamstandards entsprach, als sie das erste Mal geliefert wurde. Ist dieser Mehraufwand auf das Feedback aus dem Review-Prozess zurückzuführen oder bietet er einen wesentlichen Nutzen gegenüber dem ursprünglichen Code? (Wenn ja, dann ist das toll! Wenn Mitarbeiter sich das Feedback aus dem Review-Prozess zu Herzen nehmen und ihren Code verbessern, sollte das auf jeden Fall honoriert werden.)
• Kommunizieren Sie klar und deutlich, was Sie unter „fertig“ verstehen. Zeigen Sie den Unterschied zwischen den ursprünglichen Anforderungen und der gelieferten Arbeit auf. Wenn ein Ingenieur seinen Code über einen längeren Zeitraum überarbeitet oder neu schreibt – oder viel zu lange für die Fertigstellung des Projekts braucht –, fragen Sie einen erfahreneren Ingenieur, was er im Rahmen dieses Projekts als „gut genug“ betrachten würde.
• Eine sehr hohe Churn-Rate vor dem Release könnte bedeuten, dass der Termin womöglich nicht eingehalten werden kann. Wird kurz vor einer Deadline übermäßig viel Code überarbeitet, sollte man den Release lieber nach hinten verschieben.

Ungewöhnlich hohe Churn-Raten sind häufig auf eine unklare Kommunikation mit Stakeholdern oder Unentschlossenheit zurückzuführen. Ein unentschlossener Stakeholder mag auf den ersten Blick kein großes Problem darstellen, doch tatsächlich kann er in einem Team großen Schaden anrichten – sowohl was die Stimmung als auch den Fortschritt anbelangt. Mit der Zeit kann sich großer Frust im ganzen Team aufbauen.

Möglicherweise kommt am Ende nicht das heraus, was eigentlich herauskommen sollte. Wenn ein solches Missverständnis dazu führt, dass Funktionen oder Komponenten fehlen, dann werden Sie wahrscheinlich eine deutliche Zunahme im Ordner „New Work“ bemerkt haben, nachdem die neuen Anforderungen hereinkamen. Wenn hingegen der Code aufgrund der unklaren Kommunikation überarbeitet werden muss, wird die Code-Churn-Rate stark ansteigen. So oder so, eine starke Zunahme der Aktivitäten im letzten Drittel eines Sprints (die nicht auf einen Code-Review zurückzuführen ist) deutet darauf hin, dass der Termin womöglich nicht eingehalten werden kann.

Wenn dieses Muster bei mehreren Sprints innerhalb desselben Teams beobachtet wird, sollte man sich mit den Teammitgliedern austauschen und prüfen, ob verspätete Anfragen der Auslöser sind.

Allgemein betrachtet sollte das Problem mit der Zeit, wenn Lösungen identifiziert, entwickelt und optimiert werden, kleiner werden. Ein plötzlicher Aktivitätsanstieg, besonders in den letzten Phasen eines Projekts, weist generell darauf hin, dass etwas Neues hinzugekommen ist.

Was Sie tun können:

Wenn ein Stakeholder nach Beginn des Entwicklungsprozesses mehrmals seine Meinung ändert, sollten Sie ihm ein paar Zahlen zeigen: Stellen Sie dar, wie viel Prozent der Software-Engineering-Aktivitäten für Überarbeitungen aufgewendet werden (idealerweise nennen Sie Zeit- und Geldangaben, um ihm die Auswirkungen dieser Praktik deutlich vor Augen zu führen).

Bei besonders schwierigen Problemen kann man davon ausgehen, dass mehr Zeit mit Ausprobieren und Backtracking verbracht wird. Entscheidend ist, dass man ein Gefühl dafür hat, wann ein Problem zu viel Zeit in Anspruch nimmt.

Vielleicht denkt ein Software-Ingenieur, ein Problem korrekt gelöst zu haben (und gibt das Projekt sogar zum Review frei), nur um festzustellen, dass große Teile neu geschrieben werden müssen – was dann natürlich eine ungewöhnlich hohe Churn-Rate verursacht. Es könnte auch sein, dass die Spezifikationen viel Interpretationsraum lassen oder der Ingenieur das Problem nicht gänzlich versteht oder keine Lösung weiß.

Was Sie tun können:

• Entwickeln Sie ein Gefühl dafür, wann ein Problem zu viel Zeit in Anspruch nimmt, und handeln Sie proaktiv.
• Meist ist es besser, von einem anderen Ingenieur oder der Teamleitung gecoacht zu werden als von einem Vorgesetzten. Fragen Sie einen erfahreneren Ingenieur (der gerne anderen hilft), ob eine Tandem-Programmierung für ihn in Ordnung wäre.
• Finden Sie einen Termin für ein Meeting, der für ihn passt und sich mit seiner Arbeit vereinbaren lässt. Erkundigen Sie sich, ob er über die nötigen Ressourcen verfügt und welche noch hilfreich wären.

Bei unklaren Anforderungen müssen sich Software-Ingenieure auf ihr Bauchgefühl verlassen, um mögliche Lücken zu füllen und zu interpretieren. Zwangsläufig werden einige Vermutungen falsch sein, was wiederum zu einer höheren Churn-Rate führt. Wenn die Spezifikationen schlecht geschrieben oder unvollständig sind, könnte es sogar sein, dass sich das Projekt gar nicht in die Praxis umsetzen lässt.

Was Sie tun können:

• Prüfen Sie die Anforderungen und ermitteln Sie, ob zusätzliche Erklärungen nötig sind und ob Grenzfälle angemessen besprochen wurden.
• Treffen Sie sich mit dem Produktteam und zeigen Sie ihm, was für Kosten unklare Anforderungen verursachen. Wenn Sie GitPrime nutzen, bringen Sie eine Grafik des Projektzeitplans mit, um zu verdeutlichen, wie der Software-Engineering-Durchsatz bei einer sauberen und einer chaotischen Implementierung aussieht.
• Erklären Sie dem Team anhand eines Beispiels, wie gute Anforderungen aussehen. Machen Sie den Teammitgliedern deutlich, dass klare Spezifikationen entscheidend sind – vor allem dann, wenn sie das Projekt schneller umsetzen möchten.

Zeigt sich bei einem Ingenieur über eine längere Zeitspanne eine hohe Churn-Rate bei geringem Durchsatz, könnte dies ein Zeichen von Burn-out oder nachlassender Motivation sein. Dies könnte auf das sogenannte „Bit-Twiddling“ zurückzuführen sein. Bei diesem Arbeitsstil konzentriert sich der Software-Ingenieur sehr lange auf einen einzigen Bereich der Codebasis und nimmt hier und da nur geringfügige Änderungen vor. Es ist, als wäre man beim Puzzeln an einem Punkt angelangt, wo alles gleich aussieht und man keinen Fortschritt mehr macht – das passiert häufig, wenn der Ingenieur das Problem oder den Kontext für eine Änderung nicht gänzlich versteht.

Halten Sie Ausschau nach einer hohen Churn-Rate in einem bestimmten Bereich des Codes. Manchmal sind Wiederholungen und Überarbeitungen darauf zurückzuführen, dass der verantwortliche Software-Ingenieur im Code-Review-Prozess mit der Zeit seine Arbeit schleifen lässt oder eine gewisse Gleichgültigkeit entwickelt. Das ist ein Hinweis dafür, dass er an Dynamik und Motivation verliert oder kurz davor ist.

Was Sie tun können

• Versuchen Sie, den Ingenieur mit einem neuen Projekt wieder zu motivieren und zu begeistern. Finden Sie ein Ticket (ein kleines passt auch), das den Ingenieur in neue und interessante Bereiche des Codes führt – auch wenn das bedeutet, dass die Produktivität des Teams auf kurze Sicht sinkt.

Wenn wir uns lediglich auf den Output unserer Teams konzentrieren (Nutzungskennzahlen, Fehlerraten, Produkte und Features, die bereits veröffentlicht und von Kunden genutzt werden), können wir nicht so gut nachvollziehen, wie unsere Teams arbeiten, um diesen Output zu erzielen – also den Prozess von der Idee bis zur Produktion.

GitPrime bietet eine ganze Suite an Berichten, die den Entwicklungsprozess von der anfänglichen Idee bis zur Produktion abdecken. So können Software-Engineering-Verantwortliche besser erkennen, wo es Engpässe gibt, ob Probleme von externen Stakeholdern ausgehen und ob Ingenieure sehr viel Zeit mit Aufgaben niedrigerer Priorität verbringen. Mit GitPrime lassen sich Entwicklungen erkennen, die ansonsten nicht aufgefallen wären oder Verzögerungen verursacht hätten, wie zum Beispiel ungewöhnlich hoher Code-Churn am Ende eines Sprints.

Durch Messung des Code-Churn und anderer Indikatoren können Sie Ihr Bauchgefühl auf konkrete Daten stützen.