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.”. 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.
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?”).
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.
Daniel Kahneman ist durch seine Arbeit zu Urteilsheuristiken und kognitiven Verzerrungen bekannt geworden. In seinem Buch “Schnelles Denken, langsames Denken” beschreibt er ein Modell wie wir Entscheidungen fällen als eine Kombination aus zwei Systemen. System 1 ist dadurch geprägt, dass es heuristisch arbeitet. Es ist schnell, automatisch, immer aktiv, emotional, stereotypisierend und unbewusst. Viele intuitiv getroffenen Entscheidungen sind deshalb dem System 1 zu verdanken und werden emotional verteidigt. System 2 hingegen ist langsam, anstrengend, selten aktiv, logisch, berechnend und bewusst. Kognitive Verzerrungen und objektiv nicht nachvollziehbare Fehlentscheidungen entstehen vor Allem, wenn System 1 alle Entscheidungen trifft.
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.
In der Softwareentwicklung gibt es nur selten eindeutig optimale Lösungen. Widersprüchliche Qualitätsanforderungen zwingen uns zum Trade-off zwischen Vor- und Nachteilen verschiedener Lösungsvarianten. So kann es sein, dass wir einen Performanceverlust in Kauf nehmen, um ein Sicherheits-Feature zu implementieren oder mit Eventual Consistency leben müssen, um Anforderungen an Skalierbarkeit zu erreichen.
Kennen wir die Qualitätsanforderungen unserer Stakeholder, können wir abwägen, welche Eigenschaft in diesem Fall die wichtigere ist. Diese Qualitätsanforderungen können wir beispielsweise durch einen ATAM-Workshop erheben, der uns eine Liste von priorisierten Qualitätsszenarien liefert.
Eine gute Lösung ist eine solche, bei der wir möglichst viele von den hoch priorisierten, positiven Qualitätseigenschaften und wenige von den negativen Eigenschaften bekommen. Eine Antwort auf dieses schwierige, multi-dimensionale Optimierungsproblem ist das Pareto-optimum. Eine pareto-optimale Entscheidung liegt vor, wenn man kein Qualitätsattribut verbessern kann, ohne dass sich ein anderes dadurch verschlechtert.
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 hier.
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.
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… ?”).
Wenn die Diskussion feststeckt
- Wir haben jetzt viel über Variante A gesprochen, aber wenig über Variante B. Warum reden wir nicht mal darüber?
- Fehlen uns Informationen über die Technik von Variante B? Sollen wir vertagen und uns nochmal zusammensetzen, wenn wir die Fragen geklärt haben?
- Ich glaube, wir haben genug Nachteile für Variante A, aber keine Vorteile, gibt es da gar keine?
- Ich habe das Gefühl, wir haben kommen nicht voran. Lasst uns nochmal überlegen ob wir noch weitere Varianten finden, die noch nicht im Protokoll stehen.
- Puh. Mir schwirrt gerade der Kopf. Lasst uns mal fünf Minuten Pause machen.
Wenn Diskussionen zu wenig Varianten produzieren
- Was wäre denn die einfachste Lösung, die möglicherweise funktionieren könnte?
- Was, wenn wir zwei der Ansätze kombinieren?
- Haben wir genug Informationen, um diese Entscheidung zu treffen, oder sollten wir erst mehr recherchieren und uns dann nochmal treffen, um zu entscheiden?
- Kennen wir jemanden, der das schonmal gemacht hat, den wir vielleicht fragen könnten?
Wenn eine Entscheidung nicht einfach fällt
- Können wir Möglichkeiten finden, um die Nachteile einer Lösung so abzuschwächen, dass wir damit leben können?
- Wollen wir einfach mal die einfachste Variante versuchen, und wenn wir ein wenig Erfahrung gesammelt haben, nochmal darüber reden?
- Können wir es uns leisten, erst mal alle Ansätze umzusetzen (Stichwort: “Set Based Design”), und später eine Entscheidung treffen, wenn wir mehr Erfahrung haben?
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.”
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.