Micro-Frontends eigenen sich nicht in allen Szenarien! Diese Session stellt einen alternativen Ansatz vor: Frontend-Modulithen. Wir besprechen das Abbilden fachlicher Domänen, die Kategorisierung von Bibliotheken sowie Zugriffseinschränkungen zum Erzwingen entkoppelter Teilsysteme. Außerdem nutzen wir inkrementelle Builds und einen Build Cache zur drastischen Beschleunigung des CI-Prozesses. Am Ende wissen Sie, ob Frontend-Modulithen für Sie der richtige Ansatz sind und wie Sie Ihre Anwendungen damit aufbauen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagenwissen zu JavaScript von Vorteil
Schwierigkeitsgrad: Fortgeschritten

Imagine you have an enterprise frontend monolith. Due to explosive growth, around 30 teams work on it, with about 100 different use cases. How do you keep this system scalable and consistent?
That's the question we faced inside Partner Home at Wayfair. I'm going to share our experience implementing a micro frontend architecture based on React to distribute shared concerns as long-lived applications. We used module federation, a new feature in Webpack 5.
I'll talk about the general architecture, plus an overview of our technical solution.

Target Audience: Architects, Developers
Prerequisites: English, Frontend Architecture, React
Level: Expert

Orchestrating the work of hundreds or thousands of people working at different locations around the world presents a set of challenges specific to that kind of context. It is not simply a matter of “scaling up", we need to understand underlying principles and patterns and make them work. With this session we invite you into a conversation about how to improve the way leaders and teams collaborate in our organizations. You will experience a workshop that you can reproduce for your organisation to create supporting structures that scale

Target Audience: Thinkers, Decision Makers, Architects, Managers, Coaches, Scrum Masters, Product Owners
Prerequisites: Curiosity and some experience in working in large organisations
Level: Advanced

Extended Abstract
Orchestrating the work of hundreds or thousands of people working at different locations around the world presents a set of challenges specific to that kind of context. It is not simply a matter of “scaling up” what works for orchestrating the work of a small number of co-located people, or even a small number of distributed teams. The specific practices necessary for success will vary and evolve. Variety of practice is essential to creating successful outcomes.
There is a useful set of underlying principles and patterns that we bring to our work. They enable us to create a wide variety of context-aware practices that serve the needs of the people in our organizations, and support them in collaborating to create value for our customers.
With this session we invite you into a conversation about how to improve the way leaders and teams collaborate in our organizations. We will look at teams’ needs regarding autonomy, leadership, and support, and at leaders’ needs regarding strategy, challenges, and responsibility. One specific theme we explore in this session is that of the relationships between leaders and teams, and how we leverage those relationships to orchestrate work and outcomes.
Through this session you will experience a workshop that you can reproduce for your organisation. We will share our setup guides, tools, and materials with you so that you can create supporting structures to more effectively orchestrate collaboration at different scales in your organization.

Überall in Organisationen treffen wir auf Menschen, die gemeinsam daran arbeiten, Wert zu schaffen. Die Integration verschiedener Persönlichkeiten ist dabei selten leicht. Egal ob neues oder länger bestehendes Team, immer wieder sehen wir Teamarbeit, die keinen Spaß macht, unausgetragene Konflikte und Personen, die eigentlich gar nicht zusammen arbeiten wollen. Mit dem Team Orientation Process wollen wir einen pragmatischen Prozess vorstellen, mit dem die relevanten Fragen adressiert werden, ohne die Bedürfnisse Einzelner außer acht zu lassen.

Zielpublikum: Projektleiter:innen, Scrum Master, Manager, Teamleiter
Voraussetzungen: Erfahrung in der Arbeit mit Teams, Interesse an echten Teams
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Wir sehen in Unternehmen viele Investitionen in Team Building, die aber oft verpuffen. Das liegt aus unserer Sicht daran, dass oft die relevanten Fragen für die Zusammenarbeit im Team nicht geklärt werden. Der Team Orientation Process begeistert uns, weil er einen Fokus auf genau diese Fragen ermöglicht, ohne die Bedürfnisse der einzelnen Teammitglieder außer acht zu lassen.
Er besteht grob aus folgenden Schritten:
- Was ist die Aufgabe des Teams?
- Was motiviert die Teilnehmer des Teams, daran mitzuwirken?
- Welche Vereinbarungen braucht es dafür?
- Wie finden wir ein klares, motivierendes Ziel fürs Team?
- Welche Fähigkeiten und Ressourcen stehen uns zur Verfügung?

Das wirkt auf den ersten Blick sehr sachlich, fördert aber eine tiefe Verbindung der Personen im Team, ohne die persönlichen Befindlichkeiten zum Kern des Teams zu machen.
In unserem Vortrag wollen wir den Prozess und die Wirkung vorstellen und durch eigene Erlebnisse fühlbar machen.

"Imagine... Everyone able to work consistently at their ideal best:
- Individuals, teams, between teams, across the organisation and beyond
- Right conversations, right people, best possible moment
- Needs anticipated, met at just the right time"
Das ist ein Leitbild aus Agendashift und es spricht mir aus der Seele. Ich habe das mit OpenSpace Agility als Herzschlag kombiniert. Für meinen Kunden habe ich damit einen Mix gefunden, der es erlaubt, Struktur und Freiräume so zu kombinieren, dass Veränderung kontinuierlich geschehen kann.

Zielpublikum: Alle, die mit Veränderung, Verbesserung und/oder Organisationsentwicklung zu tun haben
Voraussetzungen: Keine Vorkenntnisse notwendig
Schwierigkeitsgrad: Anfänger

Extended Abstract
OpenSpace Agility beruht auf Einladung und Freiwilligkeit. Die Mitarbeiter:innen werden als Experten des Systems betrachtet und dabei unterstützt, Verprobungen zu wählen. Diese sollen zeigen, ob die Veränderung in die gewünschte Richtung läuft. Als Start und Endpunkt einer längeren Verprobungsphase dienen Open Spaces.
Um eine Basis für gemeinsame Gespräche zu schaffen und lokale Optimierungen zu vermeiden, war es mir besonders wichtig, sowohl in der Vorbereitung für den ersten Open Space, als auch in der Verprobungsphase Strukturen anzubieten, die helfen ein gemeinsames Verständnis herzustellen und den Lösungsraum möglichst lange offen zu halten.
Hierbei hat mir Agendashift geholfen: Gemeinsame Bilder der Ziele und Probleme über die Abteilungen und Ebenen hinweg. Struktur geben, wo sich Mitarbeiter:innen durch zu viele Freiheiten und Möglichkeiten verloren fühlten.
In dem Vortrag erzähle ich davon,

• wie wir die Phase vor dem ersten Open Space und insbesondere die Auswahl der Themen gestaltet haben
• welche Teile von Agendashift und OpenSpace Agility wir kombiniert haben und welche Auswirkung das auf Gespräche in der Organisation hatte und
• welche weiteren Kombinationsmöglichkeiten ich sehe, um mehr Verantwortung zurück in die Organisation zu geben.

Weiterhin werden die Teilnehmer:innen einen der Game Changer, kennenlernen und in kleinen Gruppen selbst anwenden, der Gespräche nachhaltig verändert hat. Mit einer handvoll wertungsfreier Fragen wird der "Coach" mit seinem:ihrem "Coachee" erforschen, was möglich ist, wenn ein spezielles Problem oder Hindernis nicht mehr existiert, und so den Raum für Lösungsoptionen erweitern. Im Debrief werden wir dann beleuchten, welche Effekte diese Art der Fragen und Übung hat und ich werde meine Beobachtungen der letzten Monate dazu teilen.

In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organizations need to design for adaptability. Designing for adaptability requires understanding the landscape organizations are operating in, identifying patterns of change, applying principles for organizational fitness, and making mindful strategic decisions to adapt change.

Target Audience: Software Architects, Tech Leads, Engineering Manager, VP of Engineering
Level: Basic

Extended Abstract
Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
This talk brings different perspectives and techniques together from business strategy (Wardley Mapping), software architecture (Domain-Driven Design), and team organization (Team Topologies) as a powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.

(Agile) Games are sounding throughout the land. Everyone plays games and anyone guides games. However, what makes playing games "interesting" from the business owner's perspective? 

We look into the criteria of effectiveness and efficiency of games and thus the capabilities of creating business impact for the company.

As such, it turns out a game - is just a game and remains a play if one does not align with underlying business needs. Sounds familiar? But you wonder how to do so?

In this talk, we will look in a 4-Step-Modelmaking the obvious tangible. And in the end, it becomes a structured approach how one might create business impact too.

Target Audience: Moderators, (young) Scrum Masters, Project Leaders, Managers, Decision-Makers, Facilitators
Prerequisites: General understanding of games and agility, and how to lead games successfully
Level: Basic

So many challenges, so little time. As testers or quality engineers, we need to sharpen the saw, but how? Gamification can be a way to look at how you're doing and find out where to improve. It's a great way to have everyone engaged and get the best out of people.

In this presentation, Ben Linders will show how playing games (onsite or online) with the Agile Testing Coaching Cards and Agile Quality Coaching Cards help to explore your current quality and testing practice and decide as a team on what to improve or experiment with.

Target Audience: Testers, Agile Teams, Tech Leads, Technical Coaches, Scrum Masters
Prerequisites: None
Level: Advanced

Extended Abstract

The Agile Testing Coaching Cards and Agile Quality Coaching Cards are a deck of cards with statements that help people to share and reflect. Examples of cards are "Testers help developers design acceptance criteria for user stories", "Failing tests get proper attention even when no defect in the product has been detected", and "Refactoring is done to keep code maintainable and reduce technical debt".

Playing games with these coaching cards (onsite or online), you can learn from each other. Teams can use the coaching cards to discuss quality and testing values, principles, and practices, and share their experiences and learnings.

Different game formats can be used to share experiences on testing and quality principles and practices and explore how they can be applied effectively. The playing formats from the Agile Self-assessment Game (benlinders.com/game) can be used to play with these cards. This presentation provides an overview of playing formats and will inspire you to come up with your own formats.

Facilitation is key when playing with these coaching cards. Ben Linders will present how to prepare a game session and facilitate it, what can be done to keep people engaged, and how debriefing can help to pull out learnings and ideas for improvement.

Takeaways:

- Show how to use gamification to self-assess your current way of working.

- Present examples of playing games with the Agile Testing Coaching Cards and Agile Quality Coaching Cards.

- Explore how facilitating games can help to enhance quality and testing in agile teams.

Digitalization has been changing existing industry B2B businesses, digitalization business models arrived and the Digitalization solutions need to be developed to support this. The sudden enforcement of social distancing has given the digital transformation a significant push forward. How do we develop innovative Digitalization offerings in the future? We will show how to seize these opportunities and forge new paths toward the new normal for Software Engineering.

Target Audience: Software Engineers, System and Software Architects, Software Managers
Prerequisites: Knowledge in Software Engineering Practice
Level: Basic

Stories from a High Performing Team is a talk about the teamwork in a software development team at ThoughtWorks, a global Tech Consultancy. The team including the speakers - Jennifer (Developer), Xiaofan (Experience Designer) and Ursula (Business Analyst) - have been working for 14 month together which is a rare case in the consultancy business. The team is known for being high performing and today they want to share stories and practices for agile software development teams on how to reach this level.

Target Audience: Developers, Business Analysts, Architects, Project Managers, Delivery Principals
Prerequisites: Agile Mindset, Modern Softwaredevelopment understanding
Level: Advanced

Was heißt es aus rechtlicher Sicht, zu Open-Source-Software beizutragen? Wer haftet wann und für was? Wie sieht es mit urheberrechtlichen Aspekten aus? Und welche Hürden muss man überspringen, um entweder bereits vorhandene eigene oder neue Software zu opensourcen? Wie kann ich verhindern, dass essenzielle Businessfunktionalität auch in Open Source überführt werden muss? Wie findet man die richtige Lizenz, wie ist das prozessuale Vorgehen?
Der Vortrag gibt einen für Laien gut verständlichen Einblick mit detaillierten Hintergründen.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider, Manager
Voraussetzungen: Projekterfahrung von Vorteil
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Google, Microsoft und Facebook tun es. Und viele andere auch. Vor einigen Jahren noch mit Skepsis wahrgenommen, ist Open Sourcing inzwischen nicht nur ein erfreulicher Trend, sondern für Soft- und Hardwareentwicklungsunternehmen zum Regelfall geworden. Die Vorteile liegen klar auf der Hand: Mitarbeiterförderung, das Finden neuer Kollegen, zusätzliches Review, Testing und Contributions. Was heißt es aber aus rechtlicher Sicht, zu Open-Source-Software beizutragen? Wer haftet wann und für was? Wie sieht es mit urheberrechtlichen Aspekten aus? Und welche Hürden muss man überspringen, um entweder bereits vorhandene eigene oder neue Software zu opensourcen? Wie kann ich verhindern, dass essenzielle Businessfunktionalität auch in Open Source überführt werden muss? Wie findet man die richtige Lizenz, wie ist das prozessuale Vorgehen?
Der Vortrag gibt einen für Laien gut verständlichen Einblick mit detaillierten rechtlichen und technischen Hintergründen zu den geläufigen Open-Source-Lizenzen, Fragen in der Haftung, in lizenz- und urheberrechtliche Fragestellungen wie auch der prozessualen Einbindung in den Entwickler- und Unternehmensalltag in Build-Pipelines mit Lösungen wie Blackduck, WhiteSource & Co. Außerdem werden Open Chain und Oracle vs. Google beleuchtet.

In jedem Projekt treffen unterschiedlichste Menschen aufeinander und damit verschiedenartige Sichtweisen.

Fachliche Experten diskutieren mit Anwendern, Softwareentwicklern und unterstützenden Fachabteilungen wie PMO, Personalabteilung, Betriebsrat oder der Unternehmensrevision. Jede Stakeholdergruppe hat unterschiedliche Erwartungen bzw. konkreten Informationsbedarf an das Projekt.

Der Vortrag stellt Lösungsansätze und Beispiele vor, wie man mit Domain Storytelling fundierte Antworten auf die Fragestellungen der Stakeholder finden kann.

Zielpublikum: Product Owner, Entwickler:innen, Anwender, Projektleiter:innen, Manager, Coaches, alle Stakeholder
Voraussetzungen: Nur eine Kurzeinführung in die Methode, aber trotzdem für Einsteiger geeignet, weil selbsterklärend
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Mit Domain Storytelling lassen sich Themen wie fachliche Projektinhalte, Personen und Leistungskontrolle oder ordnungsgemäße Abrechnung auch für größere Gruppen für die Diskussion visuell aufbereiten. Den Beteiligten macht es in der Regel Spaß und ist sehr motivierend, die eigene Rolle konkret in Szenarien zu erleben, zu hinterfragen und am Ende gemeinsam neue Lösungen zu erarbeiten. Wenn dann auch die notwendige formale Projektdokumentation durch die Szenario-Diagramme vereinfacht werden kann, entstehen weitere Win-Win-Situationen rund um das Projekt.

Domain Storytelling als Interview- und Modellierungstechnik nutzt eine einfache Bildsprache, um Geschichten über den Anwendungsbereich zu erzählen und zu dokumentieren. Die Bildsprache kennt im Wesentlichen drei Arten von Symbolen, die als Icons und Pfeile dargestellt werden:

- Akteure sind die handelnden Personen und IT-Systeme einer Geschichte. Typischerweise benannt mit einer Rollenbezeichnung (z.B. Bus-Disponentin).

- Die Arbeitsgegenstände, mit den die Akteure ihre Arbeit machen. Oft Dinge, die man anfassen und sehen kann, wie der „Bus“. Manchmal auch ein vergegenständlichtes Konzept, wie der „Auftrag“.

- Aktivitäten beschreiben, was die Akteure tun, und werden durch Pfeile ausgedrückt. Die Nummerierung der Pfeile zeigt die Reihenfolge der Aktivitäten. Die Aktivitäten sind die Verben in unseren Geschichten.

Icons und Pfeile werden durch kurze Texte so erläutert, dass ein „visueller“ Satz entsteht. Für die Beschriftung verwenden wir Begriffe aus der Domänensprache. Das Ergebnis wird als Bild mit einfachen Piktogrammen dokumentiert. (Konkrete Beispiele finden sich unter www.domainstorytelling.org )

In den 1960er Jahre entwickelte die NASA eine Methode zur Sicherstellung von Lebensmittelqualität: die Gefahrenanalyse der kritischen Kontrollpunkte nach HACCP. Diese Methode inspirierte mich zu einem Workshop, der über Teamgrenzen hinweg gemeinsam einen Blick auf die Qualität unseres Produkts wirft.

In meinem Vortrag zeige ich Ihnen, wie ich als ursprünglich gelernter Koch, heute in der Rolle des Qualitätsmanagers, instinktiv Methoden der Lebensmittelhygiene anwende. Mit dem Ziel, welches wir alle möchten: die Qualität des Produkts!

Zielpublikum: Prozessverantwortliche, Testmanager:innen, Qualitymanager:innen, Entwickler:innen, Manager, Entscheider
Voraussetzungen: Keine besonderen Vorkenntnisse nötig
Schwierigkeitsgrad: Anfänger

Extended Abstract

Zu Beginn der 1960er Jahre entwickelte die NASA eine Methode zur Sicherstellung von Lebensmittelqualität. Diese Methode inspirierte mich zu einem Workshop, der über Teamgrenzen hinweg, gemeinsam einen Blick auf die Qualität unseres Produkts wirft.

In meinem Vortrag zeige ich Ihnen, wie ich als gelernter Koch instinktiv Methoden der Lebensmittelhygiene anwende. In der Rolle als Qualitätsmanager führte ich Workshops durch, die unseren Entwicklungsprozess entscheidend veränderten – mit Methoden aus der Gastronomie.

Die Gefahrenanalyse der kritischen Kontrollpunkte nach HACCP (hazard analysis and critical control points) ist bis heute eine gesetzlich vorgeschriebene Methode in der Lebensmittelindustrie und Gastronomie, um die Qualität (Hygiene) von Lebensmittel-Produkten sicherzustellen. Diese Methode war der Ausgangspunkt für den Prozessanalyse-Workshop Quality Storming. Der, für Software-Entwicklung erdacht, in den Jahren immer mehr verbessert wurde.

Ich zeige Ihnen, wie Sie mit drei verschiedenen Quality Storming-Varianten die Hygiene ihrer Entwicklungsprozesse entscheidend verbessern können. Wir schauen gemeinsam, warum permanente Temperaturkontrollen von Tiefkühlpizza die gleichen Ziele haben wie Softwaretests in der Entwicklung: die Qualität des Produkts!

Software-Engineering ist eine kollaborative Tätigkeit, an der mehrere Personen, oft von unterschiedlichen Standorten, zusammenarbeiten. Immersive Technologie (z. B. Virtual Reality oder Augmented Reality) kann dabei helfen, diese räumlichen Grenzen aufzuheben. Entsprechend unserer Forschung auf dem Gebiet wollen wir in diesem Vortrag zeigen, welche Möglichkeiten immersive, kollaborative Arbeitsplätze bieten, um Software-Entwicklungsteams beim Wissensaustausch und bei der visuellen Analyse von Daten zu unterstützen.

Zielpublikum: Entwickler:innen, Projektleiter:innen
Voraussetzungen: Kenntnisse Software-Visualisierung
Schwierigkeitsgrad: Anfänger

Software wird mehr und mehr von Menschen entwickelt, welche keine klassische Programmier-Ausbildung erhalten haben. In der Forschung ist diese Entwicklung besonders deutlich.
Im DLR haben wir die Software Engineering Initiative gestartet, um Forschende dabei zu unterstützen, Software nachhaltig zu entwickeln. Die Initiative umfasst eine Software Engineering Guideline, Trainings, Wissensaustauschworkshops, Consultings sowie das Erstellen einer für alle zugänglichen Wissensbasis.

Zielpublikum: Manager, Entwickler:innen, Projektleiter:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
Software-Entwicklung wird Voraussetzung in immer mehr Berufen, deren Ausbildung die Entwicklung von Software nicht beinhaltet. Bewegungen wie Low-Code-Entwicklung oder die Software Carpentries sind Resultate dieser Entwicklung, um eben jenen Personen den Einstieg in die Programmierung zu erleichtern. In der Forschung ist diese Entwicklung besonders deutlich. In kaum einem Forschungsbereich kommt man ohne Software aus. Da meist hochspezialisierte Individualsoftware benötigt wird, welche es nicht „Off-the-shelf“ zu kaufen gibt, bleibt dann nur eine Möglichkeit: Selber schreiben.
Software-Entwicklung gehörte somit zunehmend zur täglichen Arbeit vieler Forscher in Natur- und Ingenieurwissenschaften. Sie stehen vor Herausforderungen im Software-Engineering, für die sie nicht ausgebildet sind. Das Deutsche Zentrum für Luft- und Raumfahrt (DLR) hat 2005 die „DLR Software Engineering Initiative“ ins Leben gerufen, um seine Forscher bei der Bewältigung dieser Herausforderungen zu unterstützen.
Die Initiative ist über die Software-Engineering-Richtlinie in das Qualitätsmanagement des DLR integriert. Die Richtlinie definiert die allgemeine Software-Engineering-Politik und ist für alle DLR-Forschungsinstitute verbindlich. Ein weiterer Kernaspekt der Initiative ist das DLR Software-Engineering-Netzwerk. Es setzt sich aus Vertretern der verschiedenen DLR-Forschungsinstitute zusammen und bildet damit das zentrale Austauschforum des DLR zum Thema Software-Engineering. Die Software-Engineering-Initiative besteht weiterhin aus folgenden ergänzenden Aktivitäten, die sich auf die direkte Unterstützung von Forschern konzentrieren, welche Software im Rahmen ihrer Tätigkeit im DLR entwickeln:
* DLR Software Engineering Guidelines
* Regelmäßige Trainings
* Wissensaustauschworkshops
* Consultings
* Aufbau einer für alle zugänglichen Wissensbasis
Wesentlich für die Akzeptanz und Annahme dieser Aktivitäten ist das Verständnis, dass es den Forschern nicht um die Entwicklung möglichst guter Software geht, sondern die eigentliche Forschungsarbeit im Zentrum ihrer Arbeit steht. Dies stellt besondere Herausforderungen an die Planung und Durchführung dieser Aktivitäten.
Was für das DLR gestartet wurde, wird aktuell auf Helmholtz-Ebene erweitert und soll zukünftig jedem zur Verfügung stehen. Für erste Elemente haben wir dies Ziel bereits erreicht, bei anderen arbeiten wir mit nationalen und internationalen Forschungszentren und Research Software Engineering (RSE) Communities darauf hin.

Um nachhaltig erfolgreich zu sein, müssen Unternehmen schnell, robust und anpassungsfähig auf die steigende Dynamik im Markt reagieren.
Doch wie entsteht Dynamikrobustheit in Unternehmen und was bedeutet das für die Organisationsstrukturen und IT-Architektur?
In unserem Workshop möchten wir unsere Erfahrung aus der Begleitung zweier Großkonzerne mit euch teilen und anhand von praktischen Beispielen Konzepte von Conways Gesetz über den Tech-Radar bis hin zu Team-Topologien beleuchten. Dazwischen ist genug Zeit für Praxisfragen und Diskussion.

Zielpublikum: Manager, Entscheider, Agile Coaches, Projektleiter:innen, Architekt:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Schnell, robust und anpassungsfähig auf die ständig steigenden Marktanforderungen reagieren zu können - das ist das Ziel vieler Unternehmen. Während die meisten noch versuchen, mit agilen Prozessmethoden der wachsenden Dynamik und Komplexität Herr zu werden, setzen erfolgreiche Unternehmen auf weitgehend resilient organisierte Strukturen. Aber wie geht das?
Mit Scalamento begleiten wir seit 2016 verschiedene Unternehmen bei der Anpassung ihrer Organisations- und IT-Strukturen an ein komplexes Umfeld. In unserem Workshop teilen wir unsere Erfahrung, wie Dynamikrobustheit in Unternehmen entsteht und was das für Teamstrukturen und die IT-Architektur bedeutet. Was sind Erfolgsfaktoren für cross-funktionale Teams? Wie finde ich heraus, welche Kollaborations-Form und Software-Architektur sich für meine Herausforderungen eignet?
Am Beispiel zweier Großkonzerne berichten wir vom Umbau der Organisations- und IT-Strukturen in hierarchischen Organisationen. Gemeinsam mit den Teilnehmenden diskutieren wir dabei den Mehrwert von Konzepten wie Conway’s Law, dem Tech-Radar und Team-Topologien. Dazwischen ist genug Zeit für Praxisfragen und Anwendungsbeispiele der Teilnehmenden.

Teams sollten interdisziplinär sein und möglichst fokussiert auf ein gemeinsames Ziel hinarbeiten. So lehrt es uns sowohl die klassische Management-Literatur als auch agile Methoden wie Scrum. Nur leider gibt es in der Praxis immer wieder sehr erfolgreiche Teams, auf die keines dieser Kriterien zutrifft.
Wenn man genauer hinsieht, entdeckt man, dass es verschiedene Arten von Teams gibt, die unterschiedlich organisiert und geführt werden sollten. Gemeinsam werden wir die verschiedenen Spielarten erkunden.

Zielpublikum: Coaches, Manager, Teamleitende
Voraussetzungen: Basiswissen über Teams, hilfreich: Agile Grundkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Die Session basiert auf dem Konzept von "Extradependent Teams" von David Kesby. Diese Teams, die nach außen wirksam sind, kommen in praktisch jeder Organisation vor und werden vom klassischen Teamgedanken außen vor gelassen. Dabei bilden sie - richtig geführt - einen Pfeiler der Organisation. Wer sie von "normalen", sogenannten "Intredependent Teams" unterscheiden kann, stellt sicher, dass funktionsfähige Teams nicht durch ein unpassendes Paradigma in dysfunktiopnale Gruppen zerlegt werden.
Wir werden die wesentlichen Elemente des Konzepts interaktiv erarbeiten.

Unfortunately, the session is cancelled without replacement.

With AI entering more and more aspects of our lives, scepticism and worries towards this technology are increasing too. Empathy towards basic human needs and a great User Experience can help AI being more widely accepted and used.
But how to get there?
After covering basic UX principles, the talk will deep dive into the fields of trust, transparency and explainable AI.
The goal is to outline a path to a fruitful collaboration and mutual understanding between humans and AI.

Target Audience: Software Engineers, Data Scientists, Product Owners, Researchers, Designers
Prerequisites: None
Level: Basic

Autonome Teams sind etwas, das häufig als Fundament agiler Organisationen gesehen wird.
Der Vortrag beschäftigt sich mit Teamautonomie aus Perspektive von Organisationen und Software-Entwicklung entlang folgender Fragen:

• Was bedeutet Autonomie in einer Organisation?
• Kann es autonome Teams eigentlich geben?
• Warum passiert es, dass Teams nicht autonom sind?
• Warum ist die Illusion von Autonomie oft wertvoller als faktische Autonomie?
• Und warum ist die Abwesenheit von Autonomie wertvoll?

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider, Scrum Master, Agile Coaches
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Der Vortrag bezieht sich auf moderne und uralte Erkenntnisse aus der Soziologie und Organisationstheorie.
Es wird gezeigt, warum mehr Autonomie in Organisationen zu mehr Kommunikation führen muss und damit eine paradoxe Situation entsteht:
Zumeist wird die Autonomie gefordert, weil es ein "Zu viel" an Kommunikation zu geben scheint. Die naive Lösung ist dann: Entkopplung, sowohl der Architektur als auch der Organisation.
Das klappt leider nicht, weil Autonomie etwas erfordert, das in der Organisationssoziologie "Entscheidungsprämissen" genannt wird. Grundsätze, anhand derer Entscheidungen "im Prinzip" getroffen werden.
Die sind notwendigerweise unspezifischer als konkrete Entscheidungen und benötigen genau deshalb häufig mehr Abstimmung im Vorfeld - und mehr Diskussion in ihrer Anwendung.
Im Vortrag erkläre ich diese Paradoxie und zeige, wie sie in Organisationen, die Software entwickeln, genauso passiert wie in der Architektur der entstandenen Software. Witzigerweise hat Conway nämlich sogar in diesem Fall recht.

Wie kann man eigentlich sehen, wo IT-Teams stehen und was sie an Unterstützung und Führung brauchen? Wir wollten in der LV 1871 endlich mal weg von nur “Bauchgefühl” und haben uns mit vier Studierenden der LMU auf den Weg gemacht, um ein Reifegradmodell mit passenden Metriken zu entwickeln, die uns einen Überblick über unsere Entwicklungsteams geben. Im Sommer 2021 wurde das 6K-Modell vorgestellt und danach eingeführt. Wie ist das 6K-Modell entstanden, wie sieht es aus und welche Erfahrungen haben wir mit ihm gemacht? - Ein Erfahrungsbericht.

Zielpublikum: Agile Coaches, IT-Führungskräfte, Management
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Es fing mit einem Projektkurs an. Doch der Outcome hat uns langfristig viel gelehrt. In diesem Vortrag berichten wir von unserer Erfahrung mit vier BWL-Studierenden der LMU und wie sie uns bei der Reifegradbestimmung unserer IT-Teams halfen. Im Rahmen des Projekts wurde die Wissenschaft mit der Praxis eng verbunden und wir konnten feststellen: beides zusammen funktioniert und ergänzt sich super!
Selbstorganisiertes Arbeiten ist eine wesentliche Voraussetzung, um erfolgreich agil im Team arbeiten zu können. Um immer auf dem aktuellsten Stand zu bleiben, wie selbstorganisiert die IT-Teams arbeiten, wurde auf Basis von qualitativen Interviews und einer umfangreichen Literaturrecherche ein Reifegradmodell entwickelt.
Mit dem Reifegradmodell der LMU-Studierenden sind wir in der Lage, die Selbstorganisation unserer agilen Teams anhand von sechs Dimensionen abzubilden: den 6 Ks. Wie es uns nach der Einführung des Reifegradmodells erging und welche Erfahrungen wir damit gemacht haben, stellen wir in diesem Vortrag vor.

Die meisten unserer alltäglichen Notizen leiden unter dem “Lang-und-unleserlich”-Syndrom, weswegen sie schnell im Altpapier landen. Oft helfen diese Notizen nicht dabei, sich an die wichtigen Dinge zu erinnern. Dabei haben wir sie doch genau dafür erstellt!
Alle können Sketchnotes erstellen: Ich zeige dir, wie du mit dem Sketchnoten starten kannst, worin die Vorteile liegen, und wir zeichnen Schritt für Schritt Symbole für abstrakte IT-Begriffe, damit du deine erworbenen Kenntnisse auf der OOP einsetzen kannst.
An die Stifte, fertig, los!

Zielpublikum: Alle
Voraussetzungen: Papier und Stift (digital oder analog)
Schwierigkeitsgrad: Anfänger

Extended Abstract
Alle von uns machen im Berufsalltag unzählige Notizen - von Vorträgen, Meetings, komplexen Aufgaben, …
Die meisten dieser Notizen leiden unter dem “Lang-und-unleserlich”-Syndrom, weswegen sie schnell im Altpapier landen. Oft helfen diese Notizen nicht dabei, sich an die wichtigen Dinge zu erinnern. Dabei haben wir sie doch genau dafür erstellt!
Gemeinsam erkunden wir die Welt der Sketchnotes. Du erfährst, was Sketchnotes sind, und wie du sie in deinen Arbeitsalltag integrieren kannst. Du bist hier richtig, wenn du deine Notizen endlich hilfreicher gestalten möchtest. Dafür brauchst du keine 1 in Kunst, sondern einfach nur Lust, mal etwas Neues auszuprobieren.
Alle können Sketchnotes erstellen: Ich zeige dir Wege, wie du „erstmal langsam“ mit dem Sketchnoten starten kannst. Damit du dein erworbenes Wissen bei den nächsten beiden Tagen der OOP nutzen kannst, zeichnen wir gemeinsam Schritt für Schritt einige Symbole für abstrakte Begriffe aus der IT.
An die Stifte, fertig, los!

"Ursache war menschliches Versagen" hört man oft, wenn etwas schiefgeht. Aber was bedeutet das? Hat der Bediener geschlafen? War er vielleicht überfordert mit dem System? Muss und kann man den Menschen besser ausbilden oder auswählen? Ist "die Organisation" schuld? Oder war das System unglücklich designt? Muss man Systeme anders gestalten? Gibt es so etwas wie ein 100 % sicheres System? Was sind überhaupt Systeme? Nur technisches Gerät? Oder auch komplexe Gebilde wie Software oder die Gesellschaft? Fragen über Fragen. Im Vortrag Ideen für Antworten.

Zielpublikum: Jeder, der sich für technische Systeme (auch) jenseits der Software interessiert
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

This talk describes how to build and run a successful product development organization that delivers business value, not just features. I will cover what makes effective product development teams, how to structure, loosely couple, align and choreograph them, especially in larger organisations with up to 100 teams. Methods I will talk about include OKRs and Kanban Flight Levels. In this context I will also show when and how decentralised product teams can benefit from centralised platforms.

Target Audience: CTO, Manager, Decision Makers
Prerequisites: Experience with software development at scale
Level: Advanced

Within DDD we have the perspective of strategic design where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities, where teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. Join us were we share war stories about our experience doing collaborative modelling in several companies with 30+ people.

Target Audience: Architects, Manager, Decision Makers, Tech Leads
Prerequisites: None
Level: Advanced

Extended Abstract
As a business, we want to make sure our software can handle changes when the business changes. We want to define boundaries that support the flow of the business value. Within Domain-Driven Design we have the perspective of strategic design. A perspective where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities. Within these sub-domains, teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. But that poses real challenges: What exactly is the definition of a (sub)domain? What is problem space? How can we form a common language of these boundaries? How does a customer journey fit in? And how do you decide and come to a single model in a large group, where everyone shares that same model on a high level?
Join us in this talk where we will show and tell war stories about our experience of having done collaborative modelling in several companies. We will tell our successes, but more importantly our failures and what we learned from them. What are the key heuristics we think that makes a collaborative modelling session with 30+ people, without any DDD knowledge, succeed? What are the skills we need to learn to facilitate it, and how can we make a company not dependent on us as consultants to continue their journey? You will leave with the knowledge of how to start your own collaborative modelling of your domain boundaries. We tell you our definition of (sub)domains, problems and solution space, and how we explained it to the companies we consulted. Providing you with new perspectives on how to embed this as a ritual in your company.

Kennen Sie das? Ein Team ist aufgestellt oder läuft schon seit einer Weile, aber irgendwie wird man das Gefühl nicht los, dass es eher auf einem Feldweg als auf der Autobahn unterwegs ist. Wir stellen ein Modell vor, das einen guten Überblick liefert, welche Faktoren zu beachten sind, um ein Team gut zu begleiten, und unterlegen es mit Erfahrungen aus unserer langjährigen Praxis.

Zielpublikum: Projektleiter:innen, Führungskräfte, Scrum Master, Agile Coaches
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
Die Teilnehmenden werden einen umfassenden Blick auf diverse Faktoren bekommen, die die Teamentwicklung beeinflussen. Die Lernziele sind:
+ Kennenlernen des Teamradars
+ Verstehen der verschiedenen Aspekte des Teamradars
+ Erkennen von Verbesserungspotenzialen
+ Entwicklung neuer Ideen, eigene Teams besser zu unterstützen
Kennen Sie das? Ein Team ist aufgestellt oder läuft schon seit einer Weile, aber irgendwie wird man das Gefühl nicht los, dass es eher auf einem Feldweg als auf der Autobahn unterwegs ist. Häufig versuchen wir in solchen Situationen, am Team zu arbeiten und Verbesserungen herbeizuführen. Die Ursachen für solche Beobachtungen liegen aber oft gar nicht im Team selbst. Wir haben – aus unterschiedlichen Studien und Modellen – ein Teamradar entwickelt, mit dem Sie schnell die wesentlichen Aspekte und Voraussetzungen für gute Teamarbeit erkennen und ansprechen können. Im vorliegenden Vortrag erklären wir das Modell und unterlegen es mit Erfahrungen aus unserer langjährigen Praxis.

Vom Spotify-Modell über Inverse Conway zu Team Topologies: Die Ideen für die Organisation von Software-Entwicklung sind vielfältig. Bei einer Modernisierung konkurrieren die Bedürfnisse von alter und zukünftiger Architektur, das erschwert die Entscheidung für eine Struktur, die beide Seiten angemessen behandelt. Auf welche Probleme stoße ich hier, welche Möglichkeiten habe ich zur Gestaltung meiner Teams und welche Variante ist am wirksamsten? Ein Überblick über die aktuellen Ansätze, angereichert mit den Schmerzen aus der Praxis.

Zielpublikum: Projektleiter:innen, Manager, Entscheider:innen, Architekt:innen, Agile Coach
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Wir sehen in der Praxis viele interessante Adaptionen von Teamstrukturen, die auf Ideen von DevOps/Team Topologies, den agilen Skalierungs-Frameworks oder dem Spotify-Modell beruhen, während im Hintergrund eine Modernisierung der Software stattfindet. Dort treten in Folge oft ähnliche Probleme, Hindernisse und Anti-Patterns auf, die bei einem Green-Field-Ansatz oder normaler Weiterentwicklung nicht vorgekommen wären — und auf die wenig Antworten zu finden sind. Wie geht man mit den Interferenzen der Koexistenz der alten und neuen Welt um? Oft weichen die informellen Strukturen und Boundaries deutlich von dem ab, was formell existiert, und Macht, Einfluss, Wissen und Schattenstrukturen sorgen nicht nur für Probleme, sondern stellen auch überlebenswichtige Prozesse in der Organisation bereit. Wie integriert man die Umverteilung von Domänenwissen und neues technisches Know-how bei der Modernisierung? Zu welchen Strukturen sind Organisation, Teams und Personen schon fähig, zu welchen noch nicht? Wie und wann muss und kann man Raum für Lernen und Adaption gehen?
Wir zeigen Lösungsansätze, Workarounds und die offengebliebenen Fragen.

In dieser Session zum Thema High-Performing-Teams möchten wir uns einigen Aspekten widmen, die eine gesunde Basis für Teams bilden, auf der aufgebaut werden kann. Teams spielen eine entscheidende Rolle im Projekterfolg und im Kontext der Agilität im Allgemeinen. Wenn Du also erfahren möchtest, was es mit Verantwortung, Verantwortlichkeit und Selbstmanagement auf sich hat und wie Teams ihr volles Potenzial entfalten können und wie Du sie aktiv dabei unterstützen kannst, dann bist Du hier genau richtig!

Zielpublikum: Manager, Führungspersönlichkeiten, Coaches, Coaches, Scrum Master, Projektmanager, Entwickler:innen
Voraussetzungen: Keine Voraussetzungen, ein generelles Interesse an der Arbeit mit Menschen wäre jedoch hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Wir wollen uns in dieser interaktiven Session dem Thema „High-Performing-Teams“ widmen und schauen, was diese ausmacht und was ihnen dabei geholfen hat, ein solches Team zu werden. Neben ein wenig Theorie lernst Du dabei auch konkrete Werkzeuge und Methode kennen, die Dir in Deinem Alltag helfen können - ganz gleich, ob Du nun in Scrum unterwegs bist oder in Kanban oder etwas ganz anderem. Zusätzlich lernst Du auch ein paar Fallstricke und definitiv ein paar Herausforderungen kennen, die Dir in der Evolution von Teams begegnen werden.
Und neben dem Team geht es natürlich auch um die Individuen im Team. Selbstmanagement braucht Verantwortung. Ein wesentliches Merkmal von High-Performing-Teams besteht darin, dass die unterschiedlichen Teammitglieder selbstorganisiert variabel und flexibel unterschiedliche Aufgaben annehmen und erledigen, sich verantwortlich fühlen. Dabei bringt jedes Teammitglied seine Stärken proaktiv ein, unterstützt, wo möglich, und lernt, wenn nötig. In einem Team, das sich selbst managt und organisiert, muss daher ein hoher Grad von Verantwortungsübernahme vorhanden sein, damit die unterschiedlichsten Aufgaben erledigt werden können.
Wir schauen uns in dieser interaktiven Session an, welche Evolution diese Teams durchlaufen, lernen verschiedene Modelle und ganz konkrete Coaching-Praktiken kennen, die euch im Alltag helfen können, High-Performance-Teams entstehen zu lassen.

"Flow bezeichnet das als beglückend erlebte Gefühl eines mentalen Zustandes völliger Vertiefung und restlosen Aufgehens in einer Tätigkeit, die wie von selbst vor sich geht" (Wikipedia). "Das wollen wir auch" wird der Ruf aus IT-Entwicklungsorganisationen laut.
Wie das gehen kann? Zwei Beispiele aus der Praxis geben Inspiration, nachdem wir geklärt haben, welche Fragen wir uns vor einer solchen Transformation unbedingt stellen sollten, um den Zustand von optimaler Passung zwischen Menschen und Aufgaben in der eigenen Organisation zu erreichen.

Zielpublikum: Entscheider, IT-Führungskräfte, agile Rollen, Menschen, die etwas verändern wollen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger