Die drei Wege

Unsere Position. Wenn Entwicklung billiger wird, gewinnt Engineering-Disziplin an Wert, statt welchen zu verlieren. Wenn alle Code produzieren können, liegt der Vorteil bei den Teams, die den richtigen Code produzieren, in der richtigen Architektur und mit der richtigen Qualität (LinkedIn-Post (öffnet in einem neuen Tab)). Die drei Wege sind diese Disziplin. Billigerer Code beschleunigt eine Stufe der Arbeit. Der erste Weg dagegen bewertet die Leistung des ganzen Systems statt eines einzelnen Silos, und der zweite Weg verkürzt und verstärkt Feedback-Loops, damit sich laufend korrigieren lässt (The Three Ways: The Principles Underpinning DevOps (öffnet in einem neuen Tab)).

Jeder Weg zielt auf einen anderen Verlust in der Delivery: Arbeit, die an Übergaben wartet, Fehler, die weit wandern, bevor jemand sie bemerkt, und Teams, die aufhören, besser zu werden.

Was verlangt jeder der drei Wege?

The Phoenix Project fasst in drei grundlegenden Mustern zusammen, wie Arbeit durch eine Organisation fließt. Diese Muster gelten unabhängig von Tech-Stack, Teamgröße oder Jahrzehnt.

Der erste Weg: schneller Flow. Versteht, wie ihr einen schnellen Flow der Arbeit von der Entwicklung in den Betrieb schafft. Genau diese Strecke liegt zwischen dem Business und den Kund:innen. Jeder Bottleneck, jede Übergabe und jedes Freigabe-Gate erzeugt Reibung. Architekturentscheidungen beschleunigen diesen Flow oder bremsen ihn. Erzeugen eure Architekturgrenzen Deploy-Abhängigkeiten zwischen Teams, seid ihr am ersten Weg gescheitert.

Der zweite Weg: schnelles Feedback. Verkürzt und verstärkt Feedback-Schleifen. So behebt ihr Qualitätsprobleme an der Quelle und vermeidet Nacharbeit. Je weiter ein Fehler von seinem Ursprung wandert, bevor ihn jemand entdeckt, desto teurer wird er. Automatisierte Tests decken dabei nur einen Teil ab. Im Kern geht es um Informationsarchitektur: Die Folgen einer Entscheidung sollen so schnell wie möglich für die Menschen sichtbar werden, die sie getroffen haben.

Der dritte Weg: kontinuierliches Lernen. Schafft eine Kultur, die Experimente fördert und aus Fehlern lernt. Dazu gehört das Verständnis, dass Wiederholung und Übung die Voraussetzung für Können sind. Dieser Weg ist der schwerste. Er verlangt psychologische Sicherheit, Toleranz für kalkulierte Risiken und organisatorische Geduld. Menschen sollen mit der Zeit besser werden dürfen, statt beim ersten Versuch perfekt sein zu müssen.

Die drei Wege sind keine Checkliste. Sie sind eine Philosophie des Flows. Und sie funktionieren nur, wenn die Menschen, die sie umsetzen, die Prinzipien dahinter verinnerlicht haben. Dann brauchen sie keine Regel, die ihnen sagt, eine Feedback-Schleife zu verkürzen. Sie spüren den Schmerz einer langen Schleife und wissen, wie sie ihn beheben.

Verwandte Seiten

• Die Five Ideals: die täglichen Bedingungen, die die drei Wege Wirklichkeit werden lassen.
• Engineering-Philosophie: warum komplexe Systeme Prinzipien statt Regeln brauchen.
• Architekturprinzipien: wie Architekturgrenzen den ersten Weg beschleunigen oder blockieren.
• Agentic Continuous Delivery: schnelles Feedback, wenn Agenten den Code schreiben.
• Wo KI-Produktivität entsteht und verloren geht: wo der Flow stockt, sobald das Coden schneller wird.

Quellen

Artikel

• The Three Ways: The Principles Underpinning DevOps (öffnet in einem neuen Tab) - Artikel von IT Revolution, der schnellen Flow, schnelles Feedback und kontinuierliches Lernen darlegt, die drei Prinzipien, die diese Seite beschreibt.

Bücher

• The Phoenix Project (öffnet in einem neuen Tab) - der DevOps-Roman von IT Revolution, in dem die drei Wege zum ersten Mal auftauchen. Er erzählt von einem IT-Manager, der ein scheiterndes Projekt rettet.

Posts

• Ten-dollar development (öffnet in einem neuen Tab) - LinkedIn-Post mit der These, dass bei nahezu kostenloser Codegenerierung Architekturdisziplin und Context Engineering die bleibenden Unterscheidungsmerkmale sind, nicht die Fähigkeit zu coden.