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?

Wir teilen unsere Erfahrung, was Dynamikrobustheit in Unternehmen ist, wie sie entstehen kann und wie sie sich auf die IT-Architektur auswirkt. Am Beispiel zweier Großkonzerne berichten wir vom Umbau der Organisations- und IT-Strukturen in hierarchischen Organisationen. Wir beleuchten dabei Konzepte von Conways Gesetz über den Tech Radar bis hin zu Team Topologien. Dazwischen ist genug Zeit für Praxisfragen und Anwendungsbeispiele der Teilnehmenden.

In der Softwareentwicklung werden die Anforderungen an ein Produkt häufig von Stakeholdern oder Product Owner in einem Lastenheft definiert und dann im agilen Prozess in User Stories überführt. Die Anforderungen der Nutzer werden dabei oft außer Acht gelassen, was dazu führt, dass das fertige Produkt keine Akzeptanz findet. Es geht auch anders. Der Vortrag beleuchtet, wie eine Idee für ein Produkt nutzerzentriert entsteht und methodisch gestützt mit einfachen Mitteln in ein Product Backlog überführt wird. Ein konkreter Use Case inklusive praktischen Übungen in Miro zeigt, wie die Theorie umgesetzt wird und wie die einzelnen Schritte aufeinander aufbauen.

Zielpublikum: Product Owner, Business Analysten, Requirements Engineer, Projektleiter, Manager und alle, die agil ein Produkt entwickeln wollen
Voraussetzungen: Grundlegendes Verständnis zu Agilität z.B. Verständnis darüber, was ein Product Backlog ist
Optional: grundlegende Erfahrung in Miro für die Übungen
Schwierigkeitsgrad: Basic

Extended Abstract:

In der Softwareentwicklung werden die Anforderungen an ein Produkt häufig von Stakeholdern oder Product Owner in einem Lastenheft definiert und dann im agilen Prozess in User Stories überführt. Die Anforderungen der Nutzer werden dabei oft außer Acht gelassen, was dazu führt, dass das fertige Produkt keine Akzeptanz findet. Es geht auch anders. Der Vortrag beleuchtet, wie eine Idee für ein Produkt nutzerzentriert entsteht und methodisch gestützt mit einfachen Mitteln in ein Product Backlog überführt wird. Ein konkreter Use Case inklusive praktischen Übungen in Miro zeigt, wie die Theorie umgesetzt wird und wie die einzelnen Schritte aufeinander aufbauen.

Praxisrelevanz und Anwendbarkeit:

Das im Vortrag vorgestellte Vorgehen wurde bereits bei mehreren Kunden in verschiedenen Branchen erfolgreich angewendet.

Vermittlungsart:

Die Teilnehmer bekommen neben wertvollen Praxistipps die Möglichkeit, das vermittelte Wissen schon während des Vortrags gerne auch anhand von eigenen Use Cases zu testen.

Expertise:

Die beiden Vortragenden gestalten und halten Schulungen zu Scrum, RE sowie weiteren methodischen Vorgehensweisen und verfügen über langjährige Beratungsexpertise in der agilen Softwareentwicklung. 

Mit dem zentralen Element im populären Scrum Framework, dem fertigen Produktinkrement (jeden Sprint), stellen wir unser liebstes Hilfsmittel für eine Fokussierung in den Mittelpunkt. Wir wollen uns in Interaktion mit den Session-Teilnehmern der Frage 'was machen wir überhaupt und wozu?' widmen.

Zunächst zeigen wir auf, wie das fertige Produktinkrement als Zielsetzung und Vehikel der Auftragsklärung immer wieder Fokussierung ermöglicht. Auf dieser Basis beleuchten wir drei Ausgangssituationen für diese Fokussierung und wie sich darin Fragestellungen und Schwerpunkte wandeln:

• Ich möchte lernen ein fertiges Produktinkrement in kurzen Zyklen zu liefern!
• Ich möchte lernen das Produktinkrement zur Wertmaximierung zu nutzen!
• Ein fertiges Produktinkrement soll mir helfen, schnell Annahmen über Marktbedürfnisse zu verifizieren. Kann es auch etwas anderes sein als laufende Software?

Zielpublikum: Du bist beteiligt bei der Entwicklung von digitalen Produkten.
Voraussetzungen: Du hast von Scrum schon mal etwas gehört und mindestens ein Produkt an den Markt gebracht.
Schwierigkeitsgrad: Advanced

Extended Abstract:

Das fertige Produktinkrement (jeden Sprint) ist als Element des populären Scrum Frameworks inzwischen ein alter Hut. Es ist aus unserer Sicht und Erfahrung dennoch zeitgemäß und hilfreich als Fokusinstrument. Wir haben gute Erfahrung gemacht, es als Hilfsmittel der Auftragsklärung von Scrum Master und Agile Coaches bei der Begleitung von Teams und Organisationen einzusetzen und dadurch kontinuierlicher Verbesserung eine transparente Stoßrichtung zu geben. Als Ausblick möchten wir in Interaktion mit den Teilnehmern beleuchten, wie im heutigen Kontext, in welchem moderne Technik neue Geschäftsmodelle möglich machen, eine neue Einordnung des fertigen Produktinkrements hilfreich sein kann.

Wir haben vor 2016 ein demokratisches und partizipartives Unternehmen gegründet. Fünf Jahre später haben wir einige Höhen und Tiefen erlebt, Regelwerke gebaut und fangen an, über Strukturen zum Wachstum zu sprechen. Ein Erlebnisbericht...

Zielpublikum: Angestellte, Freie und Nixen
Voraussetzungen: none
Schwierigkeitsgrad: Advanced

Seit dem Beginn der Chaos-Engineering-Initiative beim Vertrieb der Deutschen Bahn sind inzwischen mehr als zwei Jahre vergangen. Nach gut 90 Game Days, etlichen produktionsrelevanten Findings und Überzeugungsarbeit in einem stark skalierten agilen Umfeld wissen wir, wie man sich selbst einfach mit Chaos Engineering in den Fuß schießen kann. In diesem Vortrag sprechen wir darüber, was unsere Zuhörenden tun können, um auf keinen Fall mit Chaos Engineering Erfolg zu haben.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Tester:innen
Voraussetzungen: Projekterfahrung, Testing
Schwierigkeitsgrad: Advanced

Extended Abstract:

Seit dem Beginn der Chaos-Engineering-Initiative beim Vertrieb der Deutschen Bahn sind inzwischen mehr als zwei Jahre vergangen. Nach gut 90 Game Days, etlichen produktionsrelevanten Findings und Überzeugungsarbeit in einem stark skalierten agilen Umfeld wissen wir, wie man sich selbst einfach mit Chaos Engineering in den Fuß schießen kann. In diesem Vortrag sprechen wir darüber, was unsere Zuhörenden tun können, um auf keinen Fall mit Chaos Engineering Erfolg zu haben. Das Cynefin-Framework, die sieben Network Fallacies, ein Game Day mit Beispielagenda und Scaled-Agile-Herangehensweisen sind nur einige gute Kandidaten, die viel Potential bieten, die eigene Chaos-Engineering-Initiative zu einem grandiosen Misserfolg zu machen. Nach unserer Erkundungsreise aus dem Projektalltag wissen unsere Zuhörenden, was sie selbst tun können, um zu scheitern.

Funktionale Architektur ist grundsätzlich anders als OO-Architektur:

• unveränderliche Daten
• Eingrenzung und Kontrolle von Effekten
• konsequente Abstraktion
• Einsatz von Mathematik bei der Modellierung

All dies reduziert Kopplung und führt generell zu mehr Flexibilität und Robustheit.  Der Vortrag gibt einen Kurzüberblick mit hoffentlich kritischen und provokativen Rückfragen - und den Antworten darauf.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: OO-Programmiererfahrung
Schwierigkeitsgrad: Advanced

In den letzten Jahren scheint 'Agilität' als alleinstehender Begriff aus der Mode gekommen zu sein. Neue Trends wie 'Enterprise Agility' oder 'Business Agility' sind in aller Munde. Reicht es jetzt also für Unternehmen nicht mehr, einfach nur agil zu sein? Muss es nun Business Agility sein? Und steckt hinter 'Business Agility'? 

Der Vortrag stellt 4 Dimensionen, die Business Agility ausmachen vor - und Agile Methoden sind darin nur ein Teil einer Dimension. Dafür nehmen Technologie und Kultur einen maßgeblichen Platz ein. 

Um die 4 Dimensionen anschaulich zu machen, bringen wir in den ersten 8 Minuten eine Liste von Beispielen für Ausprägungen aus der Praxis mit. In den zweiten 8 Minuten nehmen wir Fragen zu den Dimensionen entgegen oder stellen wahlweise ein Praxisprojekt vor.

Zielpublikum: Architekten, Führungskräfte, Agile Coaches
Voraussetzungen: Grundsätzliches Verständnis von Agilität
Schwierigkeitsgrad: Basic

Extended Abstract:

'Agil' und 'Agilität' sind seit mehr als 15 Jahren als Begriffe in Unternehmen immer prominenter geworden und mittlerweile nicht mehr wegzudenken. In den letzten Jahren scheint aber 'Agilität' als alleinstehender Begriff aus der Mode gekommen zu sein. Neue Trends wie 'Enterprise Agility' - zumeist jetzt als 'Business Agility' bezeichnet - sind in aller Munde. Reicht es jetzt also für Unternehmen nicht mehr, nur nach dem richtigen Maß an 'Agilität' zu streben? Muss es Business Agility sein? Und was ist dann eigentlich 'Business Agility'? 

Der Vortrag stellt 4 Dimensionen, die Business Agility ausmachen vor - und Agile Methoden sind darin nur ein Teil einer Dimension. Dafür nehmen Technologie und Kultur einen maßgeblichen Platz ein. Um die 4 Dimensionen anschaulich zu machen, bringen wir eine Liste von Beispielen für Ausprägungen aus der Praxis mit.

Die ersten 8 Minuten konzentrieren sich auf die Vermittlung des Modells. Die zweiten 8 Minuten geben die Möglichkeit für die Zuhörer relevante Fragen zu den 4 Dimensionen oder wahlweise ein aktuelles Praxisbeispiel aus einer Dimension kennenzulernen - Abstimmung dazu z.B. über Mentimeter.

Technische und fachliche Herausforderungen in hochkomplexen Umgebungen bergen große Risiken. Eine agile Herangehensweise bietet Chancen für ein nachhaltiges Risikomanagement: Kurze Feedbackzyklen, interdisziplinäre Kollaboration sowie kleines und inkrementelles Deployen reduzieren Risiken deutlich. Jedoch bringt jedes neue Feature wiederum neue unvorhersehbare Risiken mit sich. Wie geht man mit diesen Gefahren um, wenn man trotzdem eine kurze Time-to-Market einhalten möchte

Carsten Lill (Projektleiter), Jan-Torben Evers (Data Scientist) und Nils Hyoma (Agile Coach) berichten aus unterschiedlichen Sichtweisen, wie sie dieses Problem in den Griff bekommen haben. 

Sie haben gemeinsam auf der grünen Wiese eine neue Lösung mit ihren eng vernetzten Teams entwickelt.Parallel zu der Entwicklung der Dispositionssoftware haben wir eine Self-Service-Business-Intelligence-Lösung konzipiert und implementiert.

Zielpublikum: Product Owner, Projektleiter, Manager, Entscheider, Agile Coaches, Scrum Master, Architekten
Voraussetzungen: Grundlagen Scrum
Schwierigkeitsgrad: Advanced

Extended Abstract:

Risky business? Bessere Softwareentwicklung mit überschaubaren Risiken durch Feature Toggles und Self-Service BI

Technische und fachliche Herausforderungen in hochkomplexen Umgebungen bergen große Risiken. Eine agile Herangehensweise bietet Chancen für ein nachhaltiges Risikomanagement: Kurze Feedbackzyklen, interdisziplinäre Kollaboration sowie kleines und inkrementelles Deployen reduzieren Risiken deutlich. Jedoch bringt jedes neue Feature wiederum neue unvorhersehbare Risiken mit sich. Wie geht man mit diesen Gefahren um, wenn man trotzdem eine kurze Time-to-Market einhalten möchte?

Der deutsche Luftraum ist so eine komplexe Umgebung. Eine an die europäische Luftraumüberwachung (Eurocontrol) angebundene Dispositionssoftware, welche automatisch kritische Entscheidungen trifft, muss zeitnah realistische Zeitinformationen übermitteln. Werden diese Vorhersagen nicht eingehalten, droht der Verlust von begehrten Slots im Luftraum, was zu negativen Kettenreaktionen führen kann. Im schlimmsten Fall können hunderte Passagiere nicht am selben Tag zu ihrem Reiseziel gelangen. Dabei können hohe Folgekosten entstehen.

Carsten Lill (Projektleiter), Jan-Torben Evers (Data Scientist) und Nils Hyoma (Agile Coach) berichten aus unterschiedlichen Sichtweisen, wie sie dieses Problem in den Griff bekommen haben. Sie haben gemeinsam auf der grünen Wiese eine neue Lösung mit ihren eng vernetzten Teams entwickelt.

Neben gründlichen Tests der Systeme hilft die Auswertung von operativen Daten. Hierbei sind nicht etwa Logdateien, sondern die Überprüfung vorher definierter Metriken gemeint. Eine starre Data-Warehouse-Lösung oder Standard-Reports bieten hierbei jedoch nicht die notwendige Flexibilität, um ad-hoc reagieren zu können.

Parallel zu der Entwicklung der Dispositionssoftware haben wir eine Self-Service-Business-Intelligence-Lösung konzipiert und implementiert. Dabei hat das Team die Zeit zwischen den einzelnen Releases durch das verringerte Risiko sogar verkürzen können. Alle Entwickler:innen, wichtige Stakeholder, die Geschäftsführung und der Product Owner konnten jederzeit auf die Ergebnisse der Datenanalyse zugreifen und mit diesen arbeiten. Mit den Feature Toggles war es dem Scrum Team möglich, Änderungen ohne Deployment jederzeit zu aktivieren und auch wieder zu deaktivieren. In der Software vorhandene anpassbare Parameter erlauben es, die gewonnenen Erkenntnisse zur Optimierung sofort umzusetzen.

Der Entwicklungsfortschritt der jeweiligen Produktziele war durch Transparenz in Zielsetzung und Daten jederzeit überprüfbar.