Mike Bild
Blog

Developer Productivity: verkürzte Zyklen bei hoher Qualität

Kurze Feedbackschleifen bei verlässlicher Qualität sind mein Denkmodell für Developer Productivity. Wo tatsächlich gewartet wird, muss die eigene Durchlaufzeit zeigen.

≈ 9 Min. Lesezeit
SoftwareDelivery
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (13 Min.)

MP3 herunterladen

Durchlaufzeit und Bearbeitungszeit sind zwei verschiedene Größen. Bearbeitungszeit ist die Spanne, in der jemand tatsächlich an einer Änderung arbeitet – lesen, schreiben, testen. Durchlaufzeit ist die Spanne von der ersten Zeile bis zur Rückmeldung aus der Produktion. Die Differenz zwischen beiden ist Liegezeit: Stunden und Tage, in denen eine fertige Änderung existiert und nichts mit ihr passiert.

Nehmen wir einen Change mit zwei Stunden Bearbeitungszeit und drei Tagen in Warteschlangen: vor dem Build, vor der Review, vor einer freien Testumgebung. In diesem Beispiel setzt der Ruf nach mehr Leuten an der kleineren Größe an. Ob das im eigenen System genauso aussieht, lässt sich aus den Zeitstempeln von Commit, Review, Build und Deployment ablesen – nicht aus einer allgemeinen Behauptung über Entwicklerarbeit.

Mein Denkmodell dafür lautet: kurze Feedbackschleifen bei verlässlicher Qualität. Das ist keine messbare Formel, sondern eine Erinnerung an zwei Grenzen. Tempo ohne Qualitätsnetz erzeugt schnellere Fehler; Qualitätssicherung ohne zeitnahe Rückmeldung erzeugt große Warteschlangen. Welche Seite gerade bremst, zeigt die gemessene Zykluszeit.

Produktivität entsteht in zwei verbundenen Feedbackschleifen, deren Takt und Ergebnis nicht verwechselt werden dürfen.

Delivery-Schleife

  • Frage · Wie schnell erreicht eine kleine Änderung verlässlich Produktion?
  • Folge · Code, Build, Test, Review und Deploy
  • Zeitmaß · Minuten bis Stunden
  • Signal · technische Rückmeldung und Produktionsverhalten

Discovery-Schleife

  • Frage · Löst die Änderung das richtige Problem?
  • Folge · Hypothese, Umsetzung, Messung und Lernen
  • Zeitmaß · Tage bis Wochen
  • Signal · beobachtete Wirkung und validiertes Lernen

Eine schnelle Delivery-Schleife ohne Discovery liefert womöglich zügig das Falsche. Eine gute Hypothese ohne kurze Delivery-Schleife wartet zu lange auf belastbares Feedback.

Speed und Stability sind kein Trade-off

Der hartnäckigste Denkfehler in dieser Diskussion ist die Annahme, man müsse sich zwischen Tempo und Stabilität entscheiden. „Wir könnten schneller liefern, aber dann bricht mehr“ – diesen Satz höre ich in Steering-Runden regelmäßig. Die Daten sagen das Gegenteil.

Der Zentralbefund aus Accelerate (Forsgren, Humble, Kim, 2018), die Buchfassung der DORA-Forschung mit über 23.000 Antworten aus mehr als 2.000 Organisationen, ist eindeutig: High-Performer sind bei Geschwindigkeit und Qualität besser. Nirgends in den Daten erkauft sich ein Team das eine durch das andere. Die schnellen Teams sind auch die stabilen. Das ist ein statistischer Zusammenhang, keine Haltungsfrage – und das Fundament für die These, dass Zyklen und Qualität sich gegenseitig tragen.

Operationalisiert wird das über die vier DORA-Metriken, die genau diese zwei Dimensionen messen. Für den Durchsatz: Deployment Frequency und Lead Time for Changes – die Zeit von Commit bis Produktion. Für die Stabilität: Time to Restore Service (die Zeit bis zur Wiederherstellung nach einem Incident) und Change Failure Rate – der Anteil der Deployments, die einen Fehler verursachen. Die Lead Time ist dabei die messbar gemachte „kurze Feedbackschleife“ aus meiner Formel. Wer sie senkt, senkt genau die Wartezeit, um die es hier geht.

Ein Hinweis zur Präzision, weil das oft schlampig zitiert wird: Die State-of-DevOps-Reports haben Teams jahrelang in Cluster einsortiert – 2021 noch mit einer eigenen „Elite“-Gruppe. Der 2022er Report fand nur noch drei Cluster (High, Medium, Low), kein „Elite“ mehr. Wer heute mit „laut DORA sind Elite-Teams…“ argumentiert, sollte wissen, aus welchem Jahr die Zahl stammt.

Warum der Engpass das Warten ist

Continuous Integration wird oft als „Tooling“ verstanden – man richtet einen Build-Server ein, Haken dran. Der Sinn ist ein anderer. Martin Fowler definiert CI als Praxis, bei der Teammitglieder häufig integrieren und jede Integration durch einen automatisierten Build inklusive Tests verifiziert wird, um Integrationsfehler so früh wie möglich zu erkennen. Das entscheidende Wort ist „früh“. CI ist eine Latenz-Maschine: Sie verkürzt die Zeit zwischen einem Fehler und seiner Entdeckung. Der Engpass, den CI adressiert, ist Warte- und Integrationslatenz – nicht Code-Volumen.

Die Deployment-Pipeline (ebenfalls Fowler) ist der bewusste Umgang mit dieser Latenz. Man zerlegt den Weg zur Produktion in Stages: Frühe Stages geben in Sekunden bis Minuten eine erste Sicherheit, spätere sind gründlicher und dürfen dafür langsamer sein. Damit wird zur Gestaltungsentscheidung, wo Feedback schnell und wo es gründlich sein soll.

pipeline:
  - stage: commit          # target: < 10 min  -> fastest feedback
    steps: [compile, unit_tests, static_analysis]
  - stage: acceptance      # target: minutes   -> contract & integration
    steps: [contract_tests, integration_tests]
  - stage: deploy_staging  # ephemeral environment on demand
    steps: [provision_env, smoke_tests]
  - stage: production      # gated by feature_flag, not by branch age
    steps: [progressive_rollout, health_check]

Vor so einem Skelett trägt genau eine Frage: Wo geht die Zeit real verloren? Die Antwort ist selten unit_tests. Sie ist compile, wenn der Commit-Build zwölf Minuten braucht statt unter zehn. Sie ist review, wenn ein Pull Request zwei Tage in der Queue liegt. Sie ist provision_env, wenn eine Testumgebung von Hand beantragt und über Nacht bereitgestellt wird. Das sind die eigentlichen Latenzhebel. Das Schreiben der Tests, also die Zeit an der Tastatur, ist fast nie das Problem.

Das erklärt auch, warum „shift left“ mehr ist als ein Buzzword. Ein Vertragsbruch zwischen zwei Services, der erst in einer nächtlichen End-to-End-Umgebung auffällt, kostet einen Tag. Derselbe Bruch, der im Commit-Build auffällt, kostet Minuten. Es ist derselbe Fehler – nur die Feedbacklatenz unterscheidet sich um Größenordnungen.

Die zwei Schleifen

Kurze Zyklen gibt es auf zwei Ebenen, und ich sehe oft, dass Teams nur eine davon optimieren. Die innere Schleife ist die Delivery: code → commit → build → automated tests → review → deploy, gemessen in Minuten. Die äußere Schleife ist die Discovery: hypothesis → build → measure → learn, gemessen in Tagen bis Wochen. Die innere Schleife stellt sicher, dass Sie schnell und sicher etwas ausliefern. Die äußere stellt sicher, dass es das Richtige ist.

Diese äußere Schleife wird gern vergessen, dabei ist sie derselbe Gedanke auf der Produktebene. Eric Ries hat sie im Lean Startup (2011) als Build–Measure–Learn mit dem Ziel des validated learning beschrieben. Teresa Torres hat sie in Continuous Discovery Habits (2021) konkretisiert: wöchentliche Kundeninterviews, der Opportunity Solution Tree, der Chancen und Lösungsideen in eine sichtbare Ordnung bringt, systematisches Assumption Testing. Auch hier zählt nicht mehr Output, sondern kürzere Lernzyklen. Ein Team, das seine innere Schleife auf Minuten drückt, aber ein halbes Jahr wartet, bevor es merkt, dass das Feature niemand braucht, hat den falschen Engpass optimiert.

flowchart LR
  subgraph inner["Inner loop – Delivery (minutes)"]
    code["code"] --> commit["commit"]
    commit -->|"wait: build"| build["build"]
    build --> tests["automated tests"]
    tests -->|"wait: review"| review["review"]
    review -->|"wait: provision env"| deploy["deploy"]
  end
  subgraph outer["Outer loop – Discovery (days / weeks)"]
    hypothesis["hypothesis"] --> buildit["build"]
    buildit --> measure["measure"]
    measure --> learn["learn"]
    learn --> hypothesis
  end
  deploy --> measure
  learn -.-> code

Die beschrifteten Kanten in dieser Skizze sind bewusst die Wartekanten: build, review, provision env. An ihnen entscheidet sich die Zykluszeit. Die DORA-Lead-Time misst die innere Schleife, die Discovery-Kadenz die äußere. Beide zusammen ergeben die Zahl, die zählt: wie oft ein Team pro Woche etwas Validiertes lernt.

Qualität ist das Netz, nicht die Bremse

Jetzt der Teil, den man in der Tempo-Euphorie gern überspringt. Die Formel ist multiplikativ. Kurze Zyklen ohne Qualitätsnetz bedeuten nicht „schneller liefern“, sondern „schneller kaputtgehen“. Wer die Batch-Size reduziert und häufiger deployt, ohne automatisierte Tests, Contract-Tests und eine echte Deployment-Pipeline, senkt vor allem eines: die Zeit bis zum nächsten Incident. Batch-Size-Reduktion ohne Stabilitätsmechanismen verlagert den Engpass nur – vom Warten vor dem Deploy zum Aufräumen danach.

Deshalb gehört Qualität in dieselbe Pipeline wie das Tempo. Wo Services über Systemgrenzen hinweg miteinander sprechen, trägt Consumer-Driven Contract Testing einen großen Teil dieser Last. Die Idee (sie geht auf Ian Robinson und Fowler, 2006, zurück und ist mit Frameworks wie Pact breit etabliert): Der Konsument beschreibt, was er vom Provider erwartet, und diese Erwartung wird auf beiden Seiten unabhängig verifiziert – ohne eine gemeinsame, langsame End-to-End-Umgebung hochziehen zu müssen.

// consumer side: describe the expectation, generate a pact file
consumerTest("fetches a user by id", () => {
  provider
    .given("a user exists")
    .uponReceiving("a request for user 42")
    .withRequest({ method: "GET", path: "/users/42" })
    .willRespondWith({
      status: 200,
      body: { id: 42, name: like("Ada") }, // matcher, not a fixed value
    });
  // -> produces a pact contract, verified in the provider's own pipeline
});

Der Gewinn ist doppelt. Der Contract-Test läuft in der acceptance-Stage in Sekunden statt der End-to-End-Test in Minuten in einer eigens provisionierten Umgebung – die Feedbackschleife an der Service-Grenze wird kürzer. Und er ist präziser: Er sagt nicht nur „irgendwas ist rot“, sondern „der Provider liefert name nicht mehr“. Das ist Qualität, die Tempo ermöglicht, statt es zu bremsen.

Auf Architekturebene gehört derselbe Gedanke dazu. Michael Nygard hat in Release It! (2007, 2. Auflage 2018) die Stability Patterns beschrieben – Circuit Breaker, Bulkhead und Verwandte –, damit ein Fehler in einem Teil nicht das Ganze mitreißt. Und Neal Ford, Rebecca Parsons und Patrick Kua haben in Building Evolutionary Architecture (2017) die Idee der Fitness Functions eingeführt: automatisierte, ausführbare Prüfungen für Architektureigenschaften wie Latenz, Kopplung oder Sicherheit. Beides ist dieselbe Bewegung wie bei den Tests – Qualität wird zu etwas Ausführbarem gemacht, das in der Pipeline schnell Feedback gibt, statt in einem Review-Dokument zu verstauben.

Wie man kurze Zyklen konkret baut

Aus der Praxis ein paar Hebel, die zuverlässig wirken – geordnet nach dem, was die Wartekanten am direktesten trifft.

Der Commit-Build muss schnell sein. Fowlers Faustregel vom „ten-minute build“ ist keine Nostalgie, sondern eine psychologische Grenze: Dauert der Build länger, hört das Team auf, häufig zu integrieren, und die Batches wachsen wieder. Eine schnelle, breite Basis aus Unit-Tests und eine schmale Spitze aus langsamen End-to-End-Tests – die klassische Testpyramide – hält den Build schnell, ohne an Abdeckung zu verlieren.

Branches kurz halten. Trunk-Based Development mit kurzlebigen Feature-Branches und Feature Flags entkoppelt „Code ist gemerged“ von „Feature ist an“. Das ist der Punkt, an dem production durch ein Feature-Flag gated wird, nicht durch das Alter eines Branches. Lang lebende Branches sind der klassische Weg, wie sich Integrations-Wartezeit unsichtbar aufstaut, bis der Merge zum Tagesprojekt wird.

Umgebungen on demand. Wenn provision_env ein Ticket an ein anderes Team ist, ist Ihre Lead Time keine technische, sondern eine organisatorische Größe. Ephemere, per Skript erzeugte Umgebungen nehmen diese Kante aus der Warteschlange.

Und der Punkt, der am meisten Konflikt auslöst: Messen Sie das System, nicht die Person. Die vier DORA-Metriken sind Team- und System-Outcome-Metriken. Als individuelles Entwickler-Ranking missbraucht, erzeugen sie sofort Goodhart-Effekte – man optimiert die Zahl statt die Sache. Wer an „Deployments pro Entwickler“ gemessen wird, produziert Micro-Deploys; wer an der Change Failure Rate gemessen wird, deklariert Incidents um. Forsgren und Kollegen haben explizit vor solchen Vanity- und Individual-Metrics gewarnt. Die Metriken zeigen die Gesundheit eines Flusses, nicht die Leistung eines Einzelnen.

Fazit

Produktivität in der Softwareentwicklung ist nicht sinnvoll über geleistete Stunden allein beschrieben. In vielen Flüssen steckt ein großer Teil der Durchlaufzeit im Warten auf Build, Review oder Umgebung; ob das hier der Engpass ist, muss die Messung zeigen. DORA-Metriken beschreiben die Lieferfähigkeit des Systems. Contract-Tests, Stability Patterns und Fitness Functions können ausgewählte Qualitätsrisiken früher sichtbar machen, während die Discovery-Schleife prüft, ob das Team überhaupt am richtigen Problem arbeitet.

Wenn Sie morgen anfangen wollen: Zeichnen Sie Ihre innere Schleife auf und schreiben Sie an jede Kante die reale Wartezeit. Die längste davon ist ein guter Kandidat für die nächste Verbesserung. Danach messen Sie erneut. Kurze Zyklen und verlässliche Qualität bleiben dabei zwei getrennte Größen; keine darf die andere verdecken.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare