Software-Entwicklung: Rollenspiele ersetzen langwierige Planungsphasen

Sprecherin: heise meets … – Der Entscheider-Talk. Wir besprechen kritische, aktuelle und zukunftsgerichtete Themen aus der Perspektive eines Entscheiders. heise business services begrüßt Persönlichkeiten aus Wirtschaft, Wissenschaft und Politik. Immer aktuell und nah am Geschehen.

Sprecher: Herzlich willkommen, Stefan Priebsch. Wer Stefan Priebsch noch nicht kennt – Stefan, sag zwei, drei Sätze zu dir, bevor wir in medias res gehen.

Stefan Priebsch: Ich bin Stefan. Ich bin ein Software-Success-Consultant. Das heißt, ich helfe Unternehmen, Software von einem Kostenfaktor zu einem Erfolgsfaktor zu bringen. Das ist eigentlich mein kurzer Elevator-Pitch und mehr muss es auch gar nicht sein. Wer mich in die bevorzugte Suchmaschine oder KI eingibt, findet da typischerweise ganz viel über mich. Und das meiste davon ist sogar wahr.

Sprecher: Das meiste ist wahr. Ich habe auch etwas sehr gut Verstecktes auf YouTube von dir gefunden. Da hast du eine Gitarre in der Hand. Das steht jetzt aber nicht im Vordergrund.

Stefan Priebsch: Nein, das ist jetzt – du gräbst alte Kamellen aus. Wenn man weiß, wo man suchen muss, findet man Demos von einer Band, in der ich mal gespielt habe. Das ist aber jetzt schon so lange her, dass schon nicht mehr wahr ist.

Sprecher: Ich ziehe trotzdem den Hut vor allen Menschen, die musikalisch sind, denn ich bin es leider nicht. Und neben der Musikalität hast du ein tolles Hobby, das du zum Beruf gemacht hast, wie du gesagt hast – nämlich Firmen auf dem Weg zum Einsatz mit Software zu begleiten. Was ist dein Ansatz, wenn du in ein Unternehmen kommst? Wie gehst du daran?

Stefan Priebsch: Ich muss ein bisschen ausholen, glaube ich. Irgendwann als Teenager, da war ich ungefähr zwölf, hat mein Papa einen Computer mit nach Hause gebracht. Das war Anfang der 80er-Jahre. Mein erster Gedanke: Was zur Hölle ist das? Ich fand es dann aber sehr spannend und habe mich damit mit den Computerdingen beschäftigt. Irgendwann habe ich relativ schnell beschlossen, ich will Informatik zu studieren, weil ich Computer toll fand.

Ich hatte das Glück, mein Studium schon durch eine Selbstständigkeit zu begleiten, weil als Student braucht man ja ein bisschen Geld, und da hat sich die Möglichkeit ergeben, mich selbstständig zu machen. Als IT-Berater habe ich damals Vernetzungen gemacht – das war noch State of the Art: Novell-Netzwerke und so weiter. Für Steuerberater, Rechtsanwälte und Ärzte habe ich so Netzwerke aufgebaut und Computer administriert.

Dabei habe ich relativ schnell gelernt, dass dieses IT-Ding eigentlich ein Menschenbusiness ist. Wir müssen hier was machen für Menschen und wir müssen es auch so machen, dass die Menschen es mitgehen wollen und können. Das zieht sich eigentlich so durch. Ich würde heute sagen: IT ist, so wie ich es begreife, kein technisches Thema, sondern ein Menschenthema.

Ich arbeite eigentlich mit Menschen. Ich arbeite mit Entwicklern und muss denen etwas beibringen, muss sie aus der Komfortzone holen, damit sie sich für neue Ideen öffnen. Wenn man mit Anwendern oder Fachexperten spricht, muss man sich auch in deren Welt begeben. Es wird nicht besser, wenn man anfängt, mit technischen Fachbegriffen um sich zu werfen, um seine Kompetenz zu unterstreichen – und dann Bullshit-Bingo in den Raum zu werfen, das eigentlich keiner versteht.

Wenn ich ganz weit zurückdenke: In der Schule hatte ich sehr viele tolle Lehrer, aber einer ist mir besonders in Erinnerung geblieben. Das war ein Biologielehrer, der hat gesagt: „Das Beste an einem Nobelpreisträger ist, dass er einem Fünfjährigen sein Fachgebiet erklären kann." Dieser Satz begleitet mich seit meiner Kindheit. Ich finde den toll, weil: Wenn du einem Fünfjährigen dein Fachgebiet erklären kannst, dann kannst du es ohne Bullshit-Bingo und ohne Fachausdrücke. Dann kannst Du es und musst du es wirklich auf das Einfache reduzieren.

In gewisser Weise ist das ein Kommunikationsansatz, der gut funktioniert. Ich möchte jetzt damit nicht den potenziellen Fachanwender oder Kunden zum Fünfjährigen degradieren. Aber wir dürfen keine Branchenkompetenz voraussetzen, wie wir sie aus der IT kennen. Ich muss die Leute in ihrer Sprache abholen, in ihren Worten. Ich muss mit ihnen gemeinsam ihr Problem verstehen. Das Problemverständnis, was Leute haben, ist ja teilweise ein komplett anderes als meins. Wir müssen erst mal auf ein gemeinsames Problemverständnis kommen und dann können wir von dort aus über einen Lösungsraum sprechen. Das ist im Grunde mein Ansatz.

Sprecher: Du hast auch auf der OOP in München drüber gesprochen. Das war eigentlich der Anlass für diesen Podcast. Du hast dort einen Vortrag gehalten und wir haben gesagt: Hey, der Priebsch, dieser Teufelskerl, der kann so viele tolle Sachen erklären – das muss man einem breiteren Publikum vorstellen. Wir sprechen über domainengetriebenes Modellieren. Das klingt jetzt so, als ob das im Wortschatz eines Fünfjährigen noch nicht zwingend drin ist. Was ist domainengetriebenes Modellieren? Bitteschön, Stefan.

Stefan Priebsch: Der Begriff geht zurück auf ein Buch von Eric Evans, das er 2003 veröffentlicht hat: „Domain Driven Design", also domainengetriebene Entwicklung. Auf Deutsch ist das ein etwas sperriger Begriff. Wir würden sagen: fachlichkeitsgetriebene Entwicklung. Das ist eine Entwicklungsphilosophie, die genau das beinhaltet: Lasst uns doch mal über die Fachlichkeit reden und von der Fachlichkeit kommen – und nicht so in die Technik eintauchen und nicht Technologie, technologiegetriebene Entwicklung machen.

Worum es in dem Workshop hauptsächlich geht, ist ein gemeinsames Verständnis. Wenn wir eine Problembeschreibung nehmen und mehrere Leute im Raum sind, die vielleicht auch einen unterschiedlichen fachlichen Hintergrund haben, dann ist es typischerweise so: Jeder glaubt erst mal, eine Idee für das Problem zu haben. Und jeder glaubt, dass er die gleiche Idee hat wie alle anderen, weil wir uns dann vielleicht oberflächlich mit ein paar Worten kurz verständigen und dann sagen alle: „Ja genau, ich habe auch so eine Idee."

Was aber in der Realität passiert: Wir haben ein sehr unterschiedliches Bild im Kopf. Wir interpretieren die Begriffe anders. Im Detail sieht einer Probleme, die ein anderer gar nicht sieht – und der sieht dafür wieder andere Schwierigkeiten. Was wir jetzt schaffen müssen, ist ein gemeinsames Bild. Die Ideen und das Wissen, die Bilder in den einzelnen Köpfen müssen vereinheitlicht werden.

Das kann man sehr gut schaffen, indem man sich an eine Grundregel hält: Diskutiere nie etwas Unsichtbares. Wenn wir über etwas reden, das nur in unseren Köpfen ist, dann ist es unsichtbar. Dann werden wir immer Reibungsverluste haben.

Sprecher: Kenne ich aus der Kommunikationstheorie – der gemeinsame Zeichenvorrat. Der muss einfach verhandelt sein.

Stefan Priebsch: Genau. Wir müssen das, was wir diskutieren, greifbar machen. Im kollaborativen Modellieren – was dann ist im Prinzip unser Ansatz, unser Lösungsvorschlag, wie man domänengetriebene Entwicklung beginnen sollte – modellieren wir gemeinsam das Problem beziehungsweise Lösungsideen zu diesem Problem.

Da gibt es einen ganzen Baukasten von Methoden: Event-Storming, Domain-Storytelling, Architectural Role Play und andere. Die haben alle gemeinsam, dass sie sehr leichtgewichtige Methoden sind. Du musst keine Notation lernen, du nicht viel Tooling haben. Wir arbeiten eigentlich mit Strichmännchen, Pfeilen und Kästchen, Klebezetteln – oder im Rollenspiel, indem wir einfach einen Prozess durchspielen.

Sprecher: Erklär uns das mal ganz einfach. Rollenspiel – wie läuft das bei dir ab? Welches Modell entwickelst du, um die Leute an die Hand zu nehmen und ein tolles Ergebnis zu erreichen?

Stefan Priebsch: Ich sage den Leuten: Spielt mir das mal vor. Typischerweise habe ich eine Gruppe von Leuten im Raum. Nehmen wir einen Prozess, den jeder kennt: Wir wollen ein Restaurant aufmachen. Dann haben wir ein paar Tische, eine Küche und eine Bar. Jetzt müssen wir uns überlegen: Wie geht das eigentlich? Was machen wir da? Was brauchen wir?

Jetzt könnten wir einfach sagen: Gut, stellen wir mal einen Tisch hin, da kommen zwei Gäste rein und setzen sich. Und dann ist die erste Frage schon: Kommen die zur Tür rein und setzen sich einfach hin? Oder wie machen wir das? Die erste Frage: Gibt es einen Empfang, wo man die Leute begrüßt und ihnen einen Tisch zuweist? Oder gehen die einfach rein und setzen sich selbst an einen Tisch?

Die Frage wird wahrscheinlich relativ schnell aufkommen, wenn du sagst: Ihr beiden seid Gäste, kommt doch mal einfach rein ins Restaurant und setzt euch hin. Dann bleibt der eine vielleicht stehen und fragt: „Müssen wir hier auf einen Platz warten?" Der andere sagt: „Ach, lass uns einfach hinsetzen." Dann hätten wir an dieser Stelle schon ein Thema entdeckt – und zwar sehr leichtgewichtig.

Dann können wir sagen: Gut, wollen wir uns jetzt in der Tiefe darum kümmern? Ganz wichtig ist, dass jemand am Flipchart steht und beispielsweise aufschreibt: „Wir müssen darüber nachdenken, ob wir einen Empfang haben wollen oder nicht" – als nachgelagerte Frage.

Dann setzen sich die Gäste hin und es stellt sich die Frage: Was wollen die bestellen? Da brauchen die eine Speisekarte. Wo kommt die Speisekarte her? Dahinter steckt natürlich noch viel mehr, weil auf der Speisekarte Sachen stehen, die vorab aus der Küche kommen und mit Einkäufen hinterlegt sein müssen. Das ist ein komplett eigenes Thema, wo man sagen kann: Für jetzt nehmen wir einfach an, wir haben eine Speisekarte mit ein paar Sachen drauf. Wir müssen uns aber dann noch mal darum kümmern, wo die eigentlich herkommt.

In diesem Rollenspiel, wo man die Leute in Rollen steckt – du bist der Kellner, du bist der Barmann, du bist der Koch, ihr seid die Gäste – entdeckt man aus dem Moment heraus auf sehr schnelle, leichtgewichtige Weise, was man braucht und welche Fragestellungen man hat. Und man stellt fest, dass es tatsächlich relativ herausfordernd ist, so einen Prozess einmal durchzuspielen.

Wenn du nämlich irgendwann fragst: Wo genau hattest du das Geschirr her, auf dem der Koch das Essen angerichtet hat? Und wo genau hast du beim Abräumen das Geschirr hingebracht? Was passiert dann damit? Das entdeckt man alles sehr schnell.

Es gibt natürlich auch andere Modellierungsmethoden. Jeder soll die Methode verwenden, die ihm in der Situation am sinnvollsten erscheint. Meine Erfahrung ist, dass man mit dem Rollenspiel sehr schnell viele Probleme entdeckt – und viele Themen und Fragestellungen, die man mit anderen Methoden vielleicht gar nicht streifen würde.

Darum geht es eigentlich: dass wir auf leichtgewichtige Art und Weise möglichst schnell viele Erkenntnisse gewinnen – Domain Discovery oder Domain Exploration, um es in Fachausdrücken zu benennen. Anders gesagt: Wir können sehr viel lernen. Nach einer halben oder dreiviertel Stunde Rollenspiel haben wir sehr viele Erkenntnisse und sehr viele Fragen.

Ich schreibe normalerweise Zettel. Ein Teller wird einfach durch einen Papierzettel repräsentiert, auf dem „Teller" steht. Den kann man dann auch herumreichen. Für alle Artefakte, die wir entdecken, schreiben wir Zettel. Für die Rollen, die wir entdecken, schreiben wir Zettel. Die haben die Leute dann auch in der Hand. Ich bin der Kellner, dann bin ich quasi als Kellner beschriftet. Am Ende der Session kann ich einfach alle Zettel einsammeln und habe dann schon eine erste Dokumentation: Was haben wir an Rollen entdeckt? Was haben wir an Artefakten? Der Entwickler würde sagen: Entitäten, Gegenstände, Objekte. Was haben wir entdeckt? Was brauchen wir?

Und was ganz wichtig ist: Das macht Spaß. Wenn man die Leute nicht zum Rollenspiel einlädt, sondern das Rollenspiel einfach passieren lässt, haben sie einen Riesenspaß daran. Am Anfang sind manche etwas zögerlich, und dann haben sie plötzlich einen Riesenspaß dran, das durchzuspielen. Dann sagt jemand: „Ja, pass mal auf, aber was ist denn, wenn …?" Dann sage ich: „Moment, gar nicht reden. Welche Rolle möchtest du jetzt haben? Dann spielst du es uns vor."

Wenn jemand ein Problem diskutieren möchte, schlage ich vor, dass er eine bestimmte Rolle einnimmt. Dann sagt er: „Hey, lieber Kellner, ich tausche mal mit dir die Rolle. Ich bin jetzt der Kellner." Und beim nächsten Durchlauf machst Du einfach etwas Überraschendes. Zum Beispiel denkst Du Dir: Was ist, wenn ich jetzt einen Teller runterschmeiße? Dann machst Du das im Spiel und plötzlich gibt es eine interessante Reaktion von allen. Du hast in diesem Moment garantiert jemanden in der Gruppe, der sofort sagt: „Wir müssen jetzt Folgendes beachten" oder „Folgendes machen." Ich kenne keine andere Methode, mit der man das so schnell und mit so viel Spaß herausfinden kann.

Zwei weitere Aspekte finde ich besonders toll. Erstens: Du hast eine Rolle und baust ein gewisses emotionales Attachment zu dieser Rolle auf. Wenn ich als Softwareentwickler einen Prozess gespielt und erlebt habe und dann diesen Prozess in Software umsetzen kann, habe ich einfach eine innere Verbindung. Ich weiß, wie der Prozess sich anfühlt. Ich weiß, wie er abläuft. Ich war da mal mit drinnen. Da habe ich einen anderen Zugang zu, als wenn ich aus irgendeinem Jira-Ticket irgendwo gelesen habe: „Als Stakeholder möchte ich, um zu …" – solche Sachen. Das ist alles auch hilfreich, aber einmal in dieser Situation mit drin gewesen zu sein hilft den Leuten, ein emotionales Attachment aufzubauen, um dann einfach eine bessere Lösung zu liefern.

Und: Wir haben alle Spaß gehabt und das erzeugt eine positive Stimmung. Die Leute sagen: „Hey, wir haben jetzt gemeinsam Domain Modelling gemacht und es hat Spaß gemacht." Das war nicht dröge, das war nicht formalisiert, nicht irgendwie Technologie-Blabla. Eigentlich sagt jeder für sich, wenn er aus der Session rausgeht: „Ich habe total viel gelernt. Total viele Sachen, über die ich noch nie nachgedacht habe, sind plötzlich auf meinem Radar. Ich habe total viele Aspekte entdeckt, die eigentlich wichtig sind."

Und das ist genau, was wir erreichen wollen: ein gemeinsames Verständnis für die Domain, damit wir dann eine möglichst angemessene Lösung entwickeln können. Eine Lösung, die nicht technisch unnötig komplex ist. Eine Lösung, die für die Anwender geeignet ist – und nicht eine, bei der wir hinterher das Problem haben, dass die Anwender sie gar nicht akzeptieren oder so nicht nutzen werden.

Sprecher: Ich gehe ja mit dir mit. Spaß steht im Vordergrund und so weiter. Aber nun gibt es den einen oder anderen, der mag kein Rollenspiel. Der Zweite sagt vielleicht: „Du, ich lasse mich auf das, was der Stefan da vorschlägt, nicht ein. Ich frage eine KI." Da stehen dir die Haare zu Berge, oder?

Stefan Priebsch: Naja, erstens mal hast du in jeder Methodik immer – und das ist auch ein Grund, warum ich das Rollenspiel so entwickelt habe – Du hast einen Raum typischerweise voller Leute. Ein paar davon sind sehr aktiv. Das sind typischerweise die, die sich am Whiteboard versammeln, die mit den Markern in der Hand Diagramme zeichnen oder Klebezettel da hinpacken. Dann hast du viele Leute, die sind nicht so aktiviert, und irgendwann fangen die an, auf ihr Smartphone zu gucken.

Ich habe mich immer gefragt: Wie schaffe ich es, möglichst viele Leute zu aktivieren und einzubeziehen? Ich glaube, dass jeder, der in dem Raum ist, wertvolles Wissen hat und etwas Wertvolles mitbringt. Das ist genau die Idee: Ich möchte eigentlich die Leute aktivieren.

Wenn jetzt jemand sagt, er findet Rollenspiel doof – es gibt im Rollenspiel auch die Rolle des Dokumentierers. Möchtest du am Flipchart stehen und Fragen aufschreiben, die auftauchen aufschreiben? Oder bist du jemand, der Domain-Storytelling gern mag? Dann bitte, schreib mit und dokumentiere eine Domain-Story in einem Format deiner Wahl. Es gibt da sehr viele Möglichkeiten.

Es gibt auch die Rolle, die ich Analyst nenne. Da setze ich mich einfach als Beobachter hin und sage: Okay, ich schaue mir an, wie die Gruppendynamik hier ist, und habe dann vielleicht Ideen. Zum Beispiel: „Da machen sie etwas falsch." Das kann ich aufschreiben. Dann haben wir es zumindest irgendwo dokumentiert und entdeckt.

Selbst wenn jemand nicht aktiv in einer Rolle mitspielen will, kann er seinen Platz finden. Meine Erfahrung ist: Am Anfang sind die Leute immer sehr zögerlich. Und dann kommt irgendwann jemand, der sagt: „Naja, aber dann brauchen wir doch jetzt hier …" Wir hatten in dem OOP-Workshop ein Szenario aus der Landwirtschaft – wir wollten landwirtschaftliche Produkte zum Konsumenten bringen. Dann sagt jemand: „Ja, wir brauchen ja den Landwirt." Dann sage ich: „Ja, du hast gerade den Landwirt entdeckt." Dann drücke ich ihm einen Zettel und einen Stift in die Hand, er schreibt „Landwirt" drauf und hat diese Rolle geerbt. Er kann die Rolle dann auch wieder abgeben, weil wir die Rollen tauschen können – insbesondere wenn wir Besonderheiten einbringen wollen.

Meine Erfahrung ist, dass die Leute dann mit großer Begeisterung dabei sind. Ich hatte aber auch gerade im OOP-Workshop jemanden, der gesagt hat: „Wir sind ein eher konservatives Enterprise. Wenn ich meine Manager zum Rollenspiel einlade, dann kommen die nicht."

Sprecher: Das wäre jetzt meine Frage gewesen: Wie holt man alle ab?

Stefan Priebsch: Ja, ich lade die Leute nicht zum Rollenspiel ein. Ich stelle am Anfang so eine Frage wie: „Wie würden wir das jetzt hier machen? Wie würden wir vorgehen? Was habt ihr für Ideen? Wie modellieren wir das?" Dann ist da meistens eine gewisse Unsicherheit. Dann sage ich etwas wie: „Probiert das doch einfach mal aus. Was brauchen wir, wie ist denn das dann? Vielleicht kannst du mal hier …" Und dann gleitet man so ins Rollenspiel hinein.

Das hat für mich bis jetzt tatsächlich immer funktioniert. Und wenn die Leute es einmal gemacht haben, ist die Hürde überwunden. Dann kann man auch sagen: Wir wollen da jetzt weitermachen. Eine gute Empfehlung ist, am Anfang den Happy Path anzuschauen – den Gutfall. Die Leute kommen ins Restaurant, essen dort, bezahlen, sind glücklich.

Dann wollen wir vielleicht in einer nachfolgenden Session speziell Fehlerfälle anschauen. Was ist, wenn die Leute nicht bezahlen wollen? Wenn die Kreditkarte nicht akzeptiert wird? Was man da alles an Szenarien überlegen könnte, kann man in einem Rollenspiel wunderbar ausprobieren. Dann hast du einen Kunden, der ungeduldig wird und sagt: „Ich sitze hier seit einer halben Stunde und möchte bei euch bezahlen und irgendwie geht es gerade nicht." Dann habe ich etwas, womit ich arbeiten kann.

In einem eher theoretischen Ansatz wie Event-Storming mache ich vielleicht einen Klebezettel, auf dem steht: „Die Kreditkarte wurde abgelehnt." Okay, aber was heißt das jetzt eigentlich?

Was man auch sagen muss: Es gibt viele Leute, die immer glauben, es gäbe einen goldenen Hammer – die eine Methode, „the one to rule them all". Das ist natürlich nicht richtig. Du brauchst immer einen Mix aus Methoden. Ich finde, dass ein Rollenspiel sehr gut für die schnelle Discovery geeignet ist und komplementär zu dokumentierenden Methoden wirkt. Du brauchst auf jeden Fall auch eine Dokumentation. Die kannst du auf verschiedene Weisen machen und sie muss das Rollenspiel ergänzen.

Ich würde also nie den Anspruch erheben, es gäbe ein Format, und nur weil es von mir kommt, wäre es das Einzige, was ihr braucht, und alle anderen könntet ihr vergessen. Das ist natürlich Quatsch. Man muss immer im Kopf behalten, dass die Formate nur dafür da sind, unseren gemeinsamen Denkprozess zu strukturieren.

Sprecher: Ich lerne daraus: Moderation ist enorm wichtig. Du holst alle ran und passt auf, dass sich alle ordentlich austauschen. Wir haben ausführlich über das Rollenspiel gesprochen. Wenn das nun aus irgendwelchen Gründen scheitert, nicht zustande kommt oder nicht möglich ist – welche Methoden hast du noch in petto?

Stefan Priebsch: Das Rollenspiel ist typischerweise etwas, das wir einsetzen, wenn wir einen neuen Prozess entdecken wollen oder einen bestehenden Prozess überdenken möchten. Dann gibt es typischerweise das Spannungsfeld: Ich habe eine existierende Lösung, teilweise auch mit Software, und die Frage ist: Was macht diese Software eigentlich? Was ist aktuell unser Prozess?

Wenn du das in Software hast, ist das eine eher technische Fragestellung. Dann muss Du quasi herauskriegen, wie der Prozess aktuell aussieht. Das könnte man über Analysen der Software machen – reinschauen, vielleicht Characterization-Tests einsetzen, um herauszukriegen, was da eigentlich passiert. Für den Happy Path, den Standardfall, ist es immer total klar. Aber in den Sonderfällen ist die Frage: Was passiert, wenn Mars und Jupiter in einer seltsamen Konstellation stehen? Dann weiß keiner mehr Bescheid. Da könnte ich natürlich in der Software einen Test schreiben, diese Situation in einer Testinstallation provozieren und dann sehe ich, was herauskommt. Wenn das die Situation ist, muss man vielleicht tatsächlich über die Software kommen.

Wenn es ein Prozess ist, den wir neu abbilden wollen, dann muss es über die Leute und über das Prozessverständnis gehen. Da kannst Du Event-Storming machen: Wir schauen uns an, welche fachlichen Ereignisse es gibt, und die schreiben wir einfach auf orange Klebezettel. Das ist so eine lustige Konvention, die aus einem Fehler entstanden ist, weil man geglaubt hat, gelb wäre wichtig, und davon hatte man am meisten. In Wirklichkeit sind diese fachlichen Ereignisse sehr sehr wichtig. Das wäre Event-Storming.

Beim Domain-Storytelling ist es so, dass der Fachanwender seine Geschichte erzählt, was der Reihe nach passiert, und man das in einer Art Sketchnotes mitschreibt. Das setzt aber voraus, dass man einen Fachanwender hat, der die Story so erzählen kann.

Es ist immer die Frage: Was ist denn überhaupt die Ausgangssituation und was ist die Fragestellung? Da hat man eine relativ große Bandbreite von Moderationstechniken oder auch kollaborative Modelling Methoden. Es hängt auch immer stark davon ab, was im Team schon etabliert ist. Wenn die eine Methode haben, mit der sie gut arbeiten können, warum soll ich dann die Methode wechseln?

Manchmal ist es aber genau der richtige Punkt zu sagen: Ich hole die mal aus ihrer Denkschleife heraus. Die stecken in einer Ecke und dann mache ich etwas ganz anderes, um ihnen eine neue Perspektive zu geben. Wie wir eingangs schon gesagt haben: Das ist ein sehr stark menschliches Thema. Man muss mit der Gruppe im Moment arbeiten. Was habe ich hier für Menschen? Was habe ich für Befindlichkeiten? Was habe ich für Potenziale? Dann muss man schauen, dass man das Ganze in die richtige Richtung entwickelt.

Und ja, das Feedback bekomme ich immer wieder: Moderation ist an der Stelle sehr wichtig. Gerade wenn du sehr technische Leute hast, sind die sehr gut darin, Sonderfälle zu entdecken – und noch besser darin, in Diskussionen über diese Sonderfälle abzutauchen. „Was passiert denn, wenn …?" Dann kommen Sachen, die wirtschaftlich eigentlich nicht relevant sind, weil sie alle Jubeltage mal vorkommen. Die werden aber sehr schnell zum Zentrum der Diskussion.

Da bin ich als Moderator immer sehr stringent, greife ein und sage: „Okay, wir haben das jetzt erkannt. Lasst uns das mal in unser Backlog schreiben." Ganz oft weiß ich genau: Das wird wahrscheinlich nie wieder auf den Tisch kommen. Wenn das Backlog das nächste Mal angeschaut wird, sagt man: „Das ist ein Fall, der ist gerade nicht wirklich wichtig. Den können wir erst mal ignorieren."

Das ist der Moderationstrick: die Entwickler ein bisschen aus dieser Sonderfall-Denke herausholen und auf den Happy Path fokussieren. Was passiert eigentlich idealerweise? Wir wollen als Firma a) unsere Kunden glücklich machen und b) natürlich Geld damit verdienen. Das ist der wichtigste Aspekt. Wo kommt die Wertschöpfung her? Wo kommt unser Umsatz her? Wo kommen unsere zufriedenen Kunden her? Das müssen wir herauskriegen und da müssen wir besser werden. Die ganzen technischen Sachen sind spannend und cool, aber ganz oft wirtschaftlich gar nicht so interessant, sie wirklich in die Tiefe zu verfolgen.

Sprecher: Das ist aber deine Erfahrung. Du verhinderst im Gespräch quasi, dass sich Teilnehmer recht früh auf bestimmte Techniken einschießen und sagen: „Die Lagerverwaltung, das macht der SQL-Server" oder irgendetwas Spezielles. Das blockst du über Moderation ab?

Stefan Priebsch: Ja, tatsächlich ist mein Ansatz – auch im Rollenspiel und in anderen Moderationsmethoden – zu sagen: Was ist im Kern der Prozess, den wir hier abbilden? Selbst wenn wir ein etabliertes Unternehmen haben, sich einmal auf diesen Kernprozess zurückzubesinnen und zu fragen: Was ist eigentlich das, was uns vom Kundenwunsch bis zum Umsatz führt? Was muss da alles passieren?

Oftmals hilft es, diesen Fokus reinzubringen, damit die Leute sagen: Okay, wenn das der Fokus ist, dann sind ja ganz andere Sachen wichtig. Dann ist es nicht mehr die Frage, ob das diese oder jene Software ist, ob das ein SQL-Server oder ein Konkurrenzprodukt ist, ob wir das in dieser oder jener Programmiersprache lösen.

Entwickler hören das vielleicht nicht so gerne. Natürlich, genau wie ein Englisch-Dolmetscher – wenn ich dem sage: „Kannst du mal eben Französisch dolmetschen?", dann tut Du Dich schwer. Du wirst immer dazu tendieren, das Gespräch auf Englisch führen zu wollen. So hat ein Entwickler auch seinen Hintergrund und neigt dazu, die Technologien vorzuschlagen, in denen er sich wohl fühlt.

Sprecher: Also back to the roots.

Stefan Priebsch: Ja, man kann es sogar noch einen Schritt weiterdenken. Wenn du einen Entwickler fragst, was die Lösung für dein Problem ist, kriegst du sehr wahrscheinlich die Antwort: „Wir entwickeln was." Weil du ja einen Entwickler fragst. Wenn du das anders benennen würdest – vielleicht einen Problemlöser oder einen internen IT-Dienstleister, einen internen – und sagst: „Pass mal auf, du hast einen größeren Lösungsraum als nur Software zu entwickeln. Du könntest auch Softwarelösungen verwenden, die es schon gibt." Dann haben wir einen ganz anderen Lösungsraum, über den wir sprechen können. Vielleicht ist es dann viel schlauer, etwas nicht zu entwickeln, sondern etwas Fertiges zu verwenden.

Im „Domain Driven Design“ hat schon Eric Evans damals aufgeschrieben: Ihr müsst herauskriegen, was eure Kerndomäne ist – eure Core Domain. Was macht euch einzigartig als Unternehmen? Wo verdient ihr Geld? Wo liegt euer Wettbewerbsvorteil? Da solltet ihr hinschauen, das solltet ihr richtig genau analysieren und modellieren.

Und so generische Teilfachlichkeiten – Generic Subdomains im Englischen. Das sind Teile, mit denen jeder zu tun hat, wie zum Beispiel Buchhaltung. In Deutschland bist du gesetzlich dazu verpflichtet. Das Gesetz sagt zwar nicht genau, wie du es machen musst, aber dass du es machen musst. Jedes Unternehmen muss Buchhaltung machen. Das ist aber typischerweise kein differenzierender Faktor. Keiner ist am Markt erfolgreicher, weil er besser Buchhaltung macht als die anderen. Da geht man halt zu DATEV oder so. Da ist kein großer Blumentopf zu holen – außer du bist die DATEV selbst. Dann wäre Buchhaltung natürlich deine Kerndomäne.

Wenn man diese Denkweise einnimmt, sieht man relativ schnell, dass man gar nicht alles als Software selbst bauen kann und sollte – auch und gerade mit der KI, die wir heute zur Verfügung haben. Vielleicht sollte man viel mehr darauf setzen, bereits vorhandene Lösungen miteinander zu integrieren und dann schauen, wo man mehr Wert schafft.

Aber du hast die KI-Frage, glaube ich, noch mit einer etwas anderen Motivation gestellt.

Sprecher: Richtig.

Stefan Priebsch: Ich glaube, dass wir heute an dem Punkt sind, wo wir akzeptieren müssen, dass das KI-Thema da ist. Wir sind uns wohl alle einig: Das wird nicht mehr weggehen.

Ich habe relativ gute Erfolge damit, zum Beispiel in einer Modellierungssitzung, in der ein bestimmter Fachexperte nicht da ist. Es ist gerade kein Anwalt da oder niemand aus der Rechtsabteilung. Dann könnte man sagen: Wir klammern das Thema ganz aus – wahrscheinlich eine schlechte Idee. Man könnte sagen: Wir machen wilde Annahmen. Wenn ich als Entwickler irgendwelche juristischen Annahmen mache, ist das vielleicht auch nicht so gut.

Wir könnten jetzt aber sagen: Wir nehmen so ein ChatGPT oder etwas Ähnliches und sagen: „Du bist jetzt Rechtsanwalt. Wir haben folgende Frage an dich – was würdest du antworten?" Da kommt eine Antwort heraus, die natürlich frei erfunden sein kann. Aber sie ist besser als nichts.

Ich habe immer wieder Erfolgsberichte gehört von Leuten, die in solchen Sitzungen KIs in Rollen gestellt haben. „Du bist jetzt der Fachexperte für dies oder das. Was ist deine Position?" Oder: „Stell dir vor, du bist der Anwender von so einem System. Was wären deine Bedürfnisse und Wünsche?" Da bekommt man auf jeden Fall eine gute Inspiration. Man bekommt einen Input, etwas Verwertbares. Das heißt ja nicht, dass wir blind dem folgen müssen, was die KI ausspuckt.

Ein bisschen in die Zukunft gedacht: Unter Fachleuten warten viele eigentlich nur darauf, dass die KI als gleichberechtigter Gesprächspartner irgendwann am Tisch sitzt. Sie hört mit zu und schaltet sich ein, wenn sie etwas zu sagen hat oder wenn man sie was fragt. Das kann ich mir durchaus vorstellen. Ist vielleicht ein bisschen scary. Andererseits – mit Alexa haben das viele Leute ja freiwillig schon zu Hause, dass Alexa immer zuhört. Und wenn du sagst: „Alexa, kannst du mal bitte einen Witz erzählen?", dann macht sie das.

Sprecher: Aber bevor wir über diese Zukunft reden, lass mich noch mal kurz einhaken. Der Workshop ist beendet, die Runde ist abgeschlossen. Wo ist jetzt der Benefit, wenn Stefan Priebsch nach Hause geht? Was habe ich als Unternehmen davon? Was passiert da? Welche konkreten Ergebnisse habe ich nach der Modellierung?

Stefan Priebsch: Du hast ein Modell. Ein Modell ist immer eine vereinfachte Abbildung der Realität. Wir müssen – und das ist die Kunst – die Realität vereinfachen, weil die Realität so schrecklich komplex ist, dass man das alles gar nicht berücksichtigen kann.

Wenn man sich überlegt, dass man Menschen betrachtet und dann biologisch hinein zoomt – dann spricht man von Zellen und Hormonen und hat eine gigantische Komplexität im System Mensch. Das abstrahieren wir typischerweise weg, indem wir sagen: Der Priebsch, der hat ein Gesicht. Und was hinter dem Gesicht alles passiert, das ignorieren wir. Das ist ein Modell. Du schaffst immer eine Abstraktion, du lässt also immer Details weg.

Die wichtige Frage ist: Lasse ich die richtigen Details weg? Abstrahiere ich hoch genug, aber bin ich detailliert genug, damit mir nicht hinten raus etwas fehlt, was für mein Modell wichtig ist?

In der Menschheitsgeschichte haben wir in den letzten Jahren gelernt, dass wir bei der Abstraktion „Mensch" auch ein bisschen schauen müssen, wie es dem einzelnen Menschen gerade geht – und das auch in der geschäftlichen Beziehung berücksichtigen. Vor 30, 40 Jahren war das weniger so. Da hat man gesagt: Mensch, du bist halt irgendwie ein Kommunikationspartner. Ich glaube, das ist ein gutes Beispiel dafür, dass man auch in der Abstraktion über die Zeit immer wieder weiterentwickeln muss. Wir müssen jetzt Dinge betrachten, die wir bisher ignoriert oder gar nicht gesehen haben. Man muss unterscheiden: Haben wir sie gar nicht gesehen? Oder haben wir sie bewusst ignoriert, weil wir wussten, dass sie da sind, und gesagt haben: „Nein, das gehört jetzt nicht in unser Modell."

Du bekommst aus dem Workshop also ein Modell. Das ist immer ein Work in Progress, ein aktueller Stand. Entweder ein sehr grob granulares Modell oder an manchen Stellen schon sehr fein granuliert. Modellieren ist etwas, das du zyklisch immer wieder machst. Du fängst mit einem Big Picture an: Wie sieht der übergeordnete Prozess aus? Wie erreichen wir unsere Ziele? Dann gräbt man sich nach und nach in Detailfragestellungen, in Teilprozesse, in das, was außerhalb des Happy Paths liegt. Was passiert, wenn etwas schiefgeht? Man versucht, es auf der Modellierungsebene zu verstehen.

So eine Session dauert – give or take – eine Stunde oder zwei. Und wenn du nach zwei Stunden weißt, was nicht funktionieren wird oder was man besser nicht versucht, ist das deutlich günstiger, als ein Entwicklungsteam wochenlang Software bauen zu lassen und dann die fertige Lösung anzuschauen und zu sagen: „Oh super, das ist nicht das, was wir brauchen."

Wir versuchen hier, die Feedback-Loop zu verkürzen. Was diese Workshops bieten, ist das Angebot, diese Feedback-Loop deutlich zu verkürzen und sehr schnell zu Ergebnissen zu kommen, die uns ersparen, dass wir hinten raus eine unnötig komplexe oder gar die falsche Software bauen.

Sprecher: Das heißt, nach der Modellierung ist eigentlich vor der Modellierung.

Stefan Priebsch: Ja, genau. Das steht ja schon im agilen Manifest: Wir arbeiten iterativ. Und iterativ ist etwas anderes als inkrementell. Viele Leute werfen das in einen Topf. Inkrementell heißt: Ich füge immer mehr hinzu. Iterativ heißt: Ich werfe auch mal das weg, was ich schon habe, und mache es neu. Das steht schon im agilen Manifest und das ist meines Erachtens der einzige Weg, wie man wirklich auf Dauer arbeiten kann.

Das sieht man beispielsweise, wenn man eine Stadtarchitektur anschaut. Da gibt es Häuser, die sind Hunderte von Jahren alt. Irgendwann wird so ein altes Haus abgerissen und etwas Neueres hingebaut. Kein Mensch kann es sich leisten, eine ganze Stadt auf einmal einzustampfen und neu zu bauen. Auch wenn wir sagen: Die Gebäude von damals sind schlecht isoliert, verbrauchen wahnsinnig viel Energie, will man eigentlich so gar nicht haben –ja, richtige Erkenntnis. Trotzdem können und wollen wir es uns nicht leisten, die ganzen Gebäude einfach abzureißen und neu zu bauen.

Du hast immer so einen Kreislauf des Lebens – wie es im „König der Löwen" heißen würde. Und das hast du auch in der Software. Es ist ein Zyklus aus Modellieren, Umsetzen, Schauen, was man erreicht hat, Kurskorrektur – und dann wieder zurück in die Modellierung.

Sprecher: heise meets … – wir haben irre viel gelernt von Stefan Priebsch. Weil, wir haben mit Musik angefangen, wir haben mit dem „König der Löwen" geendet. Und dazwischen war ganz, ganz viel Wissen. Stefan, herzlichen Dank.

Stefan Priebsch: Sehr gerne. Vielen Dank, dass ich hier sein durfte.

Sprecherin: Das war heise meets … – Der Entscheider-Talk. Sie wollen mehr erfahren? Dann besuchen Sie uns auf heise.de. Wir freuen uns auf Sie!