Innerhalb der Continuous-Delivery-Welt sind Releases in hoher Frequenz zum Usus geworden. Die meisten Unternehmen aktualisieren ihre Produkte inzwischen auf täglicher Basis - die Cloud und Automatisierung machen es möglich.

Doch der Fokus auf Geschwindigkeit in der Softwareentwicklung ist nicht von Vorteil. Im Gegenteil - er greift wesentlich zu kurz und kann dazu führen, dass Dinge, die außerhalb des engen Speed-Blickfelds liegen, unter den Tisch fallen.

Schatten-Development

Mit dem Aufkommen von Scrum ist die Geschwindigkeit von Story Points zum wichtigsten Faktor in agilen Softwareentwicklungszyklen geworden. Geschwindigkeit wird als Synonym für Erfolg angesehen, "Acceleration" ein Aushängeschild für jedes erfolgreiche Unternehmen im Bereich der Softwareentwicklung. Anders ausgedrückt: Liefern Sie einfach mehr Story Points und Sie haben es geschafft.

Dieser Impuls entbehrt nicht einer gewissen Logik: Aus C-Level-Perspektive ist ein perfektes Produkt, das nicht rechtzeitig auf den Markt kommt, wertlos. Dass es sich tatsächlich auszahlen kann, "Erster" zu sein, zeigt auch eine aktuelle Untersuchung von Green Hills Software. Demnach kann eine Verkürzung der Time-to-Market den Return on Investment um knapp 13 Prozent in die Höhe treiben.

Nichtsdestotrotz bin ich davon überzeugt, dass ein übermäßiger Fokus auf die Entwicklungsgeschwindigkeit mehrere wichtige Faktoren außer Acht lässt, die entscheidend sind, um Softwarelösungen tatsächlich zu optimieren. Denken Sie dabei an all die Fragen, die nicht gestellt werden, wenn es nur um Development-Speed geht:

• Sind die Produktspezifikationen gut ausgearbeitet und darauf abgestimmt, wie das Team das Produkt ausliefern will?

• Adressiert die Lösung das angestrebte Geschäftsproblem?

• Ist der Programmcode qualitativ gut genug, um spätere, zeitraubende Nacharbeiten überflüssig zu machen?

• Entsteht der Code im Rahmen von Test-driven Development, damit Refactoring einfach bleibt und Anforderungen dokumentiert sind?

• Inwiefern werden bei der nächsten Iteration technische Reibungsverluste auftreten?

• Ist das System am Ende sicher, stabil und skalierbar - und darüber hinaus auch leicht zu erweitern?

Natürlich streben wir alle danach, ansprechende Qualität in vertretbarer Geschwindigkeit zu liefern. Aber ein alleiniger Fokus darauf, fördert leider nur schlechte Angewohnheiten bei allen Beteiligten.

Dazu kommt noch, dass oft nicht dieselben Metriken auf alle Phasen des Entwicklungslebenszyklus angewendet werden: Weder werden Produktteams auf der Grundlage ihrer Geschwindigkeit bewertet, noch werden die verschiedenen Teile der Produkt-Pipeline für technische Verzögerungen verantwortlich gemacht.

Speed-Tunnelblick

Fairerweise muss man aber auch zugeben, dass es diffizil ist, die Geschwindigkeit von Produktspezifikationen zu messen. Allgemein wird impliziert, dass Produktentwicklung ein Prozess oder gar eine Kunst ist, die erfordert, zu experimentierten und schrittweise vorzugehen. In meinen Augen trifft dasselbe auf die Softwareentwicklung zu.

Es wäre absurd, die Performance eines Produktteams darauf zu reduzieren, wie schnell Tickets an die Entwickler ausgegeben werden. Inmitten seiner Iterationen beginnt das Produktteam aber irgendwann damit, Tickets zu erstellen - ohne eine echte Messgröße dafür, ob die Tickets in einer Form vorliegen, die es ermöglicht, dass sie ordnungsgemäß bearbeitet werden können. Dabei findet auch keine Bewertung darüber statt, ob die gestellten Tasks realistischerweise in der verfügbaren Zeit erledigt werden können und es besteht keine Pflicht für Backup-Pläne, falls dabei Probleme oder Verzögerungen auftreten. Die Engineers bearbeiten die Tickets, erstellen und verteilen Code. Um die Produktivität zu bewerten, wird gemessen, wie schnell sie diese Maßnahmen umsetzen.

Dabei kann es dazu kommen, dass von Produktteams (unabsichtlich) potenzielle Konflikte übersehen oder wichtige Anforderungen vernachlässigt werden. Fällt so etwas auf, arbeiten die Entwickler allerdings schon auf eine Deadline hin - und müssen Gas geben, weil sie anhand ihres Speeds beurteilt werden. Weil die Entwicklungsgeschwindigkeit der KPI ist, beeinträchtigt die Zeit, die dafür aufgewendet wird, Tickets zu bearbeiten, letztendlich die Gesamtleistung des Teams. In Einzelfällen sind zwanzig verschwendete Minuten vielleicht noch kein Weltuntergang. Wenn sich dieses Problem allerdings über mehrere Iterationen hinweg wiederholt, wird das Projekt am Ende zum Rennen gegen die Zeit - während die Produktschulden steigen.