This talk explains how Scenario Casting enables agile teams to pull together despite diverse ideas and concerns - in three iterative collaborative steps:
1. Find example scenarios of how ideas and concerns affect the domain - strictly in domain language! This provides an initial Scenario Backlog outlining the problem space.
2. Prioritize the Scenario Backlog and agree on scope.
3. Combine the top scenarios into coherent overarching Orientation Scenarios.

Let the agile teams focus on their parts of the Orientation Scenarios over the next iteration(s).

Target Audience: Stakeholders, Non-IT Domain Experts, BAs, Developers, Architects, QMs, Agilists
Prerequisites: Project experience, basic knowledge of DDD, basic knowledge of agile methods
Level: Advanced

Extended Abstract:
Scenario Casting is a collaborative planning and requirements engineering method that has emerged over the past four years in various Domain-Driven Design projects. It is used intensively with dozens of teams most of them involved in ambitious transformation projects.
Scenario Casting is especially helpful for getting a handle on complex or even overwhelming domains. If your domain feels like this and there are a lot of people involved too, you should give Scenario Casting a try.
Scenario Casting lays the groundwork for focused collaborative modeling sessions using domain storytelling or event storming. It ensures that all relevant points are addressed step by step. Also, it helps to quickly identify your domain's subdomains and determine the people who should be involved.

More relevant scenarios are discovered during collaborative modeling. They all go into the Scenario Backlog and will be considered in future Scenario Castings.
Unlike other concepts that try to scale agile, the Scenario Backlog is strictly limited to DDD's problem space, thus avoiding upfront design and premature planning.
Instead, Scenario Casting sets a common focus in problem space for agile teams by defining Orientation Scenarios. An Orientation Scenario illuminates parts of the problem space very precisely. It defines the actual results that solutions must deliver from a domain perspective - but without prescribing specific solutions. Finding and implementing good solutions remains the responsibility of the individual agile teams!

This talk contains examples from real projects and gives you best practices - so you get a good idea of how to try Scenario Casting yourself!

Funktionale Programmier:innen empfehlen meist "FP-first". Dieser puristische Ansatz passt leider nicht zu den Realitäten existierender Projekte, die objektorientiert auf DDD aufsetzen. Schade, weil diese Projekte von funktionalen Techniken profitieren können.
Der Vortrag beschreibt eine Kooperation zwischen Blume2000 (fest in OO-Hand) und der Active Group (alles FP-Puristen), um Probleme in einer hexagonalen DDD-Architektur (implementiert in Kotlin) mit funktionalen Techniken zu lösen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: OO-Grundkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dazu gehören:
- Validierung mit applikativen Funktoren
- freie Monaden, um die Domäne von den Ports zu trennen
- funktionale Dependency Injection, auch mit Monaden

Wir zeigen, wie wir's gemacht haben - und wie auch andere Projekte von funktionaler Programmierung profitieren können.
Das alles harmoniert wunderbar mit dem Kotlin/Spring-Boot-Kontext des Projekts.

Es gab aber durchaus auch Reibungspunkte: Die strikte Domänen-/Technik-Separierung des hexagonalen Modells hilft Entwickler:innen, sich zurechtzufinden - funktionale Programmierer:innen benutzen normalerweise feingranularere Abstraktionen im Rahmen der Functional-Core/Imperative-Shell-Architektur. Entsprechend präsentieren haben wir auch einige Vorschläge, wie Spring Boot verbessert werden könnte, um diesen Ansatz besser zu unterstützen.

Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.

Data Mesh überträgt die Prinzipien aus DDD, Team Topologies und Microservices auf die Datenwelt. Es hat aber auch weitreichende soziotechnische Auswirkungen, und lassen sich die zusätzlichen Aufgaben überhaupt mit dem Projektalltag vereinbaren?

In diesem Talk beschreibt Jochen Christ von INNOQ, wie eine Data Mesh-Architektur in der Praxis umgesetzt werden kann, welche organisatorischen Transformationen notwendig werden und welche Technologien sich dabei eignen.

Leider muss dieser Vortrag aus persönlichen Gründen kurzfristig abgesagt werden.

Die Twin Peaks sind ein Modell, dass die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Domain Storytelling hilft, das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement eines praxisnahen Anwendungsfalls. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Software-Architektur interaktiv vermittelt.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Agile Coach
Voraussetzungen: Projekterfahrung und Grundkenntnisse Domain-driven Design und Scrum
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Ersatzteil, Bestellung, Auftrag und Kunde. Alles klar, das kennen wir! Die im Planning gefühlte Klarheit endet, wenn Entwickler:innen bei der Implementierung von User Stories auf offene Fragen stoßen. Eine schnelle Klärung komplexer Fragen oder Annahmen seitens der Entwickler:innen führt oft nicht zum Erfolg.

Das Ergebnis: Die software-technische Realisierung deckt sich nicht mit den wirklichen fachlichen Anforderungen und es muss nachgearbeitet werden. In der Folge steigen Aufwand und Kosten. Das Projekt befindet sich in einer Abwärtsspirale aufgrund fehlenden Domänenwissens und einer daraus resultierender Softwarearchitektur, die die Domäne nicht unterstützen kann.

Die Twin Peaks sind ein Modell, das die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Die Abwärtsspirale wird durchbrochen, indem wir die Twin Peaks von der Spitze an, mithilfe von Domain Storytelling, hinabsteigen.

In diesem Talk stelle ich euch Domain Storytelling vor und wie diese Methode dabei hilft, das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement unseres Softwareprodukts. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Software-Architektur interaktiv vermittelt. Denn vermutlich liegt es nun an dir, die entscheidenden Impulse zur Verbesserung der Situation in deinem Projektkontext zu setzen.