Hör auf zu kodieren, fang an Fragen zu stellen

Kollaboratives Softwaredesign ist eine visuelle, gemeinsame Modellierungspraxis, die Entwickler, Tester, Architekten und Geschäftsexperten in einen Raum bringt, um ein gemeinsames Verständnis davon zu entwickeln, was Software eigentlich tun sollte. Werkzeuge wie Event Storming und Example Mapping nutzen einfache Haftnotizen, um verborgene Annahmen aufzudecken, Dokumentübergaben zu ersetzen und technisches und geschäftliches Wissen in beide Richtungen fließen zu lassen, bevor Code geschrieben wird.

Das Wichtigste in Kürze

• Annahmen von Entwicklern, die nie mit Stakeholdern sprechen, erreichen die Produktion als funktionierende Software und nicht nur als Missverständnisse auf dem Papier.
• Gemeinsame Modellierungssitzungen funktionieren, weil alle relevanten Rollen, einschließlich Tester, Architekten und Geschäftsexperten, direkt ein gemeinsames Verständnis aufbauen und so die Kette der Weitergabe von Dokumenten ausschalten.
• Einfache visuelle Werkzeuge wie Event Storming oder Example Mapping übertreffen formale Notationen, weil die Teilnehmer/innen frei beitragen können, ohne erst eine spezielle Notation zu lernen.
• Eine 20-minütige Beispiel-Mapping-Sitzung zu einem einzigen Backlog-Punkt reicht aus, um herauszufinden, ob die Akzeptanzkriterien klar sind oder ob noch mehr herausgefunden werden muss, bevor Code geschrieben werden kann.
• Teams, die kontinuierlich mit Stakeholdern zusammenarbeiten und direkt zur Umsetzung übergehen, reduzieren den Wissensverlust, der sich durch Tickets, Verfeinerungen und Zwischendokumente ansammelt.

Warum die meiste Software auf unangefochtenen Annahmen aufbaut

Der größte Fehlerzustand in vielen Softwareprojekten ist kein Fehler. Es ist ein Gespräch, das nie stattgefunden hat. Teams nehmen ein Ticket vom Vorstand, implementieren es und liefern es aus, ohne zu wissen, warum die Arbeit wichtig ist oder was das Unternehmen wirklich braucht.

Kenny Baas-Schwegler weist auf ein Muster hin, das in allen Unternehmen anzutreffen ist: Ein Entwickler nimmt eine Geschichte auf, bringt seine Interpretation davon in die Produktion, und diese Interpretation ist meistens eine Annahme. Die Geschichte auf dem Board entspricht nicht dem Verständnis im Kopf des Entwicklers. Was die Produktion erreicht, ist die Lücke zwischen den beiden.

Das ist das klassische Übergabeproblem. Gien Verschatse beschreibt, wie es sich zu Beginn ihrer Karriere abgespielt hat. Ein Unternehmensanalyst sprach mit den Nutzern, schrieb ihre Annahmen darüber auf, was die Software tun sollte, und gab diese Annahmen an das Entwicklungsteam weiter. Die Entwickler interpretierten dann die Interpretation des Analysten, schrieben sie in den Code und schalteten ihn live. Das Feedback, das zurückkam, war höflich und nutzlos: Das ist nicht das, was wir brauchen, aber trotzdem danke.

Der Schaden ist nicht auf die Teamebene beschränkt. Gien fragte einmal eine Softwareabteilung nach ihrer Strategie und erfuhr, dass der Schwerpunkt für das Jahr auf dem Refactoring und der Verbesserung der alten Produkte lag. Das höhere Management sagte auf die gleiche Frage hin, dass der eigentliche Schwerpunkt für die nächsten zwei Jahre die Einführung neuer Produkte sei. Zwei Teile ein und desselben Unternehmens zogen in entgegengesetzte Richtungen, ohne ein gemeinsames Bild davon zu haben, wohin sie wollten.

