Warum führten wir in jedem Sprint dieselbe Architekturdebatte? (Warum Fuehrten Wir In Jedem Sprint Dieselbe Architekturdebatte)

Warum führten wir in jedem Sprint dieselbe Architekturdebatte?

Ich arbeitete in Istanbul bei einem schnell wachsenden Technologie-Startup. In einer Mittagspause ging ich mit dem Senior Developer des Teams im Park spazieren. Er erzählte mir begeistert von der mobilen Anwendung, die bald veröffentlicht werden sollte, von neuen Modulen, die hinzugefügt würden, und von bevorstehenden Investorenpräsentationen.

Ich hörte zu und stellte eine einfache Frage: "Wo ist das Architekturdiagramm? Wo dokumentieren wir diese Entscheidungen?"

Er lächelte mich an. Es gab keinen Plan. Von einem "Software Architecture Handbook" ganz zu schweigen, es gab nicht einmal eine grobe Skizze auf einem Blatt Papier. Dass ein Manager abends den Kopf aufs Kissen legte und morgens mit einer neuen Idee aufwachte, definierte an diesem Tag unsere Architektur. Ein spontaner Fehler des Kunden konnte den gesamten Sprint in den Müll werfen. Das Projekt kam nicht voran, es trieb nur im Wind. (Als ich später hörte, dass sie in dieses Projekt über Nacht KI integriert hatten, nur weil es plötzlich populär war, war ich überhaupt nicht überrascht.)

Während dieses Spaziergangs im Park verstand ich, dass es nicht "schlechter Code" ist, der Softwareprojekte zerstört. Es ist die Verdampfung von Architekturwissen. Wir trafen eine Entscheidung, vergaßen, warum wir sie getroffen hatten, und diskutierten 3 Monate später erneut dieselbe Entscheidung. Das wurde die erste Front, der ich als technischer Leiter den Krieg erklärte.

Der Starrsinn traditioneller Unternehmen mit Tribal Knowledge

Nachdem ich dieses Chaos gesehen hatte, wurde meine erste Frage in jedem Bewerbungsgespräch: "Wie sieht Ihr Projektmanagementprozess aus und wie treffen Sie technische Entscheidungen?"

Ein paar Jahre später hatte ich ein Gespräch mit der F&E-Abteilung eines traditionellen Produktionsunternehmens. Der Manager mir gegenüber begann das Gespräch damit, meine Professionalität infrage zu stellen, weil ich keinen Anzug trug. (Dabei hatte ich für dieses Unternehmen zuvor bereits kritische Arbeiten von außen geliefert. Er wusste nicht einmal davon.)

Ich fragte, ob sie Jira, agile Prozesse und technische Dokumentation nutzten. Die Antwort war die schmerzhafte Wahrheit der Branche: "Wir haben das ausprobiert, das passt nicht zu uns. Wir schreiben einfach im Meeting in ein Notizbuch, wer was macht, und machen dann weiter."

Selbst wenn die Einstellung bestätigt worden wäre, hätte ich dieses Angebot in genau diesem Moment abgelehnt. Denn die Architektur und das Schicksal eines Projekts können nicht der verblassenden Tinte in einem Meeting-Notizbuch überlassen werden.

Decision Theater und operatives Chaos

Später stieg ich in ein großes Logistik-Transformationsprojekt ein. Als ich in das System kam, brauchte ich allein 1 Monat, um zu verstehen, wer was machte. Projektmanagement war null. Technisches Gedächtnis war null.

Ich krempelte sofort die Ärmel hoch. Ich brachte ein agiles Betriebsmodell hinein, setzte 2-wöchige Sprints auf, integrierte Jira und startete tägliche Stand-ups. Alles lief großartig. Aber es gibt eine Realität in der Privatwirtschaft: Wenn man Transparenz und institutionelles Gedächtnis in ein System bringt, fühlen sich diejenigen bedroht, deren Macht aus "Tribal Knowledge" stammt.

Das Mobbing begann. Sie versuchten, mir die Führung aus der Hand zu nehmen. Die ADR-Ausgaben (Architecture Decision Records), die ich damals erstellt hatte, wurden nicht einmal angeschaut. Einen Sprint später kam ein Manager und sagte: "Warum haben wir diese Datenbank so verändert? Niemand hat mir davon erzählt!" Alles war dokumentiert, aber sie lasen es nicht. Unsere Dokumentation hatte sich in ein Decision Documentation Theater verwandelt.

Genau da verstand ich: Es reicht nicht, nur ein Tool wie Jira oder ADR zu benutzen. Man muss dieses Tool direkt in den OKR-Blutkreislauf des Unternehmens injizieren.

Das System, das Projektchaos beendet: ADR

Heute betreiben wir dieses System in der Infrastruktur der globalen E-Commerce-Plattform, die ich als Lead Developer mit einem Team von 6 bis 7 Personen leite, sehr sauber. Als ich in das Projekt einstieg, herrschte wieder Chaos. In GitLab wurden Issues eröffnet, aber auf die Frage "Warum machen wir das?" gab es keine Antwort.

Ich brachte dem Team den agilen Geist bei und ordnete vor allem Michael Nygards ADR-Prinzipien direkt den Jahresquartalszielen wie Q1, Q2, Q3 und Q4 zu.

Was also ist ADR, und warum rettet es das Leben jedes Engineers? ADR ist ein unveränderlicher Datensatz, der nicht nur speichert, was eine Architekturentscheidung ist, sondern auch, warum sie getroffen wurde und welche Trade-offs akzeptiert wurden, direkt neben dem Code.

Heute halten wir jede Entscheidung mit einem einfachen, aber tödlich wirksamen Template fest:

Context: Welchem Problem stehen wir gegenüber? (Beispiel: Basket-Abfragen belasten die Datenbank.)

Decision: Was tun wir? (Beispiel: Wir verwenden Redis Cache.)

Neglected Alternatives: Was haben wir verworfen? (Beispiel: Datenbank-Scale-up wurde aus Kostengründen verworfen.)

Consequences / Trade-offs: Was akzeptieren wir? (Beispiel: Die Latenz sinkt, aber zusätzliche Cache-Invalidation-Komplexität entsteht.)

Ergebnis: Wir fragen nicht mehr "Warum?"

Heute sagt in Sprint-Meetings oder Management-Präsentationen niemand mehr: "Warum haben wir das so gemacht?" Denn unter jedem Ziel liegt ein klares ADR.

Wenn ein neuer Entwickler zum Onboarding ins Team kommt, verbringen wir nicht Tage damit, die Architektur zu erklären. Wir geben einfach die ADR-Logs weiter. Wir sagen: "Lies unsere Geschichte. Verstehe, welche Kriege wir geführt haben und warum wir diese Waffen gewählt haben."

Das Geheimnis, Chaos zu beenden, liegt nicht darin, fancy Code zu schreiben. Es liegt darin, das "Warum?" hinter diesem Code in ein institutionelles Erbe zu verwandeln. Jede nicht dokumentierte Architekturentscheidung ist hochverzinste technische Schuld, die du in Zukunft bezahlen musst. Bezahle sie heute, indem du deine Begründung festhältst, solange sie noch frisch ist.

An meine Software-Architect- und Tech-Lead-Kollegen: Verlieren sich Entscheidungen in euren Projekten in einer Wiki-Wüste, oder leben sie im Herzen des Codes?

Architecture Playbook Serie

#1: Warum führten wir in jedem Sprint dieselbe Architekturdebatte? (Sie lesen sie gerade)

#2: Die Engineering-Prinzipien, die ein Software Architect aus Erfahrung ableitet (Nächster Artikel)