Architektur gemeinsam gestalten bedeutet, weitreichende Softwareentscheidungen bewusst im Team zu treffen, statt sie einzelnen Architekten zu überlassen. Drei Experimente helfen dabei: ein langfristiger Produktblick als Orientierung, Double Pairs zum Vergleich zweier Lösungsalternativen im Code und Mob Programming zur gemeinsamen Umsetzung und Wissensweitergabe.
Das Wichtigste in Kürze
- Architekturentscheidungen sind schwer umkehrbar, weshalb eine breite Beteiligung aller Teammitglieder beim Treffen dieser Entscheidungen die Qualität der Lösung direkt verbessert.
- Double Pairs bedeutet: Zwei Zweier-Teams entwickeln parallel je einen Lösungsdurchstich, um Architekturalternativen anhand messbarer Kriterien vergleichbar zu machen, statt rein theoretisch zu diskutieren.
- Mob Programming überträgt Architekturwissen ins gesamte Team, weil alle Beteiligten den Code live sehen, Fragen stellen und Missverständnisse sofort klären, bevor sie sich im Produktionscode festsetzen.
- Architekten, die in Mob-Sessions mittippen statt nur im Review zu kommentieren, bekommen direktes Feedback, ob ihre Entwurfsentscheidungen im Code verständlich und umsetzbar sind.
- Neue Arbeitsweisen lassen sich leichter einführen, wenn man sie als zeitlich begrenzte Experimente kennzeichnet, weil der Label “Experiment” den Widerstand im Team messbar senkt.
Architekturentscheidungen sind teuer zu revidieren, deshalb lohnt sich die gemeinsame Basis
Eine Architekturentscheidung trägt ein besonderes Gewicht: Sie ist weitreichend und lässt sich später nicht einfach zurücknehmen. Genau das unterscheidet sie von einer beliebigen Codeänderung.
Wer im Test feststellt, dass Last und Performance nicht funktionieren, landet schnell beim selben Verdächtigen: der Architektur. Zu diesem Zeitpunkt ist eine Korrektur ein Kraftakt. Der Schmerzdruck muss erst groß genug sein, damit überhaupt jemand bereit ist, Geld für die nötige Änderung in die Hand zu nehmen.
Dazu kommt das Beweisproblem. Von außen lässt sich oft gar nicht sicher sagen, woran es liegt. Du müsstest erst belegen, dass die Investition tatsächlich Besserung bringt, bevor jemand sie freigibt.
Maximilian Aulinger und Melanie Brunnbauer setzen deshalb früher an. Ihre Überzeugung aus der Arbeit mit Softwareentwicklungsteams: Eine intensive Zusammenarbeit, bei der jeder gehört wird, auch die Introvertierten, liefert eine bessere technische und fachliche Lösung. Architekturentscheidungen brauchen eine möglichst breite Basis, bevor sie fallen.
Double Pairs: zwei Lösungen parallel bauen statt endlos diskutieren
Double Pairs ist ein Experiment für genau den Moment, in dem ein Team zwischen zwei Lösungsalternativen schwankt und beide Seiten plausible Hypothesen vortragen.
Statt weiter zu diskutieren, bauen zwei Pärchen parallel je einen Durchstich. Daher der Name: zwei Pairs, zwei Ansätze. Beide arbeiten auf messbare Kriterien hin, etwa harte Performance-Vorgaben, die für die Endnutzer-Qualität erreicht werden müssen.
Das Ergebnis ist etwas zum Anfassen. Zwei vergleichbare Durchstiche oder zumindest zwei Stände, die anhand der Kriterien einen Rückschluss erlauben, welcher Ansatz sich besser eignet.
Die Konstellation muss nicht starr sein. Zwei Pärchen sind der übliche Startpunkt, es können auch zweimal drei Personen sein. Eine enge Zusammenarbeit mit lebendigem Austausch funktioniert zu zweit meist besser als in größeren Gruppen, weil sie viel Vertrauen voraussetzt. Mehr als zwei Ansätze braucht es selten, weil der dritte oder vierte oft schon vorher in der Diskussion verworfen wurde.
Wann lohnt sich der doppelte Aufwand?
Double Pairs kostet doppelte Entwicklungszeit, deshalb sollte das Team vorher klären, wann es das Experiment abbricht. Es gibt zwei Wege dafür.
Mit einem belastbaren, messbaren Kriterium entwickelst du so lange, bis du testen kannst, und brichst dann ab. Ohne hartes Kriterium hilft eine Timebox: einen Tag investieren, A gegen B laufen lassen und am nächsten Morgen prüfen, wie weit beide Ansätze gekommen sind.
Es muss auch nicht immer um zwei vollständig neue Lösungen gehen. Eine sinnvolle Variante: Ein Team kennt den einen Ansatz gut, der andere ist technologisch unbekannt. Dann baut es nur den unbekannten durchstichartig an, um zu spüren, wie er sich anfühlt, und stellt ihn dem bekannten gegenüber.
Pauschale Kriterien gibt es nicht. Was hilft, ist der Schritt zurück zur Frage, was die Lösung erreichen soll. Wer als Organisation oder Produktverantwortlicher klar beantwortet, wozu eine Erweiterung dient, kann von dort aus messbare Kriterien ableiten.
Architekturentscheidungen verstecken sich oft im Code
Viele Architekturentscheidungen werden gar nicht bewusst getroffen, sondern beim Coden manifestiert. Das macht sie schwer greifbar und im Nachhinein teuer.
Typische Fragen, die sich erst hands-on im Code zeigen, betreffen die Anbindung externer APIs: blockierend oder nicht blockierend, synchron oder asynchron, und wie sich das an der Oberfläche anfühlt. Auch Querschnittsfunktionen wie die Einbindung eines Loggings lassen sich auf diese Weise vergleichen, weil das Ergebnis anfassbar ist und die Frage beantwortet, ob ein Produktionsbetrieb damit tragbar wäre.
Ein konkretes Beispiel: Ein Team sollte in einem laufenden Geschäftsprozess eine digitale Unterschrift ermöglichen. Der Prozess selbst lag bei einem anderen Team, zuständig war man nur für die Unterschriftenkomponente. Es gab zwei Varianten. Den Kunden auf eine eigene Seite hinausleiten oder eine integrierte, wiederverwendbare Web-Komponente bauen.
Die zweite Variante war neu und mit Unsicherheit behaftet: Funktioniert die Einbindung? Wie hoch ist der Aufwand? Erfüllt sie das Versprechen der Wiederverwendbarkeit? Das Team nahm sich anderthalb bis zwei Tage, um das als Mock zu verproben, statt es vorab durchzudiskutieren.
Eine Entscheidung braucht eine bewusste Entscheidungsregel, sonst entsteht ein Grabenkampf
Wenn sich zum Stichtag keine Lösung klar besser anfühlt, braucht das Team eine vorher vereinbarte Regel, wie es entscheidet. Sonst bleibt eine halbgare Lösung stehen, bei der ein Teil des Teams nicht mitzieht.
Ein begleitetes Team hat das als sportlichen Wettbewerb gelebt: Sind beide Ansätze gleichauf, gewinnt das Pair mit dem schnelleren belastbaren Ergebnis. Das spart weiteres Nachdenken, setzt aber Vertrauen voraus und Menschen, die im Zweifel zurückstecken.
Ein voller Konsens muss nicht das Ziel sein. Ein “ist gut genug für uns” ist oft das hilfreichere Mittel. Wichtig ist nur, die Entscheidung bewusst zu treffen, ob per Münzwurf, Best of Five oder klarer Verständigung. Sonst entsteht ein latenter Grabenkampf, weil sich übergangene Teammitglieder nicht ernst genommen fühlen.
Liegen die Kriterien sehr nah beieinander, ist das auch eine Erkenntnis. Dann kann es richtig sein, das Experiment gar nicht erst zu starten, weil der doppelte Invest sich nicht lohnt.
Vorher: ein klares Wozu über den nächsten Sprint hinaus
Bevor zwei Lösungen gebaut werden, hilft ein klares Ziel. Teams, die iterativ arbeiten, planen meist nur die nächsten Sprints und verlieren den mittelfristigen Blick.
Der Alltag steckt häufig in der operativen Grasnarbe: was morgen kommt, was in zwei Wochen, was in vier. Darüber hinaus oft nur ein Leben von der Hand in den Mund.
Das Gegenmittel ist eine kurze, regelmäßige Runde mit fester Timebox. Eine Stunde reicht, um den Schritt zurückzugehen und zu fragen, wo das Softwareprodukt in einem halben Jahr stehen soll. Bewusst nicht bis ins letzte Detail, sondern als Überblick, der den Blickwinkel für die anstehenden Entscheidungen herstellt.
Nachher: Mob Programming bringt die Entscheidung in die Köpfe
Jede Architekturentscheidung ist nur so gut wie ihre Umsetzung. Wird sie im Code nicht zum Leben erweckt, ist sie hinfällig. Und die Umsetzung ist meist so gut wie das Verständnis derjenigen, die den Code schreiben.
Genau hier setzt Mob Programming an. Wenn zwei Personen über Double Pairs einen Durchstich erarbeitet haben, kennen die anderen beiden die Umsetzung noch nicht. Der nötige Wissenstransfer gelingt im Mob, weil alle gemeinsam am selben Code arbeiten.
Remote hat dabei einen praktischen Vorteil gegenüber dem klassischen Raum mit einem Bildschirm. Jeder sitzt vor dem eigenen Rechner und sieht direkt, was passiert. Der Driver übernimmt das Tippen und kommentiert möglichst wenig, das Erklären übernehmen die anderen. So entsteht ein lebendiger Austausch, von “da fehlt ein Strichpunkt” bis “so war die Struktur eigentlich nicht gedacht”.
Wichtig ist der regelmäßige Wechsel, etwa alle zehn Minuten, damit jeder am Ball bleibt. Beim Implementieren tauchen die Fragen auf, die man sich beim Coden sonst allein stellt. Im Mob sitzen Menschen daneben, die Antworten haben, manchmal ein Snippet in den Chat werfen, und das Team kommt schneller voran als über nachgelagerte Reviews.
Die Umsetzungen sind meistens so gut wie das Verständnis der Leute, die den Code schreiben. Deshalb kommt es darauf an, eine Architekturentscheidung klar zu kommunizieren und zu zeigen, wie das in der Realität aussieht. — Melanie Brunnbauer
Architekturwissen gehört ins Team, nicht in einzelne Köpfe
In vielen Unternehmen sitzt das Architekturwissen bei zwei, drei Personen, die seit Jahren da sind und in Einzel-Reviews ihr “so geht das nicht” verteilen. Dabei bleibt keine Lernerfahrung, und das Wissen bleibt bei diesen Architekten hängen.
Der wirkungsvollste Hebel: solche Personen einmal mit in den Mob nehmen, wenn sie bereit sind, mitzucoden. Sie denken mit, stellen Fragen, geben Impulse und tippen auch mal selbst. Statt nur “so nicht” liefern sie ein “so ist es gedacht”, das zum Anfassen ist.
Der Effekt geht in beide Richtungen. Der Architekt merkt, ob sein High-Level-Konzept verständlich ist, ob er seine Kommunikation ändern muss, im Extremfall sogar, dass das Konzept nicht zum Problem passt. Diese letzte Erkenntnis kommt im Mob teuer, sollte aber besser etwas früher fallen.
Wie binden Teams Tester in diese Experimente ein?
Tester sind in diesen Formaten keine nachgelagerte Instanz, sondern oft die beste Quelle für die messbaren Kriterien, nach denen eine Lösung besser oder schlechter ist. Genau deshalb gehören sie früh dazu, schon im Refinement, wo sie sagen, worauf sie später schauen würden.
Es gibt auch Mob-Testing-Sessions. Das Team trifft sich in ähnlicher Konstellation und legt einen Fokus fest: Sind alle Masken konsistent? Oder versuchen wir heute mal, die Anwendung möglichst kaputt zu machen?
Vorab lohnt eine Klärung, die häufig fehlt: Was soll das Testen erreichen? Schnelles Feedback für die Entwicklung und ein TÜV in einem regulierten Umfeld sind zwei sehr unterschiedliche Ziele. Diese Frage offen auf den Tisch zu legen, bringt das Team weiter. In einer Mob-Session sind Menschen mit starkem Blick auf Qualitätskriterien zudem sehr gute Navigatoren.
Wie startest du ein erstes Experiment, auch ohne Mandat?
Du brauchst weder die Zustimmung des Projektleiters noch des Coaches, um anzufangen. Such dir eine Mitstreiterin oder einen Kollegen, der aufgeschlossen ist, und probiert eine Sache im kleinen Rahmen aus, zu zweit oder zu dritt.
Wer agil arbeitet, hat mit der Retrospektive einen natürlichen Ort, um das Ergebnis sichtbar zu machen. “Im letzten Sprint haben wir das ausprobiert, das fanden wir gut” stößt eine Veränderung von unten an, ohne dass du sie von oben durchsetzen musst.
Die Sprechweise macht den Unterschied. “Wir machen das jetzt so” erzeugt Widerstand. “Lasst uns das als Experiment ausprobieren und in 90 Minuten oder zwei Wochen bewerten, ob es uns geholfen hat” senkt die Hürde deutlich. Ein klar gekennzeichnetes Experiment verpflichtet zu nichts.
Vorleben schlägt Überzeugen. Wenn zwei Leute eine Methode einfach machen und ein Dritter daneben steht und merkt, dass es funktioniert, hat das einen ganz anderen Zug als jede theoretische Diskussion.
Zusammenarbeit ist gestaltbar, genau wie die Software
Die eigentliche Quintessenz dieser Experimente: Nicht nur die Software ist gestaltbar, sondern auch die Zusammenarbeit im Team. Beides lässt sich bewusst formen.
Es gibt kein Patentrezept. Was für ein Team funktioniert, klappt beim nächsten nicht, dafür wirkt dort etwas anderes. Unterschiedliche Anforderungen erfordern unterschiedliche Formen der Zusammenarbeit, um gute Lösungen zu provozieren.
Dazu gehört, Unterschiedlichkeit positiv zu sehen statt als Störung. Der Tester, der quälende Fragen stellt, ist kein Bremser. In der richtigen Ecke ist genau er derjenige, den du dazu holst. Gerade nach Phasen der Remote-Vereinzelung lohnt es sich, die Stärken der Einzelnen im gemeinsamen Tun erst wieder kennenzulernen.