Tester erben das Problem der Annahmen

Die Qualität der Arbeit leidet mehr unter fehlenden Gesprächen als unter fehlenden Testfällen. Ein Tester sitzt am Ende einer Kette von Interpretationen: die geschäftlichen Anforderungen, die Übersetzung des Analysten, die Interpretation dieser Übersetzung durch den Entwickler. Mit jeder Übergabe kommen weitere Annahmen hinzu.

Für Tester ist ein klares Verständnis dessen, was die Software tun soll, kein Nice-to-have. Es ist das, woran sie sich beim Testen orientieren. Ohne dieses Wissen können sie das beabsichtigte Verhalten nur erraten, während sie versuchen, es zu überprüfen, d. h. sie testen eine Annahme gegen eine andere.

Was kollaborative Modellierung eigentlich ist

Die kollaborative Modellierung ist ein visueller, konfliktreicher Entscheidungsfindungsprozess, der ein gemeinsames Verständnis zwischen den Menschen schafft, die über das Wissen verfügen. Dabei geht es darum, Wissen gemeinsam zu erarbeiten, anstatt es weiterzugeben.

Drei Elemente machen diese Definition aus. Es ist visuell, denn im Kreis zu reden verschwendet Zeit, und Dinge aufzuschreiben konzentriert die Konversation auf das, was vor der Gruppe liegt. Sie ist für komplexe, konfliktbeladene Entscheidungen gedacht, nicht für einfache Entscheidungen. Und das Ziel ist ein gemeinsames Verständnis, was der Teil ist, der Misskommunikation direkt angreift.

Die Methode durchbricht die Silos. Statt eines Dokuments, das von einer Person geschrieben und an alle Abteilungen weitergereicht wird, gehen alle in denselben Raum: Entwickler, Tester, Architekten, Business-Analysten, Domänenexperten. Zu den Stakeholdern gehören hier die Ingenieure und Tester, nicht nur die Geschäftsseite. Die Gruppe bespricht die tatsächlichen Prozesse, die Arbeitsabläufe, die Ausnahmen und wer mit wem kommunizieren muss.

Wie die visuellen Werkzeuge das Wissen im Fluss halten

Die Werkzeuge müssen so einfach sein, dass niemand eine zweistündige Vorlesung braucht, bevor er mitmachen kann. Der größte Teil der Arbeit besteht aus Haftnotizen und groben Zeichnungen. Jedes visuelle Werkzeug kann zu einem Modellierungswerkzeug werden, wenn es die Hürde senkt, Wissen aus den Köpfen der Menschen zu holen.

Mehrere etablierte Techniken passen auf diese Beschreibung, und keine von ihnen gehört zu einer einzigen Rolle:

• Event Storming: Ein orangefarbener Aufkleber markiert ein Ereignis, das für das Geschäft relevant ist, z. B. “Ein Sitzplatz wurde reserviert”. Von dort aus fragt die Gruppe, wann eine Reservierung nicht möglich ist und zeigt die Einschränkungen auf.
• Domain Storytelling: Ein weiterer gängiger Ausgangspunkt für das Domain-Driven Design, um Arbeitsabläufe abzubilden.
• User-Story-Mapping: wird häufig im Produktmanagement verwendet, um die Form eines Produkts zu entwerfen.
• Beispiel-Mapping: wird vor allem beim Testen eingesetzt, ist aber auch für Ingenieure nützlich, da man nach konkreten Beispielen fragen kann.
• Geschäftsmodell-Canvas: gehört normalerweise dem Produktmanagement, ist aber aufschlussreich, wenn ein Ingenieurteam es ausfüllt und die beiden Versionen verglichen werden.

Kenny vergleicht sie mit Notationen wie UML oder ArchiMate. Diese Werkzeuge sind zwar präzise, aber auch eng gefasst, mit einem Dialekt, den nicht jeder auf die gleiche Weise liest und bei dem die Füllung oder Form eines Pfeils eine Bedeutung hat, an die sich nur wenige erinnern. Wenn das Ziel darin besteht, Wissen frei in einen gemeinsamen Modellierungsraum einfließen zu lassen, ist alles, was einen Teilnehmer blockiert, ein Hindernis für dich.

Ein Bild bringt die Absicht auf den Punkt: Die Gruppe verhält sich wie Dumbledore, der Erinnerungen aus seinem Kopf in den Stiftekessel zieht. Jeder leert sein Wissen in den gemeinsamen Modellierungsraum, damit das Team es sich gemeinsam ansehen kann.

Vom gemeinsamen Verständnis zu Software-Grenzen

Das Verstehen kommt zuerst, das Entwerfen kommt als zweites. Erst wenn die Gruppe sieht, wie der Prozess in der realen Welt zusammenhängt, kann sie entscheiden, wo sie die Software einschränken will.

In der realen Welt ist alles miteinander verbunden. Software zwingt dich dazu, diese kontinuierliche Realität aus Gründen der Wartbarkeit, Flexibilität und Skalierbarkeit in Stücke zu zerschneiden. Wenn du eine Grenze ziehst und ein Stück in einen Microservice verwandelst, machst du einen künstlichen Schnitt durch einen Prozess, der eigentlich weiterläuft. Dieser Schnitt schafft Kommunikation zwischen den Diensten, und das Modell zeigt dir die Kosten, bevor du dich festlegst.

Hier entscheidest du auch, was du nicht bauen willst. Wenn eine Ausnahme einmal im Jahr vorkommt, macht es die Software komplizierter, aber es bringt wenig. Die manuelle Bearbeitung ist eine legitime Entscheidung, auch jetzt noch. Ingenieure sträuben sich oft dagegen, aber die Frage steht im Raum: Ist dies einen Platz im System wert?

Weil die richtigen Interessengruppen im Raum sind, kann das Design den Prozess verbessern, anstatt ihn nur zu kopieren. Gien und Kenny nennen das duales Lernen. Das Unternehmen bringt seine Anforderungen ein; die Ingenieure und Tester sehen, wo die Technologie den Prozess intelligenter machen könnte. In einem Top-down-Konzept, in dem die Anforderungen einem Team aufgezwungen werden, findet dieses Lernen nicht statt.

Sie nehmen Tickets an, aber sie wissen nicht, warum sie das Ticket machen. Und ohne diesen Grund werden sie einfach etwas in die Produktion bringen. Das setzt voraus, dass sie das Ticket verstehen.

Kenny Baas-Schwegler

Wie man widerspenstige Menschen in den Raum holt

Skeptische Menschen in einen Workshop zu zwingen, geht in der Regel nach hinten los. Wenn es heute wenig Zusammenarbeit gibt, wird eine große Pflichtsitzung zu einer sich selbst erfüllenden Prophezeiung: Die Leute gehen und sagen, sie hätten nichts gelernt. Fang kleiner an und verdiene dir den Raum.

Kenny bietet drei Möglichkeiten an. Der erste ist das Gespräch: Sprich mit den Leuten unter vier Augen, versteh die Probleme, mit denen sie konfrontiert sind, und führe sie zu einer Sitzung, in der sie den Sinn erkennen. Den zweiten nennt er Guerilla Modeling. In einem Unternehmen, in dem kein Team an einer gemeinsamen Sitzung teilnehmen wollte, rollte er eine Papierrolle in der Kaffeeecke aus und begann, die Landschaft selbst zu modellieren. Die Leute liefen vorbei, sahen die Fehler und korrigierten ihn. Sichtbar falsch zu liegen, zieht die Leute an. Die dritte Möglichkeit ist, es zuerst im Stillen für sich selbst zu tun. Mit einem besseren internen Modell kannst du schärfere Fragen stellen, und irgendwann wollen die Leute wissen, wie du so gut darin geworden bist, sie zu stellen.

