Architektur­entscheidung im agilen Team

Zusammen Architektur machen

Eine schlechte Architekturentscheidung kann Projekte zum Scheitern bringen. Das passiert oft, wenn ein Architekt alle wichtigen Entscheidungen alleine trifft und nie oder sehr spät Feedback bekommt, ob sie gut oder schlecht waren. Oder aber auch, wenn ein „agiles“ Team mit den Architekt(innen) die Architekturarbeit aus dem Fenster geworfen hat. Schade, denn wenn man wichtige Entscheidungen nicht einfach dem Lauf der Dinge oder einem Elfenbeinturmbewohner überlässt, findet man viel besser Lösungen.

Auch wenn viele bei Softwarearchitektur zuerst an schwergewichtige Prozesse und dicke Dokumente denken, sind Agilität und Softwarearchitektur sehr gut vereinbar. Architekturarbeit muss nicht schwergewichtig sein. Das Agile Manifest schreibt dazu: „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. [1]“. Das wirft die Frage auf: wie bekommt man ein Team dazu, sich selbst zu organisieren und eine gemeinsame Architektur zu entwickeln?

Zwischenmenschlich kann dabei einiges schief gehen: Teammitglieder(innen) mit großem Bedürfnis nach Harmonie erleben Streit. Teammitglieder(innen) mit Bedürfnis nach Struktur erleben Chaos. Gute Ideen werden nicht gehört, weil eine meinungsstarke Kollegin die Diskussion dominiert. Der Frust ist genauso schädlich wie unnötig. Mit etwas Übung klappt auch die Architekturarbeit im Team sehr gut.

Denn durch das gemeinsame, sachliche Abwägen von Architekturentscheidungen können Teams zu wesentlich besseren Ergebnissen kommen. Nur wer im Team entscheidet, kann blinde Punkte und fehlende Kenntnisse einzelner Teilnehmer(innen) durch das Wissen anderer Teilnehmer(innen) ausgleichen und es vermeiden, den kognitiven Verzerrungen auf den Leim zu gehen. Gerade bei Architekturentscheidungen, die per Definition besonders teuer zu revidieren sind, sollten wir diesen Mehraufwand investieren. Der folgende Artikel summiert meine Erfahrungswerte als Coach für Softwarearchitektur und zeigt, wie die Architekturentscheidung als Team funktionieren kann.

Legt fest, wer das Meeting moderiert

Kein anderer Faktor ist für den Erfolg eines Entscheidungsmeetings in meinen Augen so wichtig wie eine gute Moderation. Deshalb ist der erste Tipp: Legt am Anfang des Entscheidungsprozesses eine Person fest, die als Moderator(in) durch das Meeting führt und selbst nicht mitdiskutiert.

Moderator
Moderator

Die Rolle des/der Moderierenden ist es aber nicht etwa, Konflikte in der Diskussion gänzlich zu unterdrücken und durch rigide Strukturierung für „Ordnung“ zu sorgen. Vielmehr soll er/sie die Diskussion sachte zu einem Ziel führen. Dazu muss er/sie das Team auf die Problemlösung fokussieren, wenn das Team sich etwa im Streit um Kleinigkeiten verkeilt hat. Außerdem kann er/sie den Fluss der Ideen wieder in Schwung bringen, wenn betretenes Schweigen herrscht. Aber auch die Aktivierung von stillen Teilnehmer(inne)n, die sonst nicht zu Wort kommen, ist eine wichtige Aufgabe. Dazu muss ein sicherer Raum geschaffen werden, in dem es auch erlaubt ist, doof klingende Ideen mal auszusprechen.

Ein paar Dinge darf der/die Moderator(in) aber definitiv nicht zulassen: wenn Teilnehmer wild durcheinander sprechen oder von der sachlichen Diskussion in persönliche Angriffe abgleiten. In diesem Fall muss der/die Moderatorin auf ein geregeltes, respektvolles Miteinander pochen. Eine Doppelrolle als Diskussionsteilnehmer(in) und Moderator(in) würde ich vermeiden. Der Zielkonflikt zwischen der Moderation auf der einen und überzeugender Argumentation auf der anderen Seite kann eine Diskussion schnell aus der geführten Bahn werfen.

Führt ein strukturiertes Protokoll

Ein weiterer einfacher Mechanismus, den ich gerne verwende, ist das Führen eines strukturierten Protokolls über die Entscheidung. Die Struktur eines solchen Protokolls sieht am Ende des Meetings etwa wie in Listing 1 aus.

### Vorschlag 1

* Vorteile
    * Vorteil
    * Vorteil

* Nachteile
    * Nachteil (Gegenmaßnahme gegen diesen Nachteil)
    * Nachteil

### Vorschlag 2

* Vorteile
    * Vorteil
    * Vorteil

* Nachteile
    * Nachteil (Grund, waurm uns dieser Nachteil in unserem Kontext nicht relevant scheint)
    * Nachteil

### Entscheidung

Wir haben uns für Vorschlag 2 entschieden, weil ...

Das klingt erst mal unnötig bürokratisch, aber die Struktur des Protokolls hilft auf verschiedene Weise bei der Entscheidung. Wird das Protokoll während des Meetings gut für alle Teilnehmer sichtbar gepflegt, beispielsweise am Projektor oder per Bildschirmfreigabe, kann es als Strukturierungshilfe für die Diskussion eingesetzt werden. Beispielsweise können Teilnehmer auf bereits diskutierte Vorschläge referenzieren („Dieses Problem hätten wir aber bei Vorschlag 1 auch, können wir das ergänzen?“) oder sich beim Wechsel zwischen der Diskussion der verschiedenen Vorschlägen besser orientieren („Ich würde gerne nochmal zu dem Vorschlag 1 zurück kommen.“).

Ein paar einfache Diagramme nach dem Stil „Boxes and Lines“ können außerdem helfen, Missverständnisse zu vermeiden. Je abstrakter die diskutierte Lösung, desto wichtiger ist es, dass alle Teilnehmer(inn)en das gleiche Modell der vorgeschlagenen Lösung vor Augen zu haben.

Gerade bei technischen Diskussionen kommt es vor, dass wir Entwickler(innen) uns in Detaildiskussionen verlieren. Der Legende nach würden wir lieber ewig über die Fahrradhütte neben einem Atomkraftwerk streiten, als über das Design des Reaktors. Daher der Begriff des „Bikeshedding“ für Diskussionen, die sich endlos in unwichtigen Details verlieren. Die Struktur des Protokolls gibt den Moderierenden Kontext, die Diskussion wieder auf eine höhere Ebene zu heben und so die Lösung von Detailproblemen aufzuschieben („Mir scheint wir reden viel über den Nachteil von Vorschlag 2, haben wir noch andere Vorschläge die den vielleicht nicht haben?“).

Bikeshedding
Bikeshedding

In der vorgeschlagenen Protokollform ist die kritische Betrachtung verschiedener Vorschläge von beiden Seiten, mit all ihren Vor- und Nachteilen, gesetzt. Dadurch zwingen wir unser Hirn, in das logisch arbeitende „System 2“ (siehe Kasten 1) zu wechseln, statt auf die spontane, intuitive Lösung des „System 1“ zu hören, ohne deren negative Konsequenzen zu bedenken.

Kasten 1: Schnelles Denken, langsames Denken

Viele Teams stellen in der Diskussion fest, dass sie ihre intuitiven Präferenzen nicht richtig artikulieren können: („Ich weiß nicht, irgendwie fühlt sich diese Lösung falsch an!“). Entwurfsprinzipien wie DRY, SOLID, etc. können helfen diesen Gefühlen einen Namen zu geben. Ein(e) Moderator(in) kann dem Gefühl einen Namen geben und den Punkt als „Wir verletzen hier DRY“ in die Nachteil-Liste schreiben.

Ob die Verletzung eines Entwurfsprinzip im konkreten Fall wirklich ein Nachteil ist, muss aber dennoch abgewogen werden. Die Anwendung des DRY-Prinzips beispielsweise kann zu unerwünschter Kopplung führen. So passiert es nicht selten, dass eigentlich unabhängige Services durch Code-Sharing nach dem DRY-Prinzip zum Quasi-Deployment-Monolithen werden.

Haben wir alle Punkte gesammelt, die für oder gegen eine Lösung sprechen, bleibt die Frage, welche Lösung nehmen wir jetzt? Es kommt darauf an. Im Kasten 1 stehen einige Einflussfaktoren die bei dieser schwierigen Antwort helfen können.

Kasten 2: Die beste Entscheidung?

Nach erfolgreicher Entscheidung kann das entstandene Protokoll in Form eines „Lightweight Architecture Decision Records“ als Bestandteil der Architekturdokumentation abgeheftet werden. Eine schöne Sammlung dazu gibt es unter [2].

Trau dich zu moderieren

Wer merkt, wenn eine Diskussion abdriftet und in der Lage ist Fragen zu stellen, ist auch in der Lage ein Entscheidungsmeeting zu moderieren. Wenn sich das Team auf einem Holzweg befindet, braucht es oft nicht viel, um die Diskussion durch das Stellen von einfachen, zum Teil suggestiven Fragen wieder auf die Problemlösung zu fokussieren.

Moderation
Moderation

Eine kurze, unvollständige Liste der Fragen, die ich regelmäßig stelle, um Diskussionen in eine andere Richtung zu lenken, gibt es im Panel „Lenkende Fragen für Moderierende“. Auch wenn du selbst nicht mitdiskutierst, kannst du durch diese und weitere Fragen die Richtung der Diskussion lenken. Tappe aber nicht in die Falle, beim ersten Schweigen selbst mit einer Lösung vorzupreschen. Dadurch wird ein weiterer Beitrag der anderen Teammitgliedern unwahrscheinlicher. Durch geschicktes Fragen kann man aber eigene Vorschläge und Meinungen auch in die Diskussion bringen, ohne die Rolle als Moderator(in) zu brechen („Was würde denn passieren wenn wir… ?“).

Kasten 3: Lenkende Fragen for Moderierende

Gut genug ist manchmal besser als Perfekt

Manchmal kann es vorkommen, dass es für eine Frage keine objektive Antwort gibt. Oft ist mir das begegnet, wenn es sich um Geschmacksfragen und sehr kontroverse Themen handelt (z.B. Tabs oder Spaces). Hier finden wir nur sehr schwache oder gar keine Argumente. Ein Ausweg aus dem Dilemma kann es sein, den Entscheidungsprozess zu ändern und sich statt mit einem Konsens mit einem Konsent zufriedenzugeben.

Das Konzept „Konsent“ stammt aus der Organisationsform der Soziokratie und fordert, dass für die Entscheidungsfindung nicht relevant ist, dass alle von einer Lösung überzeugt sind (das wäre ein Konsens), sondern dass man sich auch für eine Variante entscheiden kann, die kein Teammitglied stark ablehnt.

Zuerst werden zu den Vorschlägen die Gründe besprochen, die zu einer starken Ablehnung bei den Teilnehmern führen. Dann wird versucht, durch diese Gründe durch Kompromisse oder andere Maßnahmen zu entkräften. Ein gerne verwendetes Zugeständnis ist es, den Vorschlag als ein zeitlich begrenztes Experiment einzuführen. „Wir probieren es jetzt mal einen Sprint lang mit Framework XYZ, und wenn euere Befürchtung wahr wird, dass es viel zu kompliziert ist, dann können wir nochmal über Alternativen diskutieren.“

Konsent
Konsent

Verlass ein Meeting nie ohne Entscheidung oder konkrete Action Items

Das Meeting nähert sich dem Ende zu, die Timebox ist fast vorbei. Was nun? Als Moderator(in), aber auch als Teilnehmer(in), ist es jetzt an der Zeit, aus dem Meeting ein verwendbares Resultat abzuleiten. Können wir schon eine Entscheidung treffen? Super, dann lass' uns die Entscheidung treffen und entsprechend dokumentieren.

Fallen euch keine Punkte ein, die für oder gegen eine Lösung sprechen, oder sind alle Punkte spekulativ, wird es gefährlich. Offenbar sind im Team nicht genug Informationen vorhanden, um eine rationale Entscheidung zu fällen. Es droht eine Paralyse durch Analyse. Wenn das Team so eine Situation erkannt hat, sollte die Entscheidung besser vertagt werden. Die notwendigen Infos können entweder durch Recherche, Fragen von Kollegen oder im Extremfall durch den Bau von Prototypen und Durchstichen selbst erarbeitet werden. Zur Ergebnissicherung können die beschlossenen nächsten Schritte in Form von Action Items gesammelt und einer zuständigen Person zugeordnet werden.

Ist die Diskussion aber noch heiß im Gange, wenn das Meeting sich dem Ende neigt, werden gerade diese abschließenden Schritte wie Action Items gerne vergessen. Sie sind aber essenziell, damit das Meeting einen wirklichen Fortschritt erzielt. Action Items verhindern nämlich, dass man bei erneuten Zusammenkünften wieder die gleichen Themen diskutiert und trotzdem nie zu einer Entscheidung kommt, weil beispielsweise eine Person gefragt werden muss, die am Meeting nicht teilnimmt, oder die benötigte Informationen nicht eingeholt wurden. Als Moderator(in) ist deshalb zehn Minuten vor Ende der Timebox ein guter Zeitpunkt das Gespräch in Richtung Ergebnissicherung zu lenken.

Literatur & Links

  1. https://agilemanifesto.org/iso/de/principles.html  ↩

  2. https://github.com/joelparkerhenderson/architecturedecisionrecord  ↩

Conclusion

“Ganz egal, wie es am Anfang aussieht. Am Ende ist es doch immer ein zwischenmenschliches Problem” war eine Devise des kürzlich verstorbenen Consulting-Gurus Jerry Weinberg. Eine Devise, die sich in meiner Erfahrung immer wieder bestätigt. Gerade bei der Entscheidungsfindung, der vermeintlich wichtigsten Aufgabe in der Architekturarbeit, tun sich Teams deshalb schwer. Viele der Probleme, die ich beobachte, wenn sich Teams sich an Softwarearchitektur versuchen, sind rein zwischenmenschlicher und nicht technischer Natur.

Ich hoffe, dass ich mit den Tipps in diesem Artikel einen kleinen Beitrag zur besseren Entscheidungskultur im Team geben konnte.

TAGS

Comments

Please accept our cookie agreement to see full comments functionality. Read more