Kollaboratives Software-Design ist eine visuelle, gemeinsame Modellierungspraxis: Entwickler, Tester, Architekten und Fachexperten sitzen in einem Raum und erarbeiten zusammen, was die Software eigentlich leisten soll. Techniken wie Event Storming und Example Mapping arbeiten mit einfachen Haftnotizen. Sie decken verborgene Annahmen auf, ersetzen die Übergabe von Dokumenten und lassen technisches und fachliches Wissen in beide Richtungen fließen, bevor die erste Zeile Code entsteht.
Das Wichtigste in Kürze
- Annahmen von Entwicklern, die nie mit den Stakeholdern sprechen, landen als laufende Software in Produktion und nicht bloß als Missverständnis auf dem Papier.
- Gemeinsame Modellierungssitzungen funktionieren, weil alle relevanten Rollen, auch Tester, Architekten und Fachexperten, direkt ein gemeinsames Verständnis aufbauen und die Kette der Dokumentübergaben entfällt.
- Einfache visuelle Techniken wie Event Storming oder Example Mapping schlagen formale Notationen, weil alle sofort mitmachen können, ohne erst eine Notation zu lernen.
- Zwanzig Minuten Example Mapping zu einem einzelnen Backlog-Eintrag zeigen, ob die Akzeptanzkriterien klar sind oder ob vor dem Programmieren noch mehr geklärt werden muss.
- Teams, die laufend mit den Stakeholdern zusammenarbeiten und direkt in die Umsetzung gehen, verlieren weniger Wissen an Tickets, Refinements und Zwischendokumente.
Warum so viel Software auf ungeprüften Annahmen steht
Der folgenreichste Fehler in vielen Softwareprojekten ist kein Bug im Code, sondern ein Gespräch, das nie stattgefunden hat. Genau hier setzt kollaboratives Software-Design an. Ohne dieses Gespräch nehmen Teams ein Ticket vom Board, setzen es um und liefern es aus, ohne zu wissen, warum die Arbeit wichtig ist oder was das Unternehmen tatsächlich braucht.
Kenny Baas-Schwegler beobachtet dieses Muster in allen möglichen Firmen: Ein Entwickler nimmt sich eine Story, bringt seine Interpretation davon in Produktion, und diese Interpretation ist größtenteils Annahme. Die Story auf dem Board ist nicht das Verständnis im Kopf des Entwicklers. In Produktion landet die Lücke zwischen beidem.
Das ist das klassische Übergabeproblem. Gien Verschatse hat es am Anfang ihrer Laufbahn selbst erlebt. Ein Business-Analyst sprach mit den Nutzern, schrieb seine Annahmen darüber auf, was die Software tun sollte, und reichte sie an das Entwicklungsteam weiter. Die Entwickler interpretierten die Interpretation des Analysten, gossen sie in Code und brachten ihn live. Die Rückmeldung war höflich und nutzlos: Das ist nicht, was wir gebraucht haben, aber trotzdem danke.
Der Schaden bleibt nicht auf Teamebene. Gien fragte einmal eine Softwareabteilung nach ihrer Strategie und hörte, der Schwerpunkt des Jahres liege auf Refactoring und der Verbesserung der alten Produkte. Das höhere Management sagte auf dieselbe Frage, in den nächsten zwei Jahren gehe es vor allem um neue Produkte. Zwei Teile derselben Firma zogen in entgegengesetzte Richtungen, ohne gemeinsames Bild davon, wohin die Reise geht.
Tester erben das Annahmenproblem
Qualität leidet stärker unter fehlenden Gesprächen als unter fehlenden Testfällen. Ein Tester steht am Ende einer Kette von Interpretationen: der fachliche Bedarf, die Übersetzung des Analysten, die Lesart dieser Übersetzung durch den Entwickler. Jede Übergabe fügt eine weitere Annahme hinzu.
Für Tester ist ein klares Verständnis dessen, was die Software tun soll, kein Nice-to-have. Es ist genau das, wogegen sie testen. Fehlt es, raten sie beim Prüfen das beabsichtigte Verhalten, und dann testen sie eine Annahme gegen eine andere.
Was kollaborative Modellierung ist
Kollaborative Modellierung ist ein visueller Entscheidungsprozess für schwierige, oft umstrittene Fragen, der ein gemeinsames Verständnis bei den Menschen schafft, die das Wissen haben. Das Wissen wird gemeinsam erarbeitet, statt es eine Kette entlang weiterzureichen. Sie ist das Herzstück von kollaborativem Software-Design.
Drei Merkmale tragen diese Definition. Sie ist visuell, denn im Kreis zu reden kostet Zeit, und was aufgeschrieben ist, lenkt das Gespräch auf das, was vor der Gruppe liegt. Sie ist für komplexe, konfliktträchtige Entscheidungen gedacht und nicht für einfache. Und ihr Ziel ist ein gemeinsames Verständnis, also genau der Teil, der Missverständnisse direkt angeht.
So unterstützt die Methode die Zusammenarbeit: Sie bricht Silos auf. Statt eines Dokuments, das eine Person schreibt und durch die Abteilungen reicht, gehen alle in denselben Raum: Entwickler, Tester, Architekten, Business-Analysten, Fachexperten. Zu den Stakeholdern gehören hier auch Entwickler und Tester, nicht nur die Fachseite. Die Gruppe geht die echten Prozesse durch, die Abläufe, die Ausnahmen und wer mit wem kommunizieren muss.
Welche visuellen Werkzeuge sich für kollaborative Modellierung eignen
Die Werkzeuge müssen so einfach sein, dass niemand erst eine zweistündige Einführung braucht, um mitzumachen. Der größte Teil der Arbeit sind Haftnotizen und grobe Skizzen. Jedes visuelle Werkzeug kann zum Modellierungswerkzeug werden, wenn es die Hürde senkt, Wissen aus den Köpfen zu holen.
Mehrere etablierte Techniken passen dazu, und keine gehört einer einzelnen Rolle:
- Event Storming: Ein orangefarbener Zettel markiert ein fachliches Ereignis, also etwas, das für das Geschäft relevant ist, etwa “Ein Sitzplatz wurde reserviert”. Von dort aus fragt die Gruppe, wann eine Reservierung nicht möglich ist, und bringt die Einschränkungen ans Licht.
- Domain Storytelling: ein weiterer gängiger Einstieg im Domain-Driven Design, um Arbeitsabläufe abzubilden.
- User Story Mapping: im Produktmanagement verbreitet, um die Gestalt eines Produkts aufzuzeichnen.
- Example Mapping (auch Beispiel-Mapping): stark im Testumfeld verankert und für Entwickler genauso nützlich, weil es auf der Frage nach konkreten Beispielen aufbaut.
- Business Model Canvas: gehört meist dem Produktmanagement, wird aber aufschlussreich, wenn ein Entwicklungsteam es ebenfalls ausfüllt und man beide Fassungen vergleicht.
Kenny stellt sie Notationen wie UML oder ArchiMate gegenüber. Die sind präzise, aber einengend, mit einem Dialekt, den nicht alle gleich lesen, und in dem Füllung oder Form eines Pfeils eine Bedeutung tragen, an die sich kaum jemand erinnert. Soll das Wissen frei in einen gemeinsamen Modellierungsraum fließen, arbeitet alles gegen dich, was auch nur eine Person ausbremst.
Ein Bild fasst die Absicht zusammen: Die Gruppe macht es wie Dumbledore, der Erinnerungen aus seinem Kopf zieht und ins Denkarium gibt. Alle schütten ihr Wissen in den gemeinsamen Modellierungsraum, damit das Team es zusammen betrachten kann.
Kollaboratives Software-Design: vom gemeinsamen Verständnis zu den Grenzen der Software
Erst verstehen, dann entwerfen. Erst wenn die Gruppe sieht, wie der Prozess in der echten Welt zusammenhängt, kann sie entscheiden, wo sie die Software schneidet.
In der echten Welt hängt alles zusammen. Software zwingt dich, diese durchgehende Wirklichkeit in Stücke zu zerlegen, aus Gründen wie Wartbarkeit, Flexibilität und Skalierbarkeit. Ziehst du eine Grenze und machst aus einem Stück einen Microservice, schneidest du künstlich durch einen Prozess, der eigentlich weiterläuft. Dieser Schnitt erzeugt Kommunikation zwischen Services, und das Modell zeigt dir die Kosten, bevor du dich festlegst.
Hier entscheidest du auch, was du nicht baust. Tritt eine Ausnahme einmal im Jahr auf, macht sie die Software komplizierter und bringt wenig. Sie von Hand zu bearbeiten, ist eine legitime Entscheidung, auch heute noch. Entwickler sträuben sich oft dagegen, aber die Frage steht im Raum: Verdient das einen Platz im System?
Weil die richtigen Stakeholder im Raum sind, kann der Entwurf den Prozess verbessern, statt ihn nur nachzubauen. Gien und Kenny nennen das duales Lernen. Die Fachseite bringt ihre Anforderungen mit, Entwickler und Tester sehen, wo Technik den Prozess klüger machen könnte. In einem Top-down-Aufbau, in dem Anforderungen einfach beim Team abgeladen werden, findet dieses Lernen nie statt.
“Sie nehmen Tickets, aber sie wissen nicht, warum sie das Ticket machen. Und ohne dieses Warum bringen sie einfach irgendetwas in Produktion. Das ist eine Annahme über ihr Verständnis des Tickets.”
(Kenny Baas-Schwegler)
Wie man skeptische Kollegen in den Raum holt
Skeptische Leute in einen Workshop zu zwingen, geht meist nach hinten los. Gibt es heute wenig Zusammenarbeit, wird ein großer Pflichttermin zur selbsterfüllenden Prophezeiung: Die Leute gehen raus und sagen, sie hätten nichts gelernt. Fang kleiner an und verdien dir den Raum.
Kenny kennt drei Wege hinein. Der erste sind Gespräche: Sprich mit den Leuten einzeln, versteh ihre Probleme und führe sie zu einer Sitzung hin, deren Sinn sie erkennen. Den zweiten nennt er Guerilla-Modellierung. In einer Firma, in der kein Team zu einem gemeinsamen Termin kommen wollte, rollte er in der Kaffeeecke eine Papierbahn aus und fing an, die Landschaft selbst zu modellieren. Die Leute liefen vorbei, sahen die Fehler und korrigierten ihn. Sichtbar falschzuliegen, zieht Menschen an. Der dritte Weg: es erst einmal still für sich selbst machen. Mit einem besseren Modell im Kopf stellst du schärfere Fragen, und irgendwann wollen die Leute wissen, wie du das so gut hinbekommst.
Gien sucht sich Verbündete, die denselben Schmerz spüren. Manche Entwickler haben es satt, dieselbe Funktion immer wieder neu zu bauen. Manche auf der Fachseite sind ehrlich frustriert, weil sie nicht bekommen haben, was sie wollten. Hol zwei oder drei von ihnen zusammen, sag, dass du etwas ausprobieren willst, und übe in kleiner Runde, bevor du vor fünfzehn Leuten stehst. Wenn diese ersten Teilnehmer anderen erzählen, dass es funktioniert hat, sinkt der Widerstand auf beiden Seiten.
Um die Post-its geht es nicht
Das Ergebnis einer Sitzung ist das gemeinsame Verständnis, nicht die Wand voller Zettel. Eines der Mottos lautet sogar, die Post-its wegzuwerfen. Was bleibt, ist das Wissen: die Geschäftsregeln, die du jetzt verstehst, der Fall, der in achtzig Prozent der Fälle eintritt, der, der in fünfzehn Prozent eintritt, und was das für den Entwurf bedeutet.
Die Vorbereitung entscheidet, ob eine Sitzung produktiv wird oder ein Termin, vor dem sich alle drücken. Setz dir vorher ein klares Ziel. Überleg, welchen Prozess oder Teil des Systems du nicht mehr verstehst, wer im Raum sein sollte und was du lernen willst. Sag den Teilnehmern, was passieren wird und was sie mitbringen sollen, meistens nur ihren Kopf. Menschen arbeiten besser, wenn sie wissen, warum sie da sind.
Wie lange eine Sitzung dauert, hängt vom Ziel ab
Eine feste Dauer gibt es nicht, denn das Format folgt dem Ziel. Die Spanne reicht vom ganztägigen Workshop bis zur knappen Übung von zwanzig Minuten.
So lässt sich das Format dem Zweck zuordnen:
| Format | Typische Dauer | Zweck |
|---|---|---|
| Big Picture Event Storming | Ein Tag, auf mehrere Tage erweiterbar | Das ganze Unternehmen abbilden, die Systeme verorten, Silos aufbrechen, abstimmen, woran zuerst gearbeitet wird |
| Architekturmodellierung (z. B. C4 oder Haftnotizen) | Anderthalb bis zwei Stunden, alle paar Wochen wiederholt | Die Architektursicht jedes Einzelnen zu einem gemeinsamen Bild zusammenführen |
| Example Mapping | Etwa 20 Minuten pro Backlog-Eintrag | Akzeptanzkriterien aufdecken; ist es nach 20 Minuten nicht klar, musst du mehr herausfinden |
Die Big-Picture-Sitzung bringt enorm viel Lernen und ein gemeinsames Gespür dafür, was sich am meisten lohnt. Deshalb macht Kenny sie, bevor er übernimmt, wo ein Kunde das Problem vermutet. Am leichtesten auszuprobieren ist Example Mapping: Nimm einen Eintrag, frag nach einem konkreten Beispiel und schau, wohin dich zwanzig Minuten bringen.
Zusammenarbeit ist die agile Schleife, nicht das Scrum-Ritual
Das stärkste Muster ist kurz: zusammenarbeiten, programmieren, Feedback holen, wieder zusammenarbeiten. Jeder zusätzliche Schritt dazwischen reicht Wissen von einem Ticket in eine andere Sicht und in ein weiteres Dokument, und bei jeder Übergabe geht etwas verloren.
Kenny hat Teams gesehen, die so arbeiten und dafür die meisten Scrum-Zeremonien fallen lassen. Retrospektiven behalten sie, Refinements lassen sie weg, weil das laufende Gespräch die schwere Dokumentation ersetzt. Solange das Verständnis frisch ist, kann der Code direkt folgen.
Das liegt näher an der ursprünglichen Idee von Agilität als vieles, was heute unter Scrum läuft. Domain-Driven Design entstand parallel zu Agile, und Eric Evans hat klar gesagt, dass die Arbeit ein fortlaufendes Gespräch mit den Stakeholdern braucht. Prüfen, anpassen, etwas entwerfen, bauen, schauen, was es tut, das Feedback zurückbringen. Wenn du jederzeit zu einem Fachexperten gehen kannst, erstarrt diese Schleife nie zum Ritual. Sie bleibt ein Gespräch.
Häufig gestellte Fragen
Warum liefern Teams immer wieder Funktionen aus, die das Unternehmen gar nicht angefordert hat?
Die Diskrepanz zwischen dem Ticket auf dem Board und dem Verständnis des Entwicklers davon gelangt als funktionierende Software in die Produktion. Kenny Baas-Schwegler beschreibt das Muster: Ein Entwickler nimmt sich eine Story, setzt seine Interpretation davon um, und diese Interpretation basiert meist auf Annahmen. In der klassischen Übergabekette schreibt ein Analyst Annahmen über Nutzerbedürfnisse auf, Entwickler interpretieren diese Interpretation, und das anschließende Feedback ist höflich und nutzlos.
Warum sollten Tester an Design-Gesprächen teilnehmen, anstatt erst am Ende zu testen?
Ein Tester sitzt am Ende einer Kette von Interpretationen: dem Geschäftsbedarf, der Übersetzung durch den Analysten, der Lesart des Entwicklers dieser Übersetzung. Jede Übergabe fügt eine Annahme hinzu. Da das beabsichtigte Verhalten genau das ist, woran Tests messen, testet ein Tester ohne dieses Verständnis eine Annahme anhand einer anderen. In kollaborativen Sitzungen sind Tester als eigenständige Stakeholder mit am Tisch.
Sind Notationen wie UML oder ArchiMate eine gute Grundlage für eine gemeinsame Designdiskussion?
Sie sind präzise, aber einengend. Beide verwenden eine Fachsprache, die die Teilnehmer unterschiedlich interpretieren, und die Bedeutung verbirgt sich in Details wie der Füllung oder Form eines Pfeils, an die sich kaum jemand erinnert. Wenn das Ziel darin besteht, Wissen aus den Köpfen der Menschen in einen gemeinsamen Raum zu bringen, wirkt sich alles, was einen Teilnehmer behindert, nachteilig aus. Haftnotizen und grobe Skizzen erfordern keine vorherige Einweisung.
Muss jede Ausnahme in einem Geschäftsprozess in der Software behandelt werden?
Nein. Wenn eine Ausnahme einmal im Jahr auftritt, sorgt das Einbauen in die Software für zusätzliche Komplexität bei geringem Nutzen, und die manuelle Bearbeitung bleibt eine legitime Option. Entwickler sträuben sich oft gegen diese Schlussfolgerung, aber die Frage ist, ob der Fall einen Platz im System verdient. Erst wenn man den tatsächlichen Prozess modelliert sieht, werden solche Entscheidungen sichtbar, noch bevor der Code existiert.
Was sollte ein Team nach dem Ende eines Modellierungsworkshops behalten?
Das Wissen, nicht die Wand voller Post-its. Eines der Mottos lautet sogar: die Post-its wegwerfen. Was bleibt, ist das Verständnis der Geschäftsregeln: der Fall, der zu achtzig Prozent auftritt, der, der zu fünfzehn Prozent auftritt, und was diese Unterscheidung für das Design bedeutet. Die Vorbereitung ist wichtiger als die Artefakte.
Solltest du skeptische Kollegen dazu bringen, an einer kollaborativen Modellierungssitzung teilzunehmen?
Leute dazu zu zwingen, geht meist nach hinten los. Wo wenig Zusammenarbeit herrscht, wird ein großer Pflicht-Workshop zu einer sich selbst erfüllenden Prophezeiung, bei der die Teilnehmer mit der Überzeugung gehen, nichts gelernt zu haben. Kenny schlägt Einzelgespräche, Guerilla-Modellierung (er hat einmal in einer Kaffeeecke Papier ausgerollt und Passanten seine Fehler korrigieren lassen) oder das stille Modellieren für sich selbst vor. Gien beginnt mit zwei oder drei Verbündeten, die das Problem bereits am eigenen Leib spüren.
Macht kontinuierliche Zusammenarbeit Scrum-Zeremonien überflüssig?
Manche werden tatsächlich überflüssig. Kenny hat Teams beobachtet, die zwar weiterhin Retrospektiven abhalten, aber keine Refinements mehr durchführen, weil der fortlaufende Austausch die umfangreiche Dokumentation ersetzt. Das Muster ist kurz: zusammenarbeiten, programmieren, Feedback einholen, wieder zusammenarbeiten. Jeder Zwischenschritt überträgt Wissen von einem Ticket in eine andere Ansicht und dann in ein anderes Dokument, und bei jeder Übertragung geht Wissen verloren. Eric Evans plädierte genau für diesen kontinuierlichen Austausch mit den Stakeholdern.