Giens Weg ist es, Verbündete zu finden, die den gleichen Schmerz empfinden. Manche Entwickler sind es leid, immer wieder dieselbe Funktion neu zu entwickeln. Einige Leute auf der Unternehmensseite sind wirklich frustriert, weil sie nicht das bekommen haben, was sie wollten. Setz dich mit zwei oder drei von ihnen zusammen, sag, dass du etwas ausprobieren willst, und übe mit einer kleinen Gruppe, bevor du dich fünfzehn Leuten stellst. Wenn diese ersten Teilnehmer/innen anderen erzählen, dass es funktioniert hat, sinkt der Widerstand auf beiden Seiten.

Die Post-its sind nicht der Punkt

Das Ergebnis einer Sitzung ist das gemeinsame Verständnis, nicht die Wand mit den Zetteln. Eines der Mottos ist, dass du die Post-its wegwerfen solltest. Was du behältst, ist das Wissen: die Geschäftsregeln, die du jetzt verstehst, den Fall, der in achtzig Prozent der Fälle eintritt, und den, der in fünfzehn Prozent der Fälle eintritt, und was das für das Design bedeutet.

Die Vorbereitung macht den Unterschied zwischen einer produktiven Sitzung und einem gefürchteten Treffen aus. Setze dir ein klares Ziel, bevor du beginnst. Überlege dir, welchen Prozess oder Teil des Systems du nicht mehr verstehst, wer im Raum sein soll und was du zu lernen hoffst. Erkläre den Teilnehmern, was passieren wird und was sie mitbringen sollen, meist nur ihr Gehirn. Menschen arbeiten besser, wenn sie wissen, warum sie da sind.

Wie lange eine Sitzung dauert, hängt von ihrem Ergebnis ab

Es gibt keine einheitliche Dauer, denn das Format folgt dem Ziel. Die Bandbreite reicht von einem ganztägigen Workshop bis zu einer knappen zwanzigminütigen Übung.

Eine nützliche Methode, um das Format dem Ziel anzupassen:

Die Big Picture Session bietet einen enormen Lerneffekt und ein gemeinsames Gespür dafür, was sich am meisten lohnt. Deshalb führt Kenny sie durch, bevor er annimmt, wo ein Kunde das Problem sieht. Das Beispiel-Mapping ist am einfachsten: Wähle einen Punkt aus, frage nach einem konkreten Beispiel und schau, wohin dich zwanzig Minuten führen.

Zusammenarbeit ist die agile Schleife, nicht die Scrum-Zeremonie

Das stärkste Muster ist kurz: zusammenarbeiten, codieren, Feedback einholen, wieder zusammenarbeiten. Jeder zusätzliche Schritt zwischen diesen beiden Punkten ist ein Wissenstransfer von einem Ticket zu einer anderen Ansicht zu einem anderen Dokument, und bei jedem Transfer geht Wissen verloren.

Kenny hat gesehen, wie Teams auf diese Weise arbeiten und die meisten ihrer Scrum-Zeremonien aufgeben. Sie behalten die Retrospektiven bei, hören aber mit den Verfeinerungen auf, weil die kontinuierliche Konversation die Notwendigkeit einer umfangreichen Dokumentation ersetzt. Wenn das Verständnis frisch ist, kann der Code direkt folgen.

Das ist näher an der ursprünglichen Absicht von Agile als vieles, was heute als Scrum bestanden wird. Das bereichsorientierte Design existierte parallel zu Agile und Eric Evans war sich darüber im Klaren, dass die Arbeit eine kontinuierliche Konversation mit den Stakeholdern erfordert. Inspektion, Anpassung, Entwurf, Bau, Rückmeldung. Wenn du bei Bedarf zu einem Fachexperten gehen kannst, schließt sich dieser Kreislauf nie zu einer Zeremonie. Es bleibt ein Gespräch.