Der Marker quietscht über das digitale Whiteboard, während im Call zehn Mikrofone stumm bleiben. "Was lief im letzten Sprint gut?", frage ich, wieder mal, und die Textfelder im Miro-Board bleiben leer. Bei einer Woche, die zu 62 Prozent aus Meetings besteht, kann ich mir das eigentlich nicht leisten, also zeichne ich inzwischen jede agile Retrospektive mit, statt sie nur zu moderieren. Sketchnotes ersetzen bei uns die klassische Liste im SaaS-Alltag, weil visuelle Notizen schneller wirken als der zehnte Stichpunkt in Confluence.
Meine Faustregel dabei ist simpel: Nicht jedes Wort bekommt ein Symbol, nur jede Entscheidung und jeder Blocker. Alles andere bleibt Text — sonst wird das Board so unübersichtlich wie die Textwüste, die es eigentlich ersetzen soll.
Warum Text in der agilen Retrospektive nicht ausreicht
Unsere Retros drehen sich um Cloud-Infrastruktur, API-Abhängigkeiten und Stakeholder-Erwartungen, Komplexität, die sich schlecht in Arial 12pt pressen lässt. Text ist linear, ein Punkt nach dem anderen, während ein Team in Wahrheit gleichzeitig an mehreren Problemen hängt. Sketchnotes lösen das nicht, weil sie hübscher sind, sondern weil sie Beziehungen zwischen Punkten zeigen, die eine Liste einfach nicht abbildet.
Ein Großteil dessen, was unser Gehirn verarbeitet, kommt über die Augen rein, nicht über geschriebene Sätze. Trotzdem versuchen die meisten Teams, Team-Dynamik und technische Blocker in eine Tabelle zu zwingen.
Bevor ich bei Sketchnotes gelandet bin, hatte ich schon anderes ausprobiert. Eine Post-it-Wand am Schreibtisch zum Beispiel, gedacht als ständiger Überblick über offene Punkte. Nach dem nächsten Sprint war sie einfach wieder leer, niemand hatte sie gepflegt. Zeichnen während der Retro selbst hat dagegen sofort funktioniert, weil es an keine zusätzliche Pflege im Nachgang gebunden ist.
Die fünf Phasen im Sketchnotes-Format
Das Modell von Derby und Larsen strukturiert jede Retro in fünf Schritte: Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close. Ich zeichne inzwischen zu jeder Phase etwas anderes, weil ein Symbol in "Set the Stage" eine andere Aufgabe hat als eines in "Decide What to Do".
In der ersten Phase reicht ein simples Stimmungsbarometer, ein paar Strich-Smileys, bewusst unperfekt gezeichnet. Zeichne ich hier zu sauber, traut sich niemand mehr, selbst etwas auf das Board zu setzen.
Perfekt ist an dieser Stelle das Gegenteil von hilfreich.
Bei "Gather Data" gruppiere ich offene Tickets nicht als Liste, sondern um ein gezeichnetes Hindernis, eine Mauer, ein Schlagloch, je nachdem, was gerade passt. Zwanzig unfertige Tickets als Text übersieht man leicht; dieselben zwanzig Tickets an einer gezeichneten Mauer sieht man auf einen Blick.
Ich habe gemerkt, dass ein Sketchnotes Kurs meine Sicht auf unleserliche Meeting Notizen änderte, weil ich seither Zusammenhänge räumlich zeige statt sie nur nacheinander aufzuschreiben.
Welche Symbole wirklich funktionieren
Ein Boot, ein Segel für Rückenwind, ein Anker für alles, was bremst. Mehr Symbolik braucht eine Retro meistens nicht. Bei einem verhauenen Deployment hat ein sonst eher stiller Senior Developer genau diesen Anker genutzt, eine Kette dazugezeichnet und sie zu einem kleinen Boot eines Nachbarteams geführt. Erst da wurde deutlich: Das Problem war keine Zeile Code, sondern eine Abhängigkeit, die vorher nie jemand benannt hatte.
Sobald ein Streitpunkt als Symbol auf dem Board liegt, gehört er nicht mehr der Person, die ihn ausgesprochen hat. Im Agile-Kontext hilft das besonders bei Priorisierungsstreits: Zwei Kollegen, die um eine Feature-Priorität streiten, diskutieren anders, wenn ihre Argumente als zwei Gewichte auf einer gezeichneten Waage liegen, dann arbeiten sie an der Zeichnung, nicht mehr gegeneinander.
Farbe kodiert Stimmung, nicht Kategorie
Farbe nutze ich in der Retro anders als in einem normalen Projekt-Meeting: Sie markiert nicht Kategorien, sondern Stimmung: was gut lief, was wehgetan hat, was das Team ändern will. Mehr Aufwand stecke ich da nicht rein, denn sobald ein Farbcode erst erklärt werden muss, hat er seinen Zweck schon verfehlt.
Sichtbare Mitschrift entscheidet, ob das Gespräch weitergeht
Hauke, unser Scrum Master, lässt sein Ladekabel ziemlich zuverlässig im Konferenzraum liegen, bevor die Retro überhaupt anfängt und wartet trotzdem lieber ein paar Minuten, bis ich mitzeichne, statt ohne Board zu starten. In der Retro entscheidet die sichtbare Mitschrift oft, ob sich Leute trauen weiterzureden; falsch gerahmt, bricht das Gespräch eher ab, statt es zu öffnen.
Genau deshalb lösche ich manche Skizzen bewusst nach der Sitzung, statt sie für immer in Confluence zu archivieren. Als ein Kollege einmal ungefragt meine Retro-Sketchnote in unseren Teamkanal postete, war das Risiko sofort greifbar: Ein geschütztes Werkzeug für den Moment kippt so leicht in ein bewertbares Protokoll, vor dem sich Leute in der nächsten Retro wieder zurückhalten.
Vorlagen als fester Rahmen für SaaS-Teams
Um nicht bei jeder Retro bei null anzufangen, nutze ich Sketchnotes Layout Vorlagen für komplexe IT Projekte im SaaS Bereich als Ausgangspunkt, den ich pro Sitzung anpasse. Ein fester Rahmen ändert auch die Erwartungshaltung im Team: Wer weiß, dass es immer eine visuelle Komponente gibt, kommt anders vorbereitet in den Termin als in eine reine Zoom-Liste.
Rainer, Stammleser aus einer Sketchnotes-Facebook-Gruppe, fragt in fast jedem Kommentar nach Minuten und Seiten: wie lange so eine Retro-Sketchnote dauert, wie viel Papier am Ende vollgekritzelt ist. Ehrliche Antwort: Vorbereitung braucht kaum Zeit, weil das meiste live während des Gesprächs entsteht, nicht davor. Ein fertiges Layout im Kopf wäre sowieso nur eine neue Textwüste in Bildern.