Agile Methoden fordern immer wieder Feedback ein. So nutzen Retrospektiven Feedback zur Verbesserung der Arbeitsorganisation. Reviews nutzen es, um Arbeitsergebnisse zu verbessern oder nachzusteuern. Wie sieht es aber mit der Verbesserung der Softwarearchitektur aus?
In der agilen Softwareentwicklung ist Feedback meiner Ansicht nach insbesondere für das Design moderner Softwarearchitekturen richtig und essentiell. Jedoch sehe ich Teams oftmals genau in diesem Punkt scheitern. Dabei bieten altbewährte Methoden wie die Architecture Tradeoff Analysis Method (ATAM) beste Grundlagen für wertvolles und vor allem zielgerichtetes, kritisches Feedback.
Jetzt mag der eine oder andere von Ihnen der Ansicht sein, dass solche Methoden viel zu schwergewichtig sind, um im agilen Projektalltag zu bestehen. Nichtsdestotrotz oder grade deswegen möchte ich an dieser Stelle eine Lanze dafür brechen. Die Grundlegende Methodik birgt nämlich viele Chancen, um zu kritischem Feedback zu gelangen.
Das Problem mit Feedback
Schauen wir uns zunächst einmal an, worin das Problem mit Feedback besteht. Feedback ist abstrakt gesehen nicht mehr als eine Antwort eines Empfängers auf die Nachricht eines Senders. Im schlechtesten Fall ist diese Antwort sehr unspezifisch. In Teams sehe ich dies immer wieder. Oftmals ist Feedback hier nicht mehr als eine demontierende Reaktion auf das präsentierte – sei es eine einfache Idee, ein Design, Architektur oder Quellcode.
Vielfach spiegeln solche Reaktionen lediglich den Gemütszustand und die Vorlieben des Feedbackgebers wieder. Diese müssen aber nicht zwingend mit Entwurfszielen eines Designs oder einer Architektur im Einklang stehen. Diese Art von Feedback erkennt man oftmals an Anweisungen oder Belehrungen, die der Feedbackgeber äußert, oder an Hinweisen darauf, dass der Feedbackgeber gewisse Aspekte anders umgesetzt hätte.
Reaktives Feedback
Ich bin der festen Überzeugung, dass derjenige, der um Feedback bittet, viel zu oft viel zu unspezifisch danach fragt. „Gib mir mal bitte ein Feedback hierzu.“ lässt beim Empfänger viel zu viel Interpretationsspielraum darüber warum wir nach Feedback fragen oder zu welchem Aspekt genau wir gerne Feedback hätten. Der Feedbackgeber wird daher oftmals ein rein reaktives Feedback geben.
Adam Connor und Aaron Irizarry beschreiben in ihrem Buch „Discussing Design“ reaktives Feedback als instinktiv und durch Erwartungen oder Wertvorstellungen des Feedbackgebers geprägt. Alternativ spiegelt es die Erwartungshaltung des Feedbackgebers, an das was der Fragende hören will, wieder. Diese Form des Feedbacks ist damit in den wenigsten Fällen sachbezogen. Dies ist dahingehen problematisch, dass es nicht im geringsten die Effektivität spezifischer Design- oder Architekturentscheidungen beleuchtet. Darüber hinaus sind Feedbackgeber (leider) in den wenigsten Fällen die Benutzer der Software. Reaktives Feedback ist damit für das Design einer Software weitestgehend wertlos. Aussagen wie „Großartige Arbeit!“ helfen niemanden dabei besser(e) Software zu entwerfen.
Weisendes Feedback
Auf der anderen Seite sind Aussagen wie „Wenn ich du wäre, hätte ich das anders gemacht.“ genauso wenig hilfreich. Connor und Irizarry bezeichnen diese Art von Feedback als weisendes Feedback. Hier ist der Feedbackgeber geneigt das Design oder den Architekturentwurf mehr an seine eigenen Erwartungen bezüglich einer Lösung anzugleichen. Er gibt dabei lediglich seine eigene Sicht der Dinge wieder. Die Problemstellung ist ähnlich wie beim reaktiven Feedback. Sicherlich können in diesem Fall weitere Erläuterungen und Lösungsvorschläge dazu beitragen, bessere Software zu entwerfen. Letztlich hilft dies aber dem Fragenden nicht weiter. Er wird nicht verstehen können warum oder in welchem Detail sein Design oder Entwurf wenig(er) effektiv ist.
Zielgerichtete Kritik mit ATAM
Es ist daher essentiell, dass wir anstatt einer solchen Feedback-Kultur eine Kritik-Kultur schaffen. Damit meine ich nicht eine Kultur, in der ständig Kritik geübt wird, sondern vielmehr eine Kultur, die kritisches Denken fördert und fordert. Eine Kultur, die Kritik als gute Form des Feedbacks versteht.
Kritik basiert nämlich nicht auf einer Reaktion oder einer Weisung mit subjektiven Erwartungen. Kritik erfordert eine Form von Analyse basierend auf einer kritischen Denkweise – einer Denkweise, um zu bestimmen, ob eine Softwarearchitektur die gesetzten (Qualitäts-)Ziele erfüllen kann oder eben nicht.
Während eine solche kritische Analyse in Retrospektiven vielfach gelebt wird, sehe ich diese leider nur zu selten im Kontext der Diskussionen um Softwarearchitekturen. Retrospektiven laufen in der Regel nach den bekannten Phasen Intro, Set the Stage, Gather Data, Generate Insights, Decide What to Do und Closing the Retrospective ab. Bei Feedback zu Softwarearchitekturen kommt dies jedoch in der Projektpraxis viel zu selten vor.
ATAM-Phasen
Dabei basieren bewährte Methoden wie die Architecture Tradeoff Analysis Method (ATAM) auf ähnlichen Phasenmodellen. Nachfolgende Tabelle stellt die Phasen von ATAM den zuvor genannten Phasen von Retrospektiven gegenüber.
| Retrospektive | ATAM |
|---|---|
| Intro | Present the ATAM |
| Set the Stage | Present business drivers Present architecture |
| Gather Data | Identify architectural approaches Generate quality attribute utility tree |
| Generate Insights | Analyze architectural approaches Brainstorm and prioritize scenarios |
| Decide What to Do | Analyze architectural approaches |
| Closing the Retrospective | Present results |
Wie leicht zu erkennen ist, sind sich Retrospektiven und ATAM Workshops in ihrem Grundwesen sehr ähnlich. Umso verwunderlicher finde ich es, dass diese Methode in agilen Projekten so wenig Anklang und Umsetzung findet. Wahrscheinlich haben tagelange Workshops mit wochenlangen Unterbrechungen (wie sie übrigens auch im ursprünglichen Technical Report „ATAM: Method for Architecture Evaluation“ zu finden sind, vgl. Kapitel 9.4) ihr Übriges dazu beigetragen.
Ad-hoc-ATAM-Sessions
Dabei muss eine ATAM-Session gar nicht tagelang dauern. Versuchen sie doch einfach mal die grundlegenden Phasen von ATAM zu verinnerlichen. Wenn sie das nächste mal jemanden um Feedback bitten wollen, melden sie doch einfach morgens in ihrem Standup Bedarf dafür an. In der Regel finden sich immer Kollegen, die auch spontan für eine kurze Session Zeit haben. Beschränken sie diese auf eine halbe Stunde bis Stunde.
Stellen sie den Kollegen zu Beginn einer Session zunächst das Vorgehen – die einzelnen Phasen – vor. Helfen sie den Kollegen dann die notwendigen Daten als Grundlage des Feedbacks zusammenzutragen. Erläutern sie dazu einfach kurz die Motivation und Ziele, die sie beispielsweise für eine Designentscheidung zu Grunde gelegt haben. Stellen sie sich gemeinsam vor ein Whiteboard und versuchen sie Architektur- und Designansätze zu identifizieren. Übernehmen sie die Führung und stellen zunächst ihre Designentscheidungen vor. Analysieren Sie gemeinsam mögliche Risiken und Tradeoffs, die sich aus ihren Designentscheidungen ergeben, und erarbeiten sie gemeinsam weitere oder alternative Ansätze. Entscheiden sie abschließend welche Szenarien sie weiter verfolgen wollen und mit welcher Priorität.
Insbesondere in den letzten Schritten liegt der wahre Mehrwert von Feedback. Die Analyse zwingt Feedbackgeber zu einer kritischen Denkweise. Über den Weg von der Auseinandersetzung mit den eigentlichen Zielen, über mögliche Architektur- und Designansätze bis hin zum Bewerten von Risiken und Tradeoffs erkennen sie mögliche Schwachstellen ihrer Lösung. Gemeinsam erarbeitete, alternative Lösungsansätze zeigen gleichzeitig mögliche Verbesserungen auf. Eine sinnvolle Priorisierung von Szenarien und Lösungen bietet einen Plan, der ihnen die nächsten Schritte aufzeigen kann.
Fazit
Nutzen sie häufiger die Chance kleine „Ad-hoc-ATAM-Sessions“ zu machen. Sie werden sehen wie reaktives und weisendes Feedback zunehmend weniger werden. Sie werden von einer kritischen Denkweise profitieren, die zu zielgerichteter Kritik führt und sie beim Entwurf besserer Softwarearchitekturen unterstützt.
