Das Wichtigste in Kürze
- Architektur ist kein starres Korsett, sondern ein Ermöglicher (Enabler) für schnelles, sicheres Entwickeln und einfache Änderungen.
- Der Schlüssel liegt darin, Entscheidungen bewusst und so spät wie möglich zu treffen, um Optionen offen zu halten und unnötige Komplexität zu vermeiden.
- Nicht-funktionale Anforderungen wie Wartbarkeit oder Performance müssen im Product Backlog explizit gemacht und priorisiert werden – sonst werden sie vernachlässigt.
- Die Teamstruktur (Conway's Law) bestimmt maßgeblich die Systemarchitektur. Willst du eine andere Architektur, musst du die Teamzusammenarbeit überdenken.
- Ziel ist eine Architektur, in der Teams "richtig gut leben können" – sie reduziert Frust und befähigt zu eigenverantwortlichem Handeln.
Worum es geht
Versteht mich nicht falsch: Architektur ist wichtig. Das Problem ist nur, dass sie in vielen agilen Kontexten als langfristiger, starrer Plan gesehen wird – als Gegensatz zur gewünschten Flexibilität und Anpassungsfähigkeit. Was ich konsistent beobachte, ist, dass diese Sichtweise zu frustrierten Teams und schlechten, nicht "lebendigen" Systemen führt.
Gemeinsam mit dem erfahrenen Architekten und Coach Matthias Bohlen gehen wir der Frage nach: Wie muss Architektur gedacht und gemacht werden, damit sie Scrum und agile Teams nicht behindert, sondern aktiv befähigt? Wir schauen uns an, wie Entscheidungen getroffen werden, welche Rolle nicht-funktionale Anforderungen spielen und wie die Teamstruktur die Architektur prägt.
Für wen?
Für wen?
Diese Episode spricht alle an, die an der Schnittstelle zwischen fachlichen Anforderungen und technischer Umsetzung arbeiten und spüren, dass Architektur oft als Bremsklotz empfunden wird.
Besonders wertvoll, wenn du:
- Als Scrum Master oder Agile Coach erlebst, dass Architekturthemen die Teamdynamik lähmen und suchst, wie du bewusste Entscheidungsprozesse fördern kannst.
- Als Product Owner oder Product Manager unsicher bist, wie du nicht-funktionale Anforderungen priorisierst und im Backlog gegenüber Stakeholdern vertrittst.
- Als (Tech) Lead oder Entwickler frustriert bist von einer Architektur, die Veränderung schwer macht, und nach Prinzipien für eine bessere, "lebendigere" Alternative suchst.
Episoden-Insights
Architektur als Enabler, nicht als Constraint
Eine gute, lebendige Softwarearchitektur ist kein Hindernis, sondern die Grundlage für agiles Arbeiten. Sie ermöglicht Teams, schnell mit der Entwicklung zu starten, Änderungen lokal in einem Modul zu begrenzen (statt das ganze System zu betreffen) und sicher zu experimentieren. Es geht darum, ein Ökosystem zu schaffen, in dem Entwicklung nachhaltig Freude macht und Wert liefert.
"Baut euch Architekturen, in denen ihr nachher richtig gut leben könnt."
Bewusste und späte Entscheidungen
Architektur bedeutet nicht, alles von Anfang an festzulegen. Im Gegenteil: Eine kluge architektonische Haltung zeichnet sich dadurch aus, Entscheidungen bewusst zu treffen und sie so spät wie möglich zu fällen. Die erste Frage sollte immer sein: "Müssen wir diese Entscheidung überhaupt jetzt treffen?" Dadurch bleiben Optionen länger offen und man vermeidet vorzeitige, oft unnötige Komplexität.
"Eine gute Architekturentscheidung ist erstmal die Frage, müssen wir sie überhaupt treffen."
Nicht-funktionale Anforderungen im Backlog verankern
Qualitätsmerkmale wie Performance, Wartbarkeit, Sicherheit oder Skalierbarkeit (auch nicht-funktionale Anforderungen oder NFRs) werden im agilen Alltag oft stiefmütterlich behandelt. Sie müssen jedoch explizit im Product Backlog auftauchen und priorisiert werden, sonst finden sie nie statt. Tools wie die ISO 25010 können helfen, diese Qualitätskriterien sichtbar und diskutierbar zu machen.
"Sagt doch mal was zu Performance, sagt doch mal was zu Wartbarkeit, sagt doch mal was zu Übertragbarkeit in andere Umgebungen."
Dein nächster Schritt
Die Prinzipien einer enabling Architektur in deinen Kontext zu übertragen, kann herausfordernd sein. Lass uns gemeinsam abgleichen, wo bei euch die größten Hebel sind.
Strategiegespräch: Architektur & Agilität
In einem unverbindlichen 30-minütigen Call analysieren wir, wie Architektur in eurem Umfeld zum Enabler werden kann – und wo die größten Hindernisse liegen.
Gespräch vereinbaren →Ressourcen
Erwähnt in der Folge
Software Engineering Institute (SEI) / ISA-Coupé Kurse(resource)
Der Gast verweist auf die SEI-Website und deren Kurse als Quelle für über 120 Definitionen von Softwarearchitektur.
Akt 42 (vermutlich 'Arc42')(book/author)
Der Gast erwähnt 'Akt 42' (wahrscheinlich das Architektur-Template 'arc42') im Zusammenhang mit der Kontextsicht bei der Architekturbeschreibung.
Weitere Ressourcen aus dem Netz
Externe Links zu weiterführenden Inhalten, die im Kontext dieser Episode hilfreich sein können.
Live zu diesem Thema
Vertiefe dieses Podcast-Thema in unseren Live-Webinaren und Trainings:
Die besten Tipps zu Scrum und Agilität
- Wo macht eine agile Arbeitsweise Sinn? Wo nicht?
- Was zeichnet Scrum im Kern aus?
- Wie gestalte ich Scrum effektiv aus?
- Wie arbeite ich in meiner Organisation agil?
Weiterführende Themen & Ressourcen
4: Scrum - Ein minimales Rahmenwerk
Scrum wird oft als zu komplex missverstanden. Dabei ist es bewusst minimal. Die wahre Herausforderung liegt in der kontextspezifischen Anwendung und dem eigenen Lernen.
83: Agile in der HR-Abteilung
HR wird oft als langsam und schwerfällig wahrgenommen. Erfahre, wie agile Methoden wie Scrum und Kanban HR-Teams effektiver, kundenorientierter und zum echten Team machen.
14: Definition of Done Nachlese - Interview mit Marc Bless
Teams liefern inkonsistente Qualität? Erfahre, warum eine klare Definition of Done entscheidend ist und wie du sie mit deinem Team entwickelst – inklusive praktischer Tipps.