Ein Fallbeispiel: Das aufstrebende Unternehmen UrbanBioKontor liefert in großen Städten auf Bestellung Kisten mit Bioagrarprodukten an Endverbraucher. Um die Attraktivität des Angebots zu erhöhen, sollen künftig auch sehr kleine regionale Erzeuger ihre Produkte anbieten können – vom privaten Hühnerhalter bis zum Urban Gardener. Statt eines offiziellen Bio-Labels wird für diese Erzeuger ein eigenes Bio-Label des Unternehmens diskutiert. Die Produkte sehr kleiner Erzeuger sind oft von außergewöhnlicher Qualität und bei Kunden daher besonders beliebt.

Paulinas Aufgabe

Das Unternehmen hat über die Jahre eine komplexe Softwarelandschaft aufgebaut, die den Ansprüchen mittlerweile nicht mehr genügt. Das monolithische Kernsystem ist über die Jahre zu einem Big Ball of Mud (BBoM, ein stark verflochtenes und daher schwer zu verstehendes und zu veränderndes System, ein Antipattern des Domain-Driven Design) erodiert und von kleinen Satellitensystemen umgeben. Für Zahlung, Buchhaltung und Mahnwesen wird eine Standardsoftware als Service genutzt. Das strategische Ziel des Unternehmens, auch kleine Erzeuger einzubinden, wird durch die schlechte Anpassbarkeit der Softwarelandschaft ausgebremst.

Das Management hat daher entschieden, die bestehende Softwarelandschaft umfassend zu modernisieren. Ziel ist eine moderne Cloud-basierte Lösung aus lose gekoppelten, eigenständigen Systemen, die nach den Prinzipien des Domain-Driven Design (DDD) aufgebaut werden soll. Einige Teile der bestehenden Software sollen weiter genutzt und auch Software hinzugekauft, statt selbst entwickelt werden. Das Modernisierungsprojekt soll innerhalb der nächsten zwei Jahre schrittweise umgesetzt werden, ohne dass das Tagesgeschäft darunter leidet.

In den verschiedenen Abteilungen und Filialen des Unternehmens gibt es zahlreiche Fachexpert:innen, von denen die wenigsten IT-Projekterfahrung besitzen. Die IT-Teams sind derzeit nur mit der bestehenden Softwarelandschaft beschäftigt. Einige Entwickler sollen das Projekt aber von Beginn an begleiten und beim Aufbau der Projektteams unterstützen.

Das ganze Unternehmen und insbesondere die Projektverantwortliche Paulina stehen vor einer riesigen Aufgabe und viele Fragen sind noch völlig ungeklärt: Wo fangen wir überhaupt an? Wie bekommen wir all die Leute dazu, an einem Strang zu ziehen? Wie vermeiden wir Fehlentwicklungen? Wie können wir schnell relevante Ergebnisse erzielen? Paulina möchte mit einem Scenario Casting beginnen – und wir begleiten sie dabei.

Sie hat damit schon in anderen Projekten gute Erfahrungen gemacht und weiß, dass Scenario Casting konkrete Antworten auf die obigen Fragen liefert. Zudem schafft es eine gemeinsame Basis für Menschen, die sonst wenig miteinander zu tun haben – aber im neuen Projekt auf einmal sehr viel.

Was ist ein Szenario?

Ein Szenario beschreibt eine beispielhafte fachliche Situation und ihre schrittweise Veränderung durch fachliche Ereignisse, z. B. durch zweckgerichtete Aktionen von Akteuren. Es steht repräsentativ für eine Vielzahl von ähnlichen Prozessen und bietet eine reichhaltige Grundlage für das Problemverständnis, das Lösungsdesign und die spätere Abnahme der Lösung. Ein Szenario ist immer

• realistisch – es könnte sich exakt so zutragen (im Soll ggf. erst in der Zukunft),

• zusammenhängend und schlüssig, ohne logische Lücken und Sprünge,

• konkret und detailliert – je konkreter, desto anschaulicher und damit nützlicher für das Problemverständnis (andere Details = anderes Szenario).

Akteure können in Szenarien sehr gut durch sog. Personas plastisch dargestellt werden. Ein gutes Szenario liefert immer einen konkreten, überschaubaren Kontext, in dem ein Problem – durchaus auch von Laien – verstanden werden kann.

Das szenariobasierte Vorgehen verwendet Szenarien, um Anforderungen zu identifizieren, Designentscheidungen zu treffen und Testszenarien zu entwickeln. Grundidee ist dabei, dass Szenarien mehr aussagen als abstrakte oder technische Dokumente. Durch moderne szenariobasierte Methoden werden die Interaktion der Projektbeteiligten und der konstruktive Diskurs gefördert, um ein gemeinsames Verständnis der durch Software zu lösenden Probleme erlangen.

Szenariobasiert ist es möglich, mit dem Lösungsdesign im kleinen Rahmen eines Szenarios anzufangen. So kann für Prozesse, die dem Szenario entsprechen, eine sinnvolle und angemessene Lösung entstehen. Die Lösung wird auf Basis weiterer Szenarien später generalisiert oder erweitert werden – aber sie ist grundsätzlich nicht falsch, denn die im Szenario identifizierten Pro-bleme sind real.

Szenariobasiert bewegen wir uns im Problemraum damit immer auf festem Boden, auch wenn wir den Problemraum noch gar nicht vollständig kennen. Das ermöglicht sehr kleine nutzbringende Ausbaustufen, deren Analyseaufwand sich auf einzelne Szenarien beschränken kann. Lösungsideen, die in unbekannte Teile des Problemraums hineinreichen, bergen dagegen immer das Risiko, ihren Zweck zu verfehlen.

Die erste Iteration – Paulinas Projektstart

Paulina möchte den Kick-off-Termin des Projekts nutzen, um nicht nur die Projektziele vorzustellen und die Projektbeteiligten zusammenzubringen, sondern direkt mit der gemeinsamen Arbeit zu starten. Sie hat vor Ort in die Zentrale des Unternehmens eingeladen, damit die Projektbeteiligten Gelegenheit haben, sich persönlich kennenzulernen. Später werden die Workshops online durchgeführt, da das Unternehmen auf viele Städte verteilt ist und viele Entwickler:innen aus dem Homeoffice arbeiten.

Mehrere Fachexpert:innen hatten Paulina vorgeschlagen, ihre Ideen für die neue Software beim dem Kick-off vorzustellen. Und auch aus der IT sind konkrete Anliegen an Paulina herangetragen worden. Schwer, das alles unter einen Hut zu bekommen! Paulina meinte nur, dass nichts vorzubereiten sei – die langjährige Praxiserfahrung aller Projektbeteiligten sei Vorbereitung genug.

Zum Kick-off sind fast alle Projektbeteiligten anwesend. Zwei Fachexperten aus dem Einkauf mussten leider kurzfristig absagen. Aber das Management ist da und beginnt den Kick-off-Termin mit einer Übersicht über die Projektziele und den Zeitplan.

Dann übernimmt Paulina und erläutert zunächst das generelle Vorgehen im Projekt. Wichtig ist ihr, dass die Projektbeteiligten verstehen, dass das Projekt in Ausbaustufen umgesetzt werden soll, immer mit dem Ziel, Ausbaustufen möglichst zeitnah live zu schalten und zu nutzen. „Jede Ausbaustufe soll einen fachlichen Mehrwert liefern“, betont sie. „So können wir erkennen, ob wir uns in dem langen Projekt schrittweise in die richtige Richtung bewegen. Es ist also wichtig, dass wir uns fokussieren und einen fachlichen Mehrwert für die nächste Ausbaustufe identifizieren. Dazu müssen wir uns gemeinsam umschauen und eine Strategie entwickeln, wie wir unsere bestehende Softwarelandschaft schrittweise modernisieren.“

Scenario Casting – Agilität beginnt im Problemraum

Im Kontext von DDD wird zwischen Problem- und Lösungsraum unterschieden: Der Problemraum umfasst das Verständnis der Fachdomäne, ihre Regeln und Zusammenhänge sowie ihre geschäftlichen Herausforderungen. Der Lösungsraum beinhaltet dagegen alle Aspekte der konkreten Lösung, vom UX-Design über die technische Architektur bis zur Umsetzung im Code – aber auch Lösungsaspekte außerhalb der Software (z. B. Postversand).

Gutes Design im Lösungsraum beginnt bereits im Problemraum. Design Thinking [1] unterscheidet zwei Phasen der Orientierung: Das Sammeln von Ideen (Divergieren) und das Fokussieren auf bestimmte Ideen (Konvergieren). Auf Problem- und Lösungsraum übertragen ergibt sich daraus ein Bild, das als „Double Diamond“ bekannt ist, und im Problemraum die Frage nach dem richtigen Problem und im Lösungsraum nach der richtigen Lösung stellt (Abb. 1).

Abb. 1: Das Double-Diamond-Designmodell

Das Verständnis des Problemraums beeinflusst nach DDD direkt die Gestaltung des Lösungsraums: Das Modell, das wir uns vom Problemraum machen, übertragen wir – vereinfacht gesagt – als softwaretechnisches Modell in den Lösungsraum. Konkret kann das beispielsweise heißen: Subdomänen werden zu Systemen oder Modulen und Fachsprache zu Code (in der technischen Umsetzung existieren sehr unterschiedliche Auslegungen von DDD, die hier nicht das Thema sein sollen).

Mit Hilfe des Scenario Casting (Kasten: „Methodensteckbrief ‚Scenario Casting‘“) erforschen wir den Problemraum schrittweise – Orientierungsszenario für Orientierungsszenario – und bauen dazu parallel in Ausbaustufen eine Lösung, die die Prozesse perfekt unterstützt, für die die Orientierungsszenarien repräsentativ stehen.

Dabei geht es vor allem darum, die architektonischen Strukturen im Großen wie im Kleinen anhand repräsentativer Details aufzubauen. Diese werden später ausgestaltet, sobald die Domäne im Wesentlichen einmal durchdrungen und verstanden wurde. In unserem Beispiel also: Wenn Paulinas Team es schafft, die Auslieferung von Gemüsekisten durch Software zu unterstützen, dann ist das Ausliefern von Obst- und vegetarischen Kisten fast ein Selbstgänger und das Ausliefern von Kisten mit zu kühlenden Produkten kann auf einer soliden Basis aufgebaut werden.

Das Orientierungsszenario ist dabei der Dreh- und Angelpunkt. Es setzt den Fokus für die Entwicklung der nächsten Ausbaustufe, die in agilen Teams eigenständig in mehreren Sprints umgesetzt wird. Es stellt zudem sicher, dass alle Teams inhaltlich an einem Strang ziehen.

Ausgehend von der Projektidee beginnt das Scenario Casting divergierend: Die Beteiligten brainstormen fachliche Beispiele zu allen Punkten, die ihnen im Projekt am Herzen liegen, und erstellen daraus ein umfassendes Scenario Backlog. Anschließend konvergiert das Scenario Casting schrittweise durch Clustern, Priorisieren und Zusammenfügen der Beispiele, bis am Ende ein oder mehrere Orientierungsszenarien stehen (Abb. 2).

Abb. 2: Ein Scenario-Casting-Zyklus aus zwei Diamanten

Ein Orientierungsszenario ist Start- und Endpunkt für die Lösungsentwicklung. Ergebnis der Lösungsentwicklung ist eine weitere Ausbaustufe unserer Software, die wir integrativ testen, wobei das Orientierungsszenario als ein umfassender Akzeptanztest fungiert und sicherstellt, dass die Inkremente der beteiligten Teams zusammenpassen. Die Produkte der Teams können aus fachlicher Sicht anschließend (sofern möglich und gewünscht) releast werden.

Damit beginnt der nächste iterativ-inkrementelle Zyklus und wir steigen in die Entwicklung der nächsten Ausbaustufe erneut mit einem Scenario Casting ein.

Agiles Vorgehen in großen Projekten

Einige Ansätze versuchen, agiles Vorgehen zu skalieren, indem sie typisch agile Teamaufgaben [8] teamübergreifend durchführen. Dadurch drohen ursprünglich leichtgewichtige Praktiken, wie z. B. das Verteilen von Aufgaben, sehr schwerfällig zu werden, und das Vorgehen fühlt sich für die Teams dann nicht mehr agil an.

Das szenariobasierte Vorgehen bietet dagegen die Chance, zusammenhängende Fachprozesse zu entflechten und auf einzelne Szenarien (die eine ganze Reihe von ähnlichen Prozessen repräsentieren) zu schauen. Scenario Casting nutzt diese Möglichkeit und führt die Teams mit Hilfe von Orientierungsszenarien schrittweise durch den Problemraum. Dabei gilt:

• Es werden keine Lösungsideen oder Features teamübergreifend vorgegeben! Die Lösungsfindung findet eigenständig in den Teams statt.

• Es werden keine Arbeiten teamübergreifend koordiniert! Die Teams koordinieren sich eigenverantwortlich mit anderen Teams vor dem Hintergrund der Orientierungsszenarien.

• Es werden keine Schätzungen von den Teams verlangt! Die (agile) Planung nimmt jedes Team nach eigenem Ermessen vor.

Wenn wir nach DDD die Fachdomäne in unabhängige Subdomänen unterteilen und das als Grundlage für den Teamschnitt nehmen, können die Abhängigkeiten zwischen den Teams und ihren Produkten minimal gehalten werden. In Kombination mit dem Scenario Casting können sich die Teams so in ihrer Subdomäne auf ein Orientierungsszenario fokussieren und im kleinen, sicheren Rahmen klassisch agil vorgehen – und trotzdem ziehen sie im Großen durch das gemeinsame Orientierungsszenario an einem Strang.

Schritt 1: Paulina lässt brainstormen

Paulina erklärt nun das Vorgehen: „Ich weiß, ihr habt alle ganz unterschiedliche Fragen, Ideen und Anliegen in diesem Projekt. Diese Punkte wollen wir heute einsammeln. Stellt euch dazu die folgende Frage: ‚In welcher fachlichen Situation kommt mein Punkt zum Tragen?‘ Überlegt euch dazu ein konkretes Beispiel und notiert es auf einem gelben Klebezettel. Jedes Beispiel ist für uns ein Merker, damit wir euren Punkt im Projekt nicht vergessen.“

Paulina macht das einmal vor: „Wenn ein neuer Auftrag reinkommt, muss ich die Daten momentan in vier unterschiedlichen Systemen erfassen. In der neuen Software muss es genügen, sie einmal einzugeben. Das ist mir wichtig! Vielleicht kann der Kunde den Auftrag sogar selbst digital erfassen. Ich notiere also folgende konkrete Beispielsituation (Abb. 3): ‚Familie Schulz bestellt eine kleine Gemüsekiste für das Wochenende‘. Das sollte als Merker reichen, damit wir uns im Projekt um eine verbesserte Auftragserfassung Gedanken machen.“

Abb. 3: Der Weg zum ersten Klebezettel mit einem plastischen fachlichen Beispiel

„Warum schreiben wir nicht einfach den Punkt ‚Auftragserfassung‘ auf den Klebezettel?“, fragt ein Fachexperte. „Weil uns dann der fachliche Rahmen fehlt. Auftragserfassung umfasst ja viel mehr als nur das Erfassen eines einzelnen kleinen Auftrags, der mir aber für meinen Punkt genügt – ich will halt nicht mehr, aber auch nicht weniger als mein Beispiel betrachten.“

Einer Fachexpertin fällt ein: „Es kommt ja oft vor, dass Kunden alte Aufträge ein weiteres Mal erteilen. Das wäre gleich der nächste Klebezettel: ‚Familie Schulz bestellt die Gemüsekiste vom letzten Wochenende auch für das nächste‘.“ – „Aber diesen erneuten Auftrag kann man ja trotzdem noch verändern!“, wendet der erste Fachexperte ein. „Stimmt, also ergänzen wir ‚… und fügt noch einen Liter Milch hinzu‘, dann haben wir Kühlprodukte gleich auch noch mit drin. Bei denen müssen wir nämlich eine genaue Lieferzeit erfassen, damit sie persönlich entgegengenommen werden können. Also schreibe ich weiter: ‚… und gibt als Lieferzeit Samstag, 9-10 Uhr an.‘“ – „Das sollten wir nicht mehr so machen“, bemerkt der Fachexperte, „denn das schaffen unsere Fahrer kaum. Lasst uns einfach ‚vormittags‘ sagen.“ – „Aber wenn die Familie ab 10 nicht mehr zuhause ist?“ Eine Lösung fällt niemandem auf die Schnelle ein, aber das fachliche Problem liegt in dem Beispiel auf der Hand. Am Ende lautet der Klebezettel nun: „Familie Schulz bestellt die Gemüsekiste vom letzten Wochenende auch für den kommenden Samstag und fügt noch einen Liter Milch hinzu, kann die Kiste aber nur bis 10 Uhr zuhause annehmen.“

„Da fallen mir gleich noch ein paar schöne Aufträge ein, z. B. Selbstabholer“ grinst eine Fachexpertin. Das ist für Paulina das Zeichen, dass die Gruppe das Prinzip verstanden hat. Nun dürfen alle ihre eigenen Klebezettel schreiben. „Spart nicht mit Details. Es gibt kein ‚zu konkret‘!“, ruft Paulina. „Jedes Detail kann ein guter Hinweis sein, um die Fachdomäne besser zu verstehen!“ Und: „Schreibt bitte euren Namen oder euren Initialen oben auf die Klebezettel, damit wir euch ggf. Rückfragen stellen können, wenn wir mit den Zetteln arbeiten.“

In nur wenigen Minuten füllt sich der Bereich um Paulinas zwei Beispielklebezettel mit vielen weiteren Beispielen (Kasten: „Tipps zum Brainstormen“).

Stakeholder Sinan schreibt: „Die neue Software muss kundenorientiert sein!“ Das ist Paulina zu allgemein und sie fragt nach einem konkreten Beispiel, in der Kundenorientierung zum Tragen kommt. „Oh, da gibt es viele“, sagt Sinan, „zum Beispiel soll auch übers Handy bestellt werden können.“ Das wiederum ist Paulina zu sehr in Lösungen gedacht. „In welcher Situation ist die Bestellung übers Handy denn wichtig?“, fragt sie. „Na, zum Beispiel, wenn ich beim Blick in den Kühlschrank feststelle, dass der dringend wieder aufgefüllt werden muss. Da renne ich doch nicht zum PC!“ – „Perfekt, das ist doch ein sehr plastisches Beispiel!“, sagt Paulina und schlägt vor, das auf dem Klebezettel zu notieren. Sinan fallen daraufhin noch viele konkrete Beispiele ein (Abb. 4).

Abb. 4: Frisch gebrainstormte, noch ungeclusterte fachliche Beispiele

Nach einer halben Stunde werden nur noch wenige neue Klebezettel geschrieben. Das ist für Paulina das Zeichen, zur nächsten Phase überzugehen: „Lest euch die Klebezettel der anderen durch. Falls einer eurer Klebezettel inhaltlich dazu passt, nehmt euren Klebezettel und hängt ihn zu den anderen. Dadurch entstehen inhaltliche Cluster.“

Tatsächlich werden die ersten Klebezettel umgehängt und die ersten Cluster (Abb. 5) entstehen wie von selbst. Paulina hilft dabei, die Custer räumlich voneinander abzugrenzen und klebt grüne Zettel an die Cluster. „Schreibt auf die grünen Zettelchen das Thema des Clusters. Das erleichtert das Clustern“ sagt sie. Ein Entwickler merkt an, dass sich die Cluster inhaltlich überlappen und einige Klebezettel in mehrere Cluster passen. Paulina kennt das Problem, weiß aber, dass Perfektion zu Beginn schwierig ist und die Clusterung mit jedem Scenario Casting besser werden wird. Daher sagt sie: „Hängt die Klebezettel einfach in die Cluster, in die sie nach eurer Meinung am besten passen. Das muss jetzt nicht auf Anhieb perfekt sein.“

Abb. 5: Inhaltlich geclustertes Scenario Backlog

Nach kurzer Zeit sind alle gelben Klebezettel einem Cluster zugeordnet. Über einige Zuordnungen wurde etwas mehr diskutiert, über andere gar nicht. Paulina geht nun die Cluster mit allen durch, jedoch ohne genauer auf die einzelnen gelben Klebezettel zu schauen – dafür sind es einfach zu viele.

„Sind die Cluster soweit erwartungskonform? Fehlt etwas Wichtiges?“, fragt sie. Es werden noch ein paar Zettel umgehängt – aber im Wesentlichen ist die Gruppe mit dem Ergebnis zufrieden. Es sind fast 100 Beispiele zusammengekommen und zu zwölf Clustern zusammengefasst worden. Einige Cluster sind sehr groß, andere umfassen nur ein bis zwei Beispiele. „Man ahnt schon, wo der Hase im Pfeffer liegt“, sagt Paulina und zeigt auf den größten Cluster.

Sie erklärt: „Das Ganze hier nennen wir Scenario Backlog. Um all diese Themen hier werden wir uns kümmern!“ Damit beendet Paulina das Kick-off-Meeting. Es hat gut zwei Stunden gedauert.

Was haben wir beim Brainstormen erreicht?

Wir haben

• die unterschiedlichsten Fragen, Ideen und Anliegen der Beteiligten über konkrete Beispiele in der Fachlichkeit verortet und so zueinander „kompatibel“ gemacht.

• ein erstes Scenario Backlog zusammengestellt mit fachlichen Beispielen, die aus Sicht der Projektbeteiligten zu betrachten sind.

• erste thematische Cluster innerhalb der Fachdomäne gebildet (die thematischen Cluster entsprechen im ersten Schritt praktisch nie den Subdomänen, die später identifiziert werden!).

• einen ersten Eindruck zu Umfang und Komplexität der einzelnen thematischen Cluster gewonnen.

Schritt 2: Paulina priorisiert

Gleich in der nächsten Woche findet schon der zweite Workshop statt. Dann sind auch die Kolleg:innen aus dem Einkauf dabei. Sie haben während der Woche ihre Klebezettel ergänzt und sogar einen weiteren Cluster hinzugefügt.

Paulina eröffnet den zweiten Workshop. Ober- und unterhalb des Bereichs mit den geclusterten Beispielen hat sie zwei neue Bereiche durch eine Linie abgegrenzt: Der Bereich oberhalb heißt „Fokus“ und der Bereich unterhalb „Out of Scope“ (oder „Außerhalb der Betrachtung“, Kasten: „Tipps zum Priorisieren“).

Paulina erklärt: „Heute werden wir unser Scenario Backlog grob priorisieren und uns auf einige wenige Beispiele fokussieren. Das tun wir, indem ihr Klebezettel, um die wir uns eurer Meinung nach jetzt sofort kümmern sollten, in den oberen Bereich hängt, und Klebezettel, die aus eurer Sicht ungültig, irrelevant oder außerhalb unseres Projekts sind, nach unten. Alle übrigen lasst ihr einfach hängen.“ Paulina betont, dass die Beteiligten auf eigene Faust entscheiden können. „Es gibt nur eine Regel: Wenn ihr findet, dass ein Klebezettel von jemand anderem falsch gehängt wurde, meldet euch zu Wort und wir diskutieren das.“

Da Paulina weiß, dass tendenziell die meisten Klebezettel nach oben wandern, hat sie den oberen Bereich deutlich kleiner gezeichnet und sie ergänzt: „Hängt die Klebezettel bitte nur dann in den oberen Bereich, wenn es aus eurer Sicht unabdingbar ist, dass wir sie jetzt betrachten.“

Ein Fachexperte hängt einige Sonderfälle nach oben und erntet sofort Widerspruch: „Lasst uns doch erstmal auf die Standardfälle schauen!“ Paulina schlägt vor, wie bei einer „Sightseeing-Tour durch die Fachdomäne“ den Fokus erstmal auf die repräsentativsten Beispiele zu legen, um so eine grobe Übersicht zu bekommen. Die Teilnehmer:innen finden das eine gute Idee und beginnen, passende Beispiele auszuwählen.

Dabei fällt auf, dass es bei zu kühlenden Produkten viele Sonderfälle gibt. Die Fachexpert:innen einigen sich darauf, diese auszulassen. „Das ist ein eigenes, größeres Thema“. Paulina hält auf einem Klebezettel für die Priorisierung fest: „Prämisse: Keine zu kühlenden Produkte“. Prämissen müssen regelmäßig auf ihre Gültigkeit überprüft werden.

Ein Fachexperte zeigt auf ein Beispiel und fragt, wozu denn z. B. Produkte wie Käse und Wurst zählen, die zwar nicht durchgehend gekühlt werden müssen, aber länger frisch bleiben, wenn sie gekühlt werden. Die Fach-experten sind unsicher und halten das auf einem roten Klebezettel fest (analog zu den Hotspot-Klebezetteln des Event Stormings), den sie an das Beispiel hängen: „Käse/Wurst immer kühlen?“

Abb. 6: Priorisiertes Scenario Backlog

Am Ende hängt ein gutes Dutzend Klebezettel im Fokusbereich (Abb. 6). Das Cluster „Bio-Label für private Erzeuger“ ist komplett in den Out-of-Scope-Bereich geschoben worden. Das Thema ist zu groß und muss auch nicht im Rahmen des Projekts vorangetrieben werden. Auch der Cluster „Erzeugerverträge“ wurde rausgenommen, da die Verträge weiterhin mit der bestehenden Software verwaltet werden sollen – das war den meisten Teilnehmer:innen gar nicht klar. „Gut, dass wir darüber gesprochen haben“, sagt Paulina. Auch zwei ungültige Beispiele, die so nicht vorkommen können, sind herausgenommen worden und haben für Aha-Erlebnisse bei zwei Entwicklern gesorgt.

Was haben wir beim Priorisieren erreicht?

Wir haben

• eine erste Strategie entwickelt, wie wir das Projekt/den nächsten Projektabschnitt beginnen wollen.

• erste Fragen zur Fachlichkeit identifiziert und festgehalten.

• den fachlichen Umfang (Scope) des Projekts geklärt.

• einen Fokus auf die jetzt wichtigsten fachlichen Beispiele im Scenario Backlog gesetzt.

Schritt 3: Zusammenfügen (aka „Fischgräting“)

Paulina freut sich über das Ergebnis und geht mit den Teilnehmer:innen die einzelnen Klebezettel im Fokusbereich durch. Ein Klebezettel wird wieder zurück ins Scenario Backlog geschoben, da er doch nicht mehr so wichtig erscheint. „Das sind ganz schön viele Beispiele“, merkt einer der Entwickler an, „hängen die nicht irgendwie zusammen?“ – „Doch, das tun sie“, antwortet Paulina, „und deswegen fügen wir sie nun zu längeren Geschichten zusammen.“

Abb. 7: Visuelle Legende der Klebezettel im Scenario Casting

Paulina nimmt die Klebezettel aus dem Fokusbereich und verteilt sie oberhalb eines Zeitstrahls von links nach rechts (Abb. 8). Der Zeitstrahl dient der Orientierung, in welcher zeitlichen Reihenfolge die Beispiele aufeinander folgen können. „Wichtig ist, dass die Geschichte, die wir hier zusammenfügen, plausibel ist!“, hebt Paulina hervor (Kasten: „Tipps zum Zusammenfügen“), denn natürlich lassen sich einige Beispiele in unterschiedlicher Reihenfolge hintereinanderstellen.

Abb. 8: Ungeordnete fachliche Beispiele über Zeitstrahl

„Was wäre denn ein guter Startpunkt?“, fragt Paulina. Eine Fachexpertin sagt: „Hier, dieser Zettel: ‚Der private Erzeuger Meyer bietet zum Wochenende 20-25 frische Eier an‘“. Die Fachexpertin hängt ihn vorne auf den Zeitstrahl. „‚Familie Schulz bestellt eine kleine Gemüsekiste für das Wochenende‘ wäre auch ein guter Startpunkt“, merkt ein Fachexperte an und hängt den Zettel weiter nach hinten auf den Zeitstrahl. Weitere Zettel, auf denen beschrieben wird, wie eine Kiste zusammengestellt, zum Kunden gefahren und abgegeben wird, werden lose dazu gehängt, ebenso weitere Zettel, auf denen für den Erzeuger ein Preis kalkuliert wird, den er annimmt, etc. Schließlich gruppieren sich alle Zettel in drei losen Wolken um den Zeitstrahl (Abb. 9).

Paulina fragt, worum es in diesen Wolken jeweils geht. „Die erste Wolke ist ‚Privater Erzeuger bietet Produkte an‘, die zweite ‚Familie bestellt Kiste‘ und die dritte ‚Tagesabschluss‘“, schlägt eine Fachexpertin vor.

Abb. 9: Zu losen Wolken zusammengezogene Beispiele am Zeitstrahl

„Gehen wir nun diese Wolken einmal durch“, schlägt Paulina vor. „Ziel ist, aus den unterschiedlichen Beispielen eine schlüssige Geschichte zu formen“. Zwei Fachexpertinnen beginnen, die Beispiele der zweiten Wolke hintereinander zu fügen. Eine der beiden überlegt laut: „Familie Schulz könnte statt einer Gemüsekiste eine vegetarische Kiste bestellen, dann können dort auch die Eier rein, die Erzeuger Meyer angeboten hat.“ – „Das Beispiel von Familie Becker, die Käse und Eier bestellt hat, kann dann raus, oder?“ – „Ja, die tierischen Produkte haben wir mit der vegetarischen Kiste mit abgedeckt.“ – „Aber Milchprodukte sind doch interessant, weil die immer separat bestellt werden und in der vegetarischen Kiste nicht mit drin sind.“ Am Ende lautet das Beispiel: „Familie Schulz bestellt eine kleine vegetarische Kiste und 200 g Wildkräuterkäse für das Wochenende.“

Auch die übrigen Beispiele wurden in den ersten beiden Wolken angeglichen und in eine endgültige Reihenfolge gebracht. Auf diese Weise sind aus den losen Wolken zwei kleine Geschichten entstanden (Abb. 10). Die dritte Wolke „Tagesabschluss“ bleibt ungeordnet, da die Teilnehmer:innen das Thema im Vergleich zu den anderen beiden Geschichten gar nicht mehr so spannend finden – Paulina schiebt sie später im Ganzen ins Scenario Backlog zurück.

Abb. 10: Zwei zusammengefügte Geschichten („Fischgräten“) und eine Wolke

Paulina erklärt: „Prima! Wir haben zwei Geschichten gefunden, in denen die wichtigsten Standardfälle vorkommen. An denen können wir uns nun im weiteren Verlauf des Projekts orientieren. Daher nennen wir sie auch Orientierungsszenarien.“ Paulina schmunzelt: „Die meisten sagen allerdings ‚Fischgräten‘, weil sie sich fischgrätenähnlich vom Zeitstrahl abzweigen – der Begriff ist nicht mehr wegzubekommen!“ – „Wollen wir die zweite Fischgräte nicht in Bestellung und Lieferung aufteilen?“, fragt eine Fachexpertin. Die anderen finden das gut, weil bei der Lieferung neue Akteure hinzukommen. „Und Angebot und Bestellung können wir dann zusammenfügen“, schlägt dieselbe Fachexpertin vor, doch davon halten die anderen nichts. Es bleibt also bei drei Orientierungsszenarien und einer nur lose zusammengefügten Wolke (Anmerkung des Autors: Danke an Jan Crüsemann, der auf die Idee kam, Orientierungsszenarien auf einem verzweigten Zeitstrahl übersichtlich zu visualisieren).

Was haben wir beim Zusammenfügen erreicht?

Wir haben

• erste fachliche Zusammenhänge diskutiert und geklärt.

• alle jetzt wichtigen fachlichen Beispiele zu plausiblen Orientierungsszenarien zusammengefügt.

• damit den Fokus für die nächste Ausbaustufe gesetzt, in dem die Orientierungsszenarien von den Teams eigenverantwortlich zum Leben erweckt werden.

Geschichtenerzählen mit Paulina

Paulina gibt einen Ausblick auf die nächsten Schritte: „Nachdem wir nun drei zentrale Orientierungsszenarien skizziert haben, wollen wir diese genauer analysieren. Das machen wir in separaten Terminen, damit sich diejenigen ausklinken können, die das jeweilige Orientierungsszenario nicht betrifft – es muss also niemand Angst haben, etwas zu verpassen.“

In den nächsten Sprints sollen die Orientierungsszenarien zum Laufen gebracht werden. Erst danach wird ein nächstes Scenario Casting anstehen, um einen neuen Fokus für die darauffolgenden Sprints zu setzen.

Paulina ist jetzt vor allem wichtig, die Subdomänen zu identifizieren, die von den Orientierungsszenarien berührt werden. Sie möchte zügig Teams aufstellen, die sich um die einzelnen Subdomänen kümmern und Lösungen entwickeln können.

Die Beschreibung der Orientierungsszenarien fasst bisher nur die wichtigsten Aspekte zusammen, geht aber kaum ins Detail. Paulina weiß: Das ist zu wenig, um Subdomänen voneinander abgrenzen zu können oder in die agile Lösungsentwicklung einzusteigen. Daher möchte sie mit den Fachexpert:innen tiefer einsteigen und die Orientierungsszenarien auserzählen. Dazu verwendet Paulina vor allem zwei Methoden:

• Domain Storytelling beschreibt grafisch, wie Akteure in einem Szenario miteinander kommunizieren, Informationen und Arbeitsgegenstände austauschen bzw. damit arbeiten.

• Event Storming beschreibt auf orangefarbenen Klebezetteln von links nach rechts die fachlichen Ereignisse, die sich innerhalb eines Szenarios zugetragen haben.

Beide Methoden sind gleichermaßen geeignet, um die fachlichen Zusammenhänge in den Orientierungsszenarien besser zu verstehen, Subdomänen zu identifizieren und Product Backlogs zu füllen.

Zum Auserzählen des ersten Orientierungsszenarios hat Paulina zu einem weiteren Workshop eingeladen. Mit den Fachexpert:innen geht sie nun ins Detail und orientiert sich dabei an den Klebezetteln des Orientierungsszenarios (Kasten: „Tipps zum Auserzählen von Orientierungsszenarien“).

Beim Auserzählen stoßen die Fachexpert:innen immer wieder auf Situationen, in denen sich das Orientierungsszenario auch anders entwickeln könnte als skizziert. Paulina schlägt vor, diese alternativen Erzählstränge wie im Brainstorming auf gelben Klebezetteln festzuhalten und in einem Bereich neben dem auserzählten Orientierungsszenario zu sammeln. „Das kommt alles in unser Scenario Backlog!“, erklärt Paulina. „Wir analysieren das, sobald es in einem der nächsten Scenario Castings hoch priorisiert wird“. Auf diese Weise gelingen den Fachexpert:innen zwei Dinge: (1) eine spannende, sinnvoll zusammenhängende Geschichte zu erzählen und (2) das Scenario Backlog um weitere fachliche Beispiele zu ergänzen, mit denen sie sich später befassen wollen.

Die Entwickler:innen finden die Geschichte in dieser plastischen und detaillierten Form sehr verständlich. Sie haben schon erste Ideen, wie das Orientierungsszenario durch Software unterstützt werden könnte. Doch Paulina möchte erst wissen, welche Subdomänen an der Geschichte beteiligt sind, um die Teams entsprechend aufzubauen [9]. Sie erklärt: „Um unsere Fachdomäne in Subdomänen zu zerlegen, können wir unser Orientierungsszenario zunächst in Teilprozesse zerlegen. Jeder Teilprozess zielt auf ein bestimmtes Ergebnis ab. Und erst wenn diese Mission erfüllt wurde, sind andere Teilprozesse an der Reihe.“

Paulina geht mit der Gruppe das auserzählte Orientierungsszenario durch und fragt: „An welchen Stellen haben wir eine Mission erfüllt und damit einen Teilprozess im Orientierungsszenario dauerhaft abgeschlossen?“ Den Fachexpert:innen fällt es leicht, die Stellen zu benennen (Tatsächlich kennen Fachexpert:innen die zentralen Ergebnisse in ihren Prozessen zumeist sehr genau; diese Ergebnisse stoßen üblicherweise Teilprozesse in anderen Subdomänen an und eignen sich somit gut, um diese Subdomänen voneinander abzugrenzen und so zu identifizieren.)

Paulina grenzt die Teilprozesse durch Linien voneinander ab. An den Teilprozessen notiert sie auf grünen Klebezetteln, welche Mission in einem Teilprozess jeweils erfüllt wird (Abb. 11).

Abb. 11: Auserzähltes und in Teilprozesse aufgeteiltes Orientierungsszenario plus Scenario Backlog für neu entdeckte Szenarien

Die Entwickler:innen finden einige Missionen sehr ähnlich und vermuten, dass sie zur selben Subdomäne gehören, im Lieferszenario z. B. die Missionen „Bestimme nächsten Abholpunkt der Tour“ und „Bestimme nächsten Lieferpunkt der Tour“. Die Fachexpert:innen schlagen „Bestimme nächsten Zielpunkt der Tour“ als beide Teilprozesse umfassende Mission vor und „Tourkoordination“ als Namen für die Subdomäne. Nach und nach kristallisieren sich die Subdomänen heraus.

„Schön, wie am Ende nach den Workshops zum Scenario Casting und zum Auserzählen der Orientierungsszenarien auf einmal alles rauspurzelt, was wir für die Lösungsentwicklung benötigen“, freut sich einer der Entwickler. Ein anderer Entwickler ergänzt: „Ich bin zwar erst seit kurzem dabei, aber die Orientierungsszenarien habe ich gut verstehen können und auch, warum wir gerade auf diese den Fokus legen.“

Die Entwickler:innen des Projekts finden sich im Anschluss an die Workshops zu zwei Teams zusammen und teilen die Subdomänen unter sich auf. Sie sind nun bereit, in die Lösungsentwicklung einzusteigen. Paulina bringt das Ziel der nächsten Sprints auf den Punkt: „Lasst uns dafür sorgen, dass die Orientierungsszenarien Realität werden!“

Dafür ist immer noch viel zu tun – aber alle sind sich einig: Dieses Ziel fühlt sich nicht mehr nach einem unüberschaubar großen Projekt an, sondern nach einer Aufgabe, die man in einigen Sprints bewältigen kann.

Um nun die Product Backlogs zu füllen, schlägt Paulina vor, die auserzählten Orientierungsszenarien weiter in sinnvolle User Stories aufzusplitten: „Das Einfachste ist, dafür das auserzählte Orientierungsszenario in User Stories aufzuteilen. Der Abschnitt, auf den sich eine User Story bezieht, ist direkt der erste Akzeptanztest dafür.“ – „Da bietet sich wohl eine testgetriebene Umsetzung nach TDD oder BDD an“, überlegt eine Entwicklerin.

Nach jedem Sprint markiert Paulina die umgesetzten Teile in den auserzählten Orientierungsszenarien und kann so teamübergreifend den Fortschritt verfolgen. Auch die Fachexpert:innen freuen sich über diese Übersicht, da sie so einen guten Einblick haben, was in der Umsetzung geschieht.

Dabei bemerkt Paulina, dass die Umsetzung des Zahlungsteilprozesses offenbar länger braucht. Sie spricht mit dem betroffenen Team. Offenbar kann das Drittsystem, das die Zahlungen abwickelt, aus Lizenzgründen nicht ohne Weiteres eingebunden werden. Das Team hat sich als sehr einfach umzusetzende Notlösung überlegt, Zahlungen zunächst nur manuell per Rechnung abzuwickeln. Auch wenn das nicht dem auserzählten Orientierungsszenario entspricht, in dem per Lastschrift bezahlt wird, ließe sich so das Orientierungsszenario zeitnah im Ganzen testen. Paulina holt die Fachexpert:innen hinzu, die den Vorschlag gut finden.

Einen Sprint später hat Paulina sämtliche Orientierungsszenarien grün markiert. Nun kommt der spannende Moment, alle drei Orientierungsszenarios im Zusammenhang im Ganzen integrativ zu testen.

Da die beiden Teams genau auf diesen Test hin entwickelt und ihre Teile vorab schon mit Hilfe der Orientierungsszenarios getestet haben, treten keine größeren Probleme auf. Lediglich ein paar Kleinigkeiten müssen gefixt werden. Paulina hat das auch schon anders erlebt und freut sich, dass die Teams mit dem Orientierungsszenario einen konkret testbaren Beispielprozess und keine abstrakte Lösungsidee als Spezifikation zur Verfügung hatten [10], [11]. Die Tester:innen des Projekts überprüfen nun alternative Testszenarien, die sie von den Orientierungsszenarien abgeleitet haben.

Die zweite Iteration

Paulina ist erleichtert, dass die zweite Iteration bereits nach wenigen Sprints beginnen kann. Als sie das erste Mal Scenario Casting eingesetzt hatte, waren ihr die unterschiedlichen Scenario-Casting-Strategien noch nicht klar und sie hatte sich mit dem damaligen Team unbewusst für eine eine Backpacking-Strategie entschieden (Kasten: „Typische Scenario-Casting-Strategien“). Deren Ergebnisse waren zwar sehr aufschlussreich, aber viel zu reichhaltig, um sie in überschaubarer Zeit umzusetzen. Seitdem hat Paulina beim Scenario Casting immer im Blick, dass die zusammengefügten Orientierungsszenarien in kurzer Zeit zu bewältigen sind. In der ersten Iteration ist das schwierig abzuschätzen, da die Teams oft selbst nicht wissen, wie schnell sie sind und oft auch mehr bauen, als fürs Ausprobieren des ersten Orientierungsszenarios notwendig ist. Paulina beginnt die zweite Iteration damit, das Scenario Backlog zusammen mit einigen Fachexpert:innen aufzuräumen:

• Bereits erledigte Beispiele werden herausgenommen.

• Die restlichen Beispiele werden, soweit passend, nach den neu erkannten Subdomänen geclustert.

• Leere alte Cluster werden entfernt.

• Die beim Auserzählen neu entdeckten Szenarien werden in die Cluster einsortiert.

Nun lädt Paulina zum nächsten Scenario Casting ein, das diesmal online stattfinden soll. Paulina hat dazu das Scenario Backlog auf ein virtuelles Whiteboard übertragen.

Die Gruppe verzichtet auf das Brainstorming, denn das Scenario Backlog ist ja schon gut gefüllt und es liegt keine neue oder stark geänderte Fachlichkeit vor. Alle Beteiligten dürfen ohnehin jederzeit neue fachliche Beispiele ins Scenario Backlog aufnehmen.

In der ersten Iteration hatte sich gezeigt, dass die Einbindung der bestehenden Systeme in die neue Architektur schwierig ist, nicht nur die des Zahlungssystems. Paulina schlägt vor, nun die Tagestrip-Strategie anzuwenden und die erkannten Problemstellen durch kürzere Szenarien genauer zu beleuchten. Die Gruppe nimmt nun den Bestellprozess unter die Lupe, da unklar ist, ob und wie die Produkte der kleinen privaten Erzeuger in das Altsystem eingespielt werden können. Im Zahlungsprozess soll die Zahlung per Rechnung durchleuchtet werden, um die gewählte Notlösung auf eine solide Basis zu stellen.

Am Ende des diesmal deutlich kürzeren Scenario Castings stehen sieben kleine, weitgehend parallele Orientierungsszenarien, die genau die Fachlichkeit der obigen Problemstellen beschreiben. Auch die neuen Orientierungsszenarien werden wieder auserzählt.

Und so setzt die Gruppe die gemeinsame Reise durch die Fachlichkeit des Projekts weiter fort.

Der weitere Projektverlauf

Orientierung fehlt in Projekten vor allem zu Beginn. Je weiter das Projekt voranschreitet, desto weniger (teamübergreifende) Orientierung wird naturgemäß benötigt. Scenario Casting wandelt sich daher im Projektverlauf: Orientierungsszenarien sind zu Beginn überblicksartig und werden mit der Zeit kürzer und betreffen weniger Teams. Es sind dann vor allem wenige benachbarte Teams, die Scenario Casting zur Ausgestaltung ihrer Schnittstellen nutzen, oder einzelne Teams zur Ausgestaltung des eigenen Produkts.

Gegen Ende des Projekts müssen oft nur noch punktuelle, d. h. sehr kurze, aber zahlreiche Szenarien betrachtet werden. Diese können direkt aus dem Szenario Backlog ausgewählt oder ad hoc gebrainstormt und auserzählt werden. Das „Fischgräting“ entfällt dann meist oder ist trivial.

Erst bei umfangreichen oder einschneidenden Änderungen der Fachlichkeit (z. B. durch Gesetzesänderungen) hilft Scenario Casting dann wieder in der größeren Runde.

Links & Literatur

[1] Lewrick, Michael; Link, Patrick; Leifer, Larry: „The Design Thinking Playbook“, Wiley, 2018

[2] Khononov, Vladislav: „Einführung in Domain-Driven Design“, O’Reilly, 2022

[3] Hofer, Stefan; Schwentner, Henning: „Domain Storytelling“, Addison Wesley 2022

[4] https://domainstorytelling.org

[5] Brandolini, Alberto: „Introducing EventStorming“; https://leanpub.com/introducing_eventstorming, 2021

[6] https://www.eventstorming.com

[7] https://scenario-casting.org

[8] Beck, Kent: „Extreme Programming Explained“, Addison-Wesley, 1999

[9] Skelton, Matthew; Pais, Manuel: „Team Topologies“, IT Revolution, 2019

[10] Adzic, Gojko: „Specification by Example“, Manning Publications, 2011

[11] Koch, Jörn; Middeke, Sebastian: „Effizientere agile Prozesse. Testfallbasierte Anforderungsdokumentation“, Objekt-Spektrum Themenspecial, 2015