Psychologische Sicherheit macht unsere Teams performanter, ja sogar zu "High Performance Teams", sagen zumindest die Wissenschaft und auch Google. Aber wie wir diese ominöse Psychologische Sicherheit erreichen, ist doch sehr schwammig beschrieben.
Diese sehr interaktive Session gibt Dir Anregungen, Inspiration und Werkzeuge an die Hand, wie Du als Leader in Dir selbst auf die Suche nach der (psychologischen) Sicherheit gehen kannst. Denn in einem ist sich die Wissenschaft einig: Psychologische Sicherheit beginnt mit dem Leader.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager:innen, Führungskräfte, Scrum Master:innen, Leader:innen
Voraussetzungen: Lust und Wille zu Reflektieren
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Psychologische Sicherheit macht unsere Teams performanter, ja sogar zu "High Performance Teams", sagt zumindest die Wissenschaft und auch Google. Aber wie wir diese ominöse Psychologische Sicherheit erreichen, ist doch sehr schwammig beschrieben.
Diese sehr interaktive Session gibt Dir Anregungen, Inspiration und Werkzeuge an die Hand, wie Du als Leader in Dir selbst auf die Suche nach der (psychologischen) Sicherheit gehen kannst. Denn in einem ist sich die Wissenschaft einig: Psychologische Sicherheit beginnt mit dem Leader.
Dazu braucht es eine spezifische Form der Selbstkenntnis, die wir durch überwiegend reflektorische, aber auch impulsgeführte Fragen und Aufgaben in dieser Session bearbeiten. Gelegentliche Checkins mit einem Gegenüber halten dabei den wichtigen Spiegel vor, der es ermöglicht, sich selbst im Gespräch zu überprüfen. Neue Erkenntnisse sind hoch wahrscheinlich! Diese Session wird ein Tanz zwischen Impulsen, Wissenschaft und Case Study mit einer guten Portion Reflektionsarbeit für alle Teilnehmer.

Die Zeit des blinden Vertrauens in Scrum als Allheilmittel ist vorbei. Wir müssen der Wahrheit ins Auge blicken: Scrum funktioniert nicht immer, besonders wenn es um die Bewältigung der Herausforderungen unzureichender Anforderungen geht.
Dabei gewinnt das Verständnis der Fachlichkeit unserer Kunden zunehmend an Bedeutung. Dennoch scheitern viele Softwareprojekte aufgrund unzureichender Anforderungen.
Aber keine Sorge, es gibt Alternativen!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider:innen, Product Owner:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wir müssen der Wahrheit ins Auge blicken: Scrum funktioniert nicht immer, besonders wenn es um die Bewältigung der Herausforderungen unzureichender Anforderungen geht.
Dabei gewinnt das Verständnis der Fachlichkeit unserer Kunden zunehmend an Bedeutung, was an der aktuellen Domain-driven-Design-Bewegung zu erkennen ist. Hier wird die enge Zusammenarbeit zwischen Entwicklungsteams und fachlichen Experten betont. Dennoch scheitern viele Softwareprojekte aufgrund unzureichender Anforderungen.
Aber keine Sorge, es gibt Alternativen!
In diesem Vortrag werfe ich einen kritischen Blick auf Scrum und präsentiere verschiedene Tools und Methoden, mit denen unsere Entwicklungsteams tief in die Fachlichkeit eintauchen. User Story Mapping, Event Storming und Domain Storytelling sind nur einige der Werkzeuge, die wir erkunden werden. Sie helfen dabei, die Fachlichkeit besser zu verstehen, Lücken in den Anforderungen aufzudecken und eine gemeinsame Sprache zwischen dem Entwicklungsteam und den fachlichen Experten zu etablieren.
Dieser Vortrag ermutigt die Teilnehmer, das veraltete Scrum-Paradigma zu überdenken und sich stattdessen auf wirkungsvollere Methoden zu konzentrieren. Nur so können wir hochwertige Produkte entwickeln, die den Bedürfnissen unserer Kunden gerecht werden.
Lasst uns die Grenzen des Bekannten überschreiten. Es ist an der Zeit, den Status quo zu übedenken und den Weg zu bahnbrechenden Innovationen zu ebnen. Sei ein Teil dieser Veränderung und tauche ein in die faszinierende Welt der Fachlichkeit!

Wir müssen Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen. An dieser Stelle kommen Team Topologies (M. Skelton und M. Pais) ins Spiel. Dort gibt es die Topologie des "Enabling Teams", welches knapp zusammengefasst, andere Teams mit Wissen und Methodik unterstützt. Dieser Vortrag gibt Ihnen einen Überblick sowie eine praktische Anleitung, wie Sie ein Architekturteam in ein Enabling Team umwandeln können, welches andere Teams unterstützt und befähigt. Der Vortrag enthält viele praktische Beispiele.

Zielpublikum: Architekt:innen, Manager:innen
Voraussetzungen: Eigentlich keine, aber ein paar Architektur-Basics schaden nicht.
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Viele große Unternehmen arbeiten immer noch mit zentralisierten architekturbezogenen Teams. Deren Aufgabe besteht häufig darin, anderen Teams architektonische Spezifikationen vorzugeben und dafür zu sorgen, dass diese Spezifikationen bei der Umsetzung eingehalten werden. Diese Teams werden oft als "Elfenbeinturm-Architektur"-Teams bezeichnet, die darauf abzielen, hochqualifizierte Architekt:innen zu bündeln. Diese Rolle ist auf dem Markt sicherlich nicht in Hülle und Fülle vorhanden.
Sie passen jedoch nicht in eine agile Umgebung, in der wir den Teams die Möglichkeit geben wollen, ihre eigenen Entscheidungen zu treffen. Bestimmte Leitplanken sind dennoch notwendig, um sicherzustellen, dass das Gesamtkonstrukt funktioniert. Darüber hinaus können gut gewählte Leitplanken auch den Abstimmungsbedarf zwischen den Teams drastisch reduzieren.
Wir müssen diese Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen, und gleichzeitig dafür sorgen, dass die einzelnen Teile zusammenpassen. An dieser Stelle kommen Team Topologies ins Spiel, eine von Matthew Skelton und Manuel Pais eingeführte Methode. Dort gibt es den Teamtyp des "Enabling Teams", welches knapp zusammengefasst, andere Teams mit Wissen und Methodik unterstützt.
Dieser Vortrag gibt Ihnen einen Überblick über diesen Wandel sowie eine praktische Anleitung, wie Sie ein zentralisiertes Architekturteam in ein Enabling Team umwandeln können, dessen Aufgabe es ist, die Architekturarbeit in anderen Teams zu verbessern. Sie werden lernen:
1.    Welche Stakeholder Sie in diesen Prozess einbeziehen sollten
2.    Warum das künftige Enabling-Team ebenfalls befähigt werden muss und wie man das macht
3.    Wo häufige Fallstricke auf dieser Reise liegen
4.    Warum diese Reise auf agile Weise mit kontinuierlichem Lernen und Retrospektiven durchgeführt werden muss
Dieser Vortrag wird auch viele Beispiele aus der Praxis enthalten, die eine solche Transformation begleiten.

Der Begriff „Plattform“ ist leider „überstrapaziert“. Wegen der Popularität großer Plattformen und Plattform-Unternehmen wird der Begriff inflationär gebraucht. Dadurch reden selbst Experten in der IT-Industrie kontinuierlich aneinander vorbei.
Der Vortrag präsentiert eine Landkarte mit Architektur-Big-Picture durch den Plattform-Dschungel, die dabei hilft, verschiedene Arten von Plattformen zielsicher zu erkennen und zu verstehen. Sie erlaubt Architekten, den Überblick zu behalten und alle anderen sicher durch den Dschungel zu führen.

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

Extended Abstract:
Der Begriff „Plattform“ existiert schon sehr lange und wird aktuell extrem viel und vielfältig verwendet, man muss leider schon sagen, er wird „überstrapaziert“.
Beispiele sind die Begriffe Cloud-Plattform, Plattformökonomie, iOS-Plattform, Platform Engineering oder Plattform-Industrie 4.0.
Wegen der Popularität großer Plattformen, dem Erfolg von Plattform-Unternehmen und den Verheißungen der Plattform-Ökonomie wird der Begriff mittlerweile inflationär gebraucht. Dadurch entsteht viel Verwirrung und selbst Experten in der IT-Industrie reden kontinuierlich aneinander vorbei.
Zeit, um etwas Ordnung zu schaffen und einen Überblick über verschiedene Arten von Plattformen und Verwendungen des Begriffs Plattform zu geben.
Der Vortrag hat zum Ziel, eine Landkarte durch den Plattform-Dschungel zu präsentieren, die es ermöglicht, verschiedene Arten von Plattformen zu erkennen und vor allem auch ihre unterschiedlichen Eigenschaften und Daseinsberechtigungen zu verstehen. Dadurch wird auch klar, wie große Unterschiede existieren und dass teilweise die einzige Gemeinsamkeit ist, dass Software im Spiel ist …
Die Zuhörer bekommen im Vortrag die Landkarte in die Hand, um sich nicht mehr zwischen Plattformbegriffen zu verirren. Der Vortrag ist nicht technisch motiviert oder orientiert, sondern soll eine bessere Kommunikation und Diskussion zwischen allen Professionen in der Digitalen Welt ermöglichen

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.naab , https://www.sigs.de/autor/dominik.rost

The Product Owner role in Scrum is vital, but lacks comprehensive guidance. This talk presents the SMIQ Method (Single Most Important Question), derived from the "48 hour book method," empowering Product Owners and Managers to translate customer needs into software requirements. It simplifies complex techniques into user-friendly steps for effective requirements engineering. The speaker's success in using this method for writing books, organizing conferences, and developing software highlights its simplicity and effectiveness.

Target Audience: Product Owners, Product Managers, Requirements Engineers, UX, Project Managers
Prerequisites: Scrum, Product Owner role in Scrum, beginner level knowledge of User-centered design
Level: Basic

Extended Abstract:
Product Owner is one of the most critical roles in the Scrum Framework. However, beyond “the backlog” and “prioritization”, there’s very little guidance as to what that role entails. This talk presents a method (The SMIQ or Single Most Important Question Method, discussed in the “48 hour book method”) that guides Product Owners, and Product Managers in their discovery work, and helps them translate customer needs into Software requirements. It’s a simple method, but it offers the opportunity for in-depth understanding and effective requirements management. The method achieves it’s simple format by codifying some complex techniques into a simple set of steps that anyone can use, and this speaker has used to write books, create conferences, and develop software.
Key Learnings

1. The challenge of understanding the customer, and what is required to succeed
2. How to translate real life into software requirements, reliably, and quickly
3. Concrete practices and techniques to implement the method suggested
4. Practical application of the SMIQ method in the conference room, with the participants
5. How to bring the SMIQ method to our work as Product Owners and Product Managers

Stoic practitioners know they cannot control circumstances, other people or rather... they know they cannot control anything outside of the realm of their own choices. So as a Stoic Product Leader you should stop focussing on outcome (!). Outcome is always outside of your control. However the CHOICES you need to make the product vision and goals ARE within your power, within your control. So the best thing you can do as a (product) leader is improving the quality of your decisions and teach your teams how to do that too.

Target Audience: Project/Portfolio Leaders, Product Owners, Product Managers, Leadership, Decision Makers
Prerequisites: None
Level: Basic

Extended Abstract:
Stoic practitioners know they cannot control circumstances, other people, behaviour of other people in their teams, or simply: they know they cannot control anything outside of their own mind, the realm of their own choices.
So as a Stoic Product Leader you should stop focussing on outcome. Outcome is outside of your control as a leader. Your own choices are within your control. The choices you need to make in the long run (product vision) and the ones you need to make that are right in front of you (iteration goal).
So the best thing you can do as a (product) leader is improving the quality of your decisions and teach your teams how to improve their ability to make better choices.
(Sustainable) product leadership is far more like poker (with uncontrollable circumstances and emerging events that influence possible outcomes) than like chess (if you think long and hard you could predict what is the next best move).
* Learning goals

1. know how to move from outcome focus to focus on improving decision quality
2. know how to implement habits that will improve your decision making as a product leader

This session will help you make better, more sustainable product choices

You have to deal with people - always! Konflikte & Veränderungen fordern uns heraus. Wir schaffen es nicht, diese Themen zu bearbeiten. Das führt zu Unzufriedenheit & Frust.
In unserem Vortrag wollen wir konkrete systemische Prinzipien und Methoden von 2 erfahrenen Coaches mitgeben, die eine neue Perspektive auf Herausforderungen im Projektalltag geben und eine persönliche Weiterentwicklung unterstützen können. Laut Zukunftsforschern wird die systemische Perspektive immer mehr zu einer Kernkompetenz von Akteuren in der modernen Arbeitswelt.

Target Audience: Software Engineers, Leaders, Scrum Masters, Agile Coaches
Prerequisites: None
Level: Basic

Extended Abstract:
Wenn Menschen zusammenarbeiten, kann es immer wieder Situationen geben, die in uns Stress erzeugen. Termin- und Entscheidungsdruck, ungelöste Konflikte und eine rasante Veränderungsgeschwindigkeit fordern uns täglich heraus. Als Führungskraft möchte ich meine Mitarbeiter:innen in Entscheidungen einbeziehen, muss aber trotzdem meiner Führungsrolle gerecht werden. Als Team-Mitglied habe ich vielleicht einen Konflikt mit jemandem im Team und weiß nicht, wie ich damit umgehen soll. Als Scrum Master begleite ich agile Veränderungsprozesse und bin auf der Suche nach Ideen und Impulsen, wie ich besser mit auftretenden Widerständen umgehen kann.
Systemisch beobachten, denken und handeln ist eine Grundhaltung, die uns helfen kann, besser mit sozialer Komplexität und organisatorischen Paradoxien umzugehen. Laut Zukunftsforschern wird die systemische Perspektive, wie sie z.B. auch professionelle Coaches und Therapeuten nutzen, immer mehr zu einer unverzichtbaren Kernkompetenz von Akteuren in der modernen Arbeitswelt (siehe auch Harvard Business Manager 01/2022 „Führen wie ein Coach“ oder „Future Skills“ von Pechstein, Spiegel et al., 2021).
Die Systemische Perspektive einnehmen bedeutet z.B., Zusammenhänge, Wechselwirkungen, Rückkopplungen, Rollen und Wahrnehmungen (auch die eigene) in komplexen Systemen zu erkennen und darauf aufbauend achtsam zu kommunizieren und zu handeln. Weitere Prinzipien wie Wertschätzung, Ressourcen-Orientierung, Lösungsfokussierung helfen, den Menschen und seine Bedürfnisse in den Mittelpunkt der Betrachtung zu stellen, und dadurch anschlussfähigere Lösungsansätze zu gewinnen.
In unserem Vortrag wollen wir die Systemische Haltung als „Mindset“ der Systemiker vorstellen. Darüber hinaus stellen wir 10 Denkanstöße und konkrete Methoden vor, die jede/r im Arbeitsalltag ausprobieren und seine/ihre systemische Haltung ausprobieren bzw. üben kann.
Als Führungskraft und Agile Coach bringen wir zwei wertvolle Perspektiven auf Menschen und Organisationen mit und finden so große Anschlussfähigkeit für die täglichen Herausforderungen von Teams, Führungskräften, Scrum Mastern und Agile Coaches.

Drei Jahre nach dem Ausbruch der Pandemie haben wir viel Erfahrung mit dem Thema Home-Office gesammelt. Langsam kehrt überall wieder Normalität ein, doch am Arbeitsplatz bleibt die Frage, wie es auf Dauer weitergehen soll. Wollen wir zurück ins Büro oder lieber im Homeoffice bleiben?
In diesem interaktiven Talk geht es um Antworten auf die Frage(n): Wer will wann wie und warum wo arbeiten und vor allem: Wie bringen wir alle unter einen Hut?

Zielpublikum: Software-Entwicklungsteams
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Dazu hat mich vor allem interessiert, welche Faktoren in unsere individuelle Vorliebe für ein Arbeitsplatzmodell hineinspielen. Bleiben introvertierte Menschen lieber im Homeoffice und Scrum Master:innen sind immer vor Ort? Hängt die Entscheidung davon ab, wie der Arbeitsplatz gestaltet ist? Welches sind die Top-Gründe für die eine oder andere Arbeitsweise? Und wie decken sich die Wünsche mit der Realität?
Um Antworten auf diese und mehr Fragen zu finden, habe ich über 100 Personen befragt und Studien recherchiert. Die Erkenntnisse daraus stelle ich in diesem Talk vor und bringe euch Ideen mit, wie ihr für euer Team und eure Organisation das passende Modell entwickeln könnt.

Many of us have worked on death-march projects or rewrote code "just because CTO said so".
How many have seen such endeavours succeed - without burning people, motivation, reputation & lots of money?
The quest for Sustainable Pace is as old as XP. Maybe even older.
It's neither an individual task nor is it only a team’s responsibility. It’s an interaction of both - and beyond: it all is about (organisational) systems!
If we cannot architect livable organisational systems, how are we supposed to architect decent socio-technical systems?

Target Audience: Developers, Architects, System Engineers, Managers of all flavours, Curious human beings
Prerequisites: Curiosity and some work/project experience is beneficial
Level: Advanced

Extended Abstract:
In this session you will get some of my answers on these questions.
Also you will:

1. learn what sustainable pace is about (and what it's NOT)
2. connect to all-too-common pitfalls that can “unbalance” a system (i.e. team, a whole organisation, and also yourself)
3. get simple yet powerful self-care practises for yourself and for your team(s)
4. learn necessary psychological background (e.g. stress & coping)

Bring genuine curiosity with you - the number one “tool” to expand horizons!

In 2011, realizing it desperately needed to offer a competitive product to Airbus’ A320neo, Boeing embarked on a project to upgrade its legendary 737 aircraft to match the A320neo’s efficiency. Limited by the constraints of the 737’s original design and their desire to minimize training needed by pilots to fly the new aircraft, Boeing made multiple critical compromises in the aircraft’s design. 346 deaths and $87 billion later, we have all been reminded of the importance of rigorous design processes and the need to engineer systems for the realities of the end users and their environment. This talk dives into the motivations for the design compromises, the human factors considerations that were disregarded, and how a Fortune 100 company’s prioritization of profit over good design practice led to its stunning fall from grace.

Als PO gestalten wir die Zukunft unseres Unternehmen: bessere (Teil-)Produkte, mehr Umsatz, Erfüllung von Stakeholder:innen-Wünschen, die oft nicht nachhaltig sind. In diesem Workshop widmen wir uns speziellen Themen aus dem riesigen Bereich "Nachhaltigkeit":

• Umgang mit dem Zwiespalt: People, Planet UND Profit
• Wie wir den CO₂-Fußabdruck bei Entwicklung und Betrieb von "grünerer Software" senken können.
• Wie unsere Produkte dazu beitragen, Nachhaltigkeitziele (SDGs), gesetzliche Vorschriften und Berichtsanforderungen zu erfüllen.

Max. Teilnehmendenzahl: 20
Laptop (mit Browserzugang) wird benötigt.

Zielpublikum: Schlaumeier und Gutmenschen ;-), Product Owner:innen, Produktmanager:innen, Menschen mit Interesse an nachhaltiger Produktentwicklung
Voraussetzungen: Kenntnisse in agiler Produktentwicklung ist hilfreich, aber nicht Voraussetzung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nachhaltigkeit wird in den nächsten Jahren in der Produktentwicklung eine zentrale Rolle spielen. Neue Gesetze, Nachhaltigkeit als Unternehmensstrategie, aber auch die schlichte Verantwortung als Mensch in einer zukunftsschönen Welt fordern, dass wir dazulernen. Wenn ihr dieses Thema als Product Owner:in bisher noch nicht auf dem Schirm habt oder vertiefen möchtet, seid ihr in diesem Workshop richtig.

Der Workshop ist in zwei Teile gegliedert, in denen es um Themen aus dem Bereich “Nachhaltigkeit in der Produktentwicklung” bzw. “Nachhaltigkeit durch Produkte” geht. Die Teilnehmenden erhalten die Gelegenheit, die Erkenntnisse auf ihre eigene Produktentwicklung zu übertragen. Im ersten Teil widmen wir uns der Frage, was Product Owner:innen mit ihren Teams in der Entwicklung konkret für den Klimaschutz tun können, z.B. um die Treibhausgas-Emissionen in digitalen Vorhaben zu reduzieren. Im zweiten Teil geht es um die Auswirkungen, die unser Produkt auf das nachhaltige Verhalten von Nutzer:innen haben kann, aber auf andere Stakeholdergruppen wie etwa Gemeinden oder Lieferant:innen.

Der Workshop ist als Arbeitsergebnis des Sustain-Agility-Vereins entstanden, dem Sabine und Johannes als Vorstände angehören. Wir beschäftigen sich aus innerer Motivation mit Nachhaltigkeit zusätzlich zu ihrer ursprünglichen Profession. Die gemeinsame Überzeugung der Mitglieder ist, dass agile Vorgehensweisen, Modelle und Haltungen hilfreiche Grundlagen und Erfolgsfaktoren für die Nachhaltigkeitstransformation unserer Gesellschaft und Wirtschaft sind. Wir haben erkannt, dass diese Transformation unverzüglich geschehen muss. Wir möchten diese Erkenntnis in der (agilen) Community verbreiten und zum Handeln aufrufen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/johannes.mainusch