Foto: Sensvector - shutterstock.com
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.
Deadline-Verderben
Unzureichende Tickets gepaart mit geschwindigkeitsbasierten KPIs fördern auch schlechte Gewohnheiten auf technologischer Seite. Ist die Deadline der alleinige Maßstab, haben die Entwickler keine andere Wahl, als Tickets abzuarbeiten - und Abstriche zu machen. Die können sich in schlampiger Kodierung manifestieren, was wiederum zu ausufernden technischen Schulden führt. Letztendlich erschwert die überstürzte Konfiguration des Produkts am Ende nur, neue Funktionen in der Zukunft hinzuzufügen - und der Teufelskreis schließt sich. Aber hey: Die Deadline steht.
Eine Umgebung, in der sich Softwareingenieure:
nonstop mit Zeitdruck konfrontiert sehen,
nicht in der Lage sind, ihre Arbeit richtig zu leisten und
von einer Metrik abhängig sind, die nicht (vollständig) in ihrem Einflussbereich liegt,
ist ein zuverlässiger Weg zu Burnout und Mitarbeiterfluktuation.
Im Interesse unserer Entwicklungsteams und Unternehmen können wir es uns weder aktuell noch in Zukunft leisten, unsere wertvollsten Mitarbeiter zu vergraulen - insbesondere dann nicht, wenn das Endprodukt darunter leidet. Auch Softwareentwicklung ist ein Prozess und eine Kunstform. In diesem Zusammenhang auf eine maschinenähnliche Kadenz zu beharren, verhindert kreatives Denken und iteratives Vorgehen - und somit die Chance, die bestmögliche Lösung zu schaffen. Es kommt manchmal eben vor, dass Ansätze nicht funktionieren - dann ist es nötig, einen anderen Weg auszutesten. Das führt manchmal zu besseren Lösungen, die Mehrwert schaffen, auch wenn das ein wenig länger dauert. Was es braucht, ist Spielraum.
Vielleicht noch wichtiger ist jedoch, dass Produkt- und Development-Teams sowohl während des Entwicklungsprozesses als auch in Retrospektiven enger zusammenarbeiten, um positive Ergebnisse und kontinuierliche Verbesserungen zu erzielen. Mehr Kommunikation im Vorfeld kann auf lange Sicht viel Zeit sparen, weil so beide Teams die Möglichkeit bekommen, den Übergang von den funktionalen Anforderungen zur kodierten Realität zu meistern.
Und vergessen wir nicht die Grundprinzipien des "Blameless" Postmortem: Ohne gemeinsame Verantwortlichkeit sind Unternehmen nicht in der Lage, ein differenziertes Verständnis darüber zu entwickeln, was während eines bestimmten Sprints schiefgelaufen ist. In einer Kultur ohne Schuldzuweisung arbeiten beide Teams zusammen, um die Gründe zu identifizieren und die volle Komplexität des Geschehens zu erfassen.
Speed ist als wesentliche Metrik für den Erfolg von Entwicklungsteams ungeeignet und erzeugen ein grundlegend falsches Bild davon, wie Produkte entwickelt werden sollten. Der wahre Maßstab für den Erfolg ist eine Kombination aus dem geschäftlichen Wert - wie er von den Produktverantwortlichen in Zusammenarbeit mit dem Entwicklungsteam definiert wurde - und der Umsetzung dieses Wertes durch die Entwickler. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.