Retrospektiven sind ein mächtiges Werkzeug, um Kollaboration in Teams zu fördern. Sie ermöglichen ihnen, im Plan-Do-Check-Act-Zyklus ihre Arbeitsweise strukturiert zu reflektieren, sie fördern Zusammenarbeit und die Lieferfähigkeit für Ergebnisse.

In manchen Teams werden Retrospektiven zwar halbwegs regelmäßig durchgeführt, sie haben jedoch ihre Strahlkraft eingebüßt. Hinter vorgehaltener Hand wird kritisiert, dass die wichtigen Themen nicht angesprochen, immer die gleichen Probleme diskutiert werden oder dass dem Moderator eine phantasievolle Methodenauswahl wichtiger scheint als echte Problemlösung.

In dieser Session wird mit einem Praxis-Theorie-Mix gezeigt, wie man die Ursachen für Zombie-Retrospektiven herausfindet, sie wiederbeleben und mit anderen Praktiken ergänzen kann.

Zielpublikum: Menschen, die Retrospektiven moderieren und/oder Impulse für ihr Team suchen
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

KI, Digitalisierung, Nachhaltigkeit … Es gibt immer neue strategische Herausforderungen zu bewältigen, und strategisches Alignment bleibt eines der kritischsten Erfolgskriterien.

Outcome-orientierte Strategiearbeit (z. B. Objectives und Key Results, OKRs) kann der Katalysator und eine transformative Kraft sein, um das strategische Alignment in Organisationen zu schaffen, das über vertikale und horizontale Dimensionen hinausgeht.

Die weit verbreitete Praxis der Kaskadierung bzw. das Kopieren von Organigrammen bei der Umsetzung der Strategie behindert allerdings oft den Fortschritt und die Motivation. Aber es gibt eine Alternative: „Das Solar System“ – ein innovatives Modell, das aus der Praxis heraus entwickelt wurde, um bereichsübergreifendes Alignment und Kollaboration zu stärken.

In diesem Vortrag tauchen wir in die Feinheiten des „Solar Systems“ ein und präsentieren verschiedene Team-Modelle wie Shared Teams und Dynamische Teams, die sich auf bestimmte strategische Outcomes konzentrieren. Praxisnahe Beispiele beleuchten die Anwendung dieser Modelle in der realen Welt.

Zielpublikum: Strategic Leadership, Product Leadership, Organisational Development, Decision Makers, Coaches
Voraussetzungen: Erste Erfahrungen mit Strategiearbeit, OKR, Team- und Organisationsentwicklung
Schwierigkeitsgrad: Advanced

Creating high-quality software is challenging due to a focus on solutions over understanding organizational context. Developers need to engage with stakeholders across contexts. However, stakeholder communication can lead to misunderstandings and conflicts, disrupting knowledge sharing. This often results in autocratic decisions by architects. Achieving sustainable and design decisions, it's more effective to employ visual techniques, improving collaboration with stakeholders.

This talk explores collaborative modeling, a technique for analyzing complex decisions with all stakeholders. Inclusive sessions and skills like observing, listening, neutrality, and empathy are key. The goal is for teams to understand stakeholder needs, guiding software architecture through collaborative design.

Target Audience: Technical leaders, decision makers, software engineers, architects
Prerequisites: None
Level: Advanced

Homeoffice, Remote-Arbeit, verteilte Teams – alles das sind heute gängige Arbeitsformen, die uns überall begegnen. Kann es nach der Team-Definition „Ein Team ist eine Gruppe von Menschen mit einem gemeinsamen Ziel, das sie nur durch Zusammenarbeit erreichen können“ das klassische Agile Team heute überhaupt noch geben? Womit haben wir es heute oft zu tun? Wir möchten dich in diesem interaktiven Vortrag auf unsere Erfahrungs- und Gedankenreise der Akzeptanz von Agilen Gruppen – und den damit geänderten Anforderungen an Führung – mitnehmen.

Agile Gruppen unterscheiden sich von Agilen Teams dadurch, dass eine enge Zusammenarbeit nicht stattfindet, sondern jede Person einen individuellen Beitrag leistet, der später ins Ganze eingefügt wird. Trotzdem ist agiles Arbeiten immer noch möglich.

Damit so eine Agile Gruppe erfolgreich sein kann, braucht sie allerdings bestimmte Rahmenbedingungen und Vorgehensweisen, die sich von jenen eines Teams zum Teil stark unterscheiden. Die Vorteile, Rahmenbedingungen – und natürlich auch mögliche Nachteile einer Agilen Gruppe – werden wir gemeinsam beleuchten. Dazu bekommst du einige lösungsfokussierte Techniken des Gruppencoachings an die Hand, um Agile Gruppen noch besser unterstützen zu können. Damit möchten wir eine spannende Diskussion anregen oder – wer weiß – vielleicht sogar motivieren, die Zwangsvorstellung, Agile Teams trotz stark veränderter Rahmenbedingungen um jeden Preis erhalten zu müssen, aufzugeben.

Zielpublikum: Scrum Master, Agile Coaches, Führungspersonen, Organisationsentwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Datenintensive Softwaresysteme, insbesondere Empfehlungssysteme, prägen zunehmend unseren Alltag. Damit diese Technologien der Menschheit dienen, müssen sie ethisch entwickelt und von den Werten ihrer Nutzer getragen werden. Ethische Prinzipien sind zwar wichtig, ihre praktische Anwendung gestaltet sich oft schwierig. Deshalb schlagen wir einen praxisorientierten, wertebasierten Ansatz vor. Das HYBRIDA-Framework unterstützt die Ideenfindungsprozesse und sorgt für verantwortungsbewusstes Design. Es konzentriert sich auf zwei Hauptaspekte: die Integration von Werten in Designprozesse und die Förderung interdisziplinärer Zusammenarbeit in datenintensiven Entwicklungsumgebungen. Das HYBRIDA-Framework unterstützt insbesondere die Ideenfindungsprozesse und besteht aus drei Phasen („Dive In“, „Tune In“, „Look Out“) für verantwortungsbewusstes Design, die die Ausrichtung von Team und Stakeholdern betonen.

In der ersten Phase werden die Werte des Teams und des Projekts identifiziert, beginnend mit einer Erkundung der Werte, die jede Person einbringt. In der nächsten Phase werden die Bedürfnisse, Motive und Werte der Stakeholder sowie der Nutzungskontext untersucht. Darauf basierend etabliert das Team Designprinzipien, die den Prozess leiten und als Ideen-Trigger fungieren. Das Team wird zudem herausgefordert, mögliche Probleme zu durchdenken und wie mögliche Dystopien verhindert werden können.

Der methodische Ansatz von HYBRIDA betont auch die kollaborativen Aspekte des Entwicklungsprozesses, indem hybride Werkzeuge und intensive Reflexion genutzt werden, um ein umfassendes Verständnis der ethischen Prinzipien zu fördern. Dieser interaktive Rahmen stärkt nicht nur die ethische Grundlage des Entwicklungsprozesses, sondern stellt auch sicher, dass vielfältige Perspektiven und Expertisen berücksichtigt werden, was zu robusteren und ethisch fundierten Softwarelösungen führt.

Zielpublikum: Produkt Owner, Projektleiter:innen, Entscheider:innen, Anforderungsingenieur:innen, UX-Designer
Voraussetzungen: Projekterfahrung, Produktkonzeption, Anforderungserhebung und -gestaltung, User-Centered Design
Schwierigkeitsgrad: Basic

Bounded Contexts spielen bei Domain-driven-Design-Diskussionen eine zentrale Rolle. Sie gelten als eine vielversprechende Lösung zur Modularisierung von Systemen, sei es in Form von Deployment-Monolithen oder Microservices. Doch die Anwendung in der Praxis bringt Herausforderungen mit sich: Es ist oft schwierig, eine Domäne sinnvoll in Bounded Contexts aufzuteilen. Zudem ist das Konzept nicht einfach zu verstehen. Einerseits steht es für die Aufteilung eines Softwaresystems in Module, andererseits soll es helfen, verschiedene Fachsprachen innerhalb einer Domäne voneinander zu trennen. Darüber hinaus wird ein Bounded Context oft als ein Team betrachtet. Wie lässt sich all das miteinander in Einklang bringen, und wie kann man in der Praxis erfolgreich damit arbeiten? Dieser Vortrag erklärt, was Bounded Contexts sind, und beleuchtet dann diese Herausforderungen. So zeigt er, wie man Projekte mit DDD noch erfolgreicher gestalten kann.

Zielpublikum: An Softwarearchitektur oder Domain-driven Design Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Schwierigkeitsgrad: Advanced

Die Grundlage für gute Software ist eine gute Architektur. Eine zum System passende Architektur kann jedoch nicht im luftleeren Raum entstehen – um eine geeignete Architektur definieren zu können, muss man die Domäne und ihre Anforderungen verstehen. Moderne Architekturarbeit beginnt somit ein ganzes Stück vor der eigentlichen Architektur. Für diese Exploration der Domäne wurden im Rahmen von Domain-Driven Design (DDD) verschiedene kollaborative Modellierungstechniken entwickelt. Deren Ziel ist es, dass alle an einer Software beteiligten Personen die Domäne und ihre Anforderungen kennen und verstehen. Insbesondere soll eine gemeinsame Sprache entwickelt werden, um über Problemstellungen innerhalb der Domäne diskutieren zu können, die auch als Ubiquitous Language im Sinne von DDD verwendet werden kann.

Obwohl all diese Modellierungstechniken dieselben Ziele verfolgen, unterscheiden sie sich in ihrem Ansatz. Das beliebte Event Storming modelliert Wissen als Sequenz von Events. Beim Domain Storytelling werden die Interaktionen zwischen Personen und/oder Systemen modelliert und die Ergebnisse können zur Visualisierung von Szenarien verwendet werden. Weitere Methoden verwenden andere Elemente in der Modellierung oder versuchen, die Stärken anderer Methoden zu kombinieren. In diesem Vortrag möchten wir einige beliebte Modellierungstechniken kurz vorstellen und ihre Stärken hervorheben. Wir möchten einige Ratschläge geben, wie man auf Basis des Szenarios eine kollaborative Modellierungstechnik auswählt.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Basic

Join us for an immersive exploration into the world of technical teams through engaging and educational simulations.
Understanding Technical Debt: Learn about technical debt from a non-technical perspective. Discover how it accumulates, impacts projects, and strategies to mitigate its effects.
Navigating Dependencies and Silos: Experience the tension of organizational silos by engaging in Testing Jenga.
The Power of Pair Programming: Discover the advantages of pair programming without writing code. Through team-based solving battles, see how collaboration enhances problem-solving and learning.
Prepare to think, play, and learn as we decode the secrets of successful technical teams using non-technical examples!

Target Audience: Developers, managers, non-developers who want to learn about these concepts
Prerequisites: None
Level: Advanced

So... in our organisation we've been busy trying to bridge the gap between Dev and Ops. And we've been moving towards an almost completely automated Infrastructure enablement. We thought we were doing so well. And then... it turned out that even without human intervention, IT infrastructure is secretly still about human interaction. I will tell you our real life story of how we hit rock bottom Developer Experience because as enablement teams we were so focused on IaC and automating everything that somehow we forgot to talk to our very own customers: the other teams in the organisation that are building software products. We thought we knew what they needed - because we were all developers ourselves too, innit. Well...-DevEx metrics showed us. Thankfully, this is a story with a happy ending too. We quickly retraced our steps and reverted to practical communication strategies to bridge the gap between us "software defined infrastructure product group" and the other teams.

Practical take-aways from this talk are some practices that can be applied straight away, to restore lost connections:

• Heard, seen, respected (learn to listen without showing any judgement)
• Finnish listening (remain silent! it allows conversations to evolve naturally. And we will practice some during the talk)
• Back-to-back (ha, that will be the mystery practice & exercise)

Target Audience: Architects, Developers, Managers, DevOps team members
Prerequisites: None
Level: Basic

In this constantly changing world, we face new challenges: rapidly changing customer needs, increasing competition, and a shortage of skilled workers. Agility and speed are essential. Adopting Platform Engineering can be key, providing the flexibility and scalability to adapt swiftly, outpace competitors, and bridge the skills gap through automation and optimization.

I will demonstrate, using a real Platform, how Platform Engineering can help companies overcome hurdles and scale issues with DevOps practices.

Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers, Platform Engineers, DevOps Engineers
Prerequisites: Basic DevOps knowledge, understanding of platform engineering concepts
Level: Advanced

„Verstehe ich nicht. Zeigst du das noch am Beispiel?“, „Das hast Du sehr vereinfacht erklärt. Hast du noch ein realitätsnahes Beispiel?“ Solche Aussagen sind oft die ersten Reaktionen auf die Vorstellung neuer Ideen. Denn leider fehlen oft gute Beispiele, um die Ideen (besser) zu verstehen. Obwohl wir selbst oft als Erstes nach einem guten Beispiel fragen, vergessen wir die Beispiele gerne bei unseren eigenen Präsentationen. Gute Beispiele bauen stabile Brücken über Verständnislücken und sind daher besonders wichtig, wenn Ideen außerhalb der eigenen Arbeitsgruppe präsentiert werden. Der Vortrag zeigt, warum „Lorem Ipsum“, „Max Mustermann“, „Unternehmen 1“ und „Produkt XYZ“ nicht ausreichen, um andere mitzureißen, und gibt konkrete Hilfestellungen, wie man richtig gute Beispiele gestaltet.

Zielpublikum: Für alle OOP-Teilnehmenden, denn alle müssen andere von ihren Ideen überzeugen
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

GAIA-X is a strategic initiative of the European Union in order to support secure and trustworthy dataspaces. But what does it mean to set up a GAIA-X compliant data space, polished powerpoint aside?
In this presentation we will report about our experiences learned from almost three years' work in one of the GAIA-X lighthouse projects "COOPERANTS". COOPERANTS is the world’s only collaborative alliance of industry, SMEs and research institutes in the Aeronautics and space sector that solves pressing digital collaboration problems by creating a common data space.
We will talk about experiences on how to navigate the confusing data-space ecosystems and tech-stacks and how and why we chose a specific solution (EDC vs. GXFS vs. Pontus-X, e.g.) and how we implemented the services.

Target Audience: Architects, CDO, Decisions Makers
Prerequisites: Knowledge in Data Management, IT Architecture
Level: Advanced

Architecture work can be tough: juggling tech stacks, new tools, facilitating decisions, working with different stakeholders & even some organisational development. Herding cats is easier, isn’t it?

With Architecture in ACTion, I introduce you to decades of practical science on the Human Mind. We’ll dig into Psychological Flexibility and ACT - concepts that are (still) rarely used in biz but have huge impact at work!

Because: Deep tech expertise, domain navigation *and* change skills is a lot!

You'll leave this session with:

• practical, low-tech tools for effective operational work as architects
• a reflection canvas for laser-focussed strategic work as tech leaders
• digestible science bits on Human Mind and Behaviour
• (hopefully!) a desire to learn more about your “thinking machine”

Target Audience: Software Architects, (Technical) Leaders, curious humans in IT who work with other humans (in IT)
Prerequisites: Some work/project experience and openness for new ways of thinking (and potentially behaviour)
Level: Basic

Code that is well-designed and easy to understand is cheaper to extend and modify - so you can deliver more value, sooner. Many organizations struggle with older codebases that use outdated designs and have too much cruft.

I found that the technical coaching I was doing was addressing those kinds of issues successfully, but it was slow to scale up to large projects where there are tens of teams of developers working on different parts of the same codebase.

Recently I’ve been using a complementary approach. The basic idea is regular, short interactive training for teams of developers, led by a peer. They use high quality materials and content I’ve designed. In this talk I will explain what I’ve found and how you could adapt my ideas and materials for your situation.

Target Audience: Tech lead, senior dev, architect
Prerequisites: Experience writing code in a development team (even if it was a while ago)
Level: Advanced

Während einer Product Discovery werden alle relevanten Beteiligten zusammengebracht und so viele valide Informationen wie notwendig gesammelt, um den gesamten Problemraum durch die wichtigsten Anforderungen aller Perspektiven klar zu definieren. Nach dem Motto “fail early” werden darauf aufbauend passende Lösungsansätze erarbeitet, evaluiert und iteriert - erstmal ganz ohne Programmieraufwände. Diese Praxis ermöglicht langfristig ein effektives, ressourcenschonendes Entwickeln und trägt durch informierte Entscheidungen zur höheren Qualität einer bedarfsgerechten, nutzerzentrierten Lösung bei. Aus unserer Erfahrung müssen aber ein paar Faktoren stimmen, dass eine Discovery auch tatsächlich Lerneffekte und innovative Lösung bewirkt.

Ich bringe ein good practice Beispiel mit und möchte mit dem Publikum interaktiv analysieren, welchen Einfluss z.B. Teamzusammensetzung, Methoden der Nutzerzentrierung und Kollaboration haben und welche Knackpunkte ganz konkret problematisch sein könnten.

Zielpublikum: Product Owners, Project Leads, Agile Coaches, Developers, Designers
Voraussetzungen: Interesse und grundlegende Praxis in nutzerzentrierter Arbeit
Schwierigkeitsgrad: Advanced

Immer wieder stehen wir vor der Frage "Make or Buy?" und begegnen dabei featurereichen Platform-as-a-Service- oder Software-as-a-Service-Lösungen, die unsere Anforderungen erfüllen sollen.

Doch ist das tatsächlich so? Unsere Erfahrung zeigt, dass fertige Lösungen von der Stange in den seltensten Fällen genau die Fähigkeiten mitbringen, die unsere Anforderungen erfüllen.

Am Beispiel API-Management stellen wir unseren Ansatz des Capability Journey Mappings als Herangehensweise zur pragmatischen Diskussion von Fähigkeiten vor. Die Metapher eines Liniennetzplans erlaubt uns dabei eine geführte und strukturierte Betrachtung möglicher Capabilities auf dem Weg zu einer passgenauen Lösung. So werden potentielle Voraussetzungen oder Vorbedingungen abhängiger Fähigkeiten berücksichtigt.

Im Ergebnis entsteht ein klares Bild, welche Capabilities zur Erfüllung der Geschäftsanforderungen benötigt werden. Damit ist die Grundlage geschaffen, um eine differenzierte Make-or-Buy-Entscheidung für einzelne Capabilities zu treffen, anstatt umfangreiche, monolithische Plattformen einzuführen. Die Brücke von den Geschäftszielen zu den benötigten technischen Fähigkeiten einer Plattform ist damit geschlagen.

Zielpublikum: Architects, Product Owner, Business Analysts, Enterprise Architects
Voraussetzungen: Grundverständnis von Anforderungsanalyse, System Capabilities
Schwierigkeitsgrad: Advanced