Die im Konferenzprogramm der SEACON digital 2021 angegebenen Uhrzeiten entsprechen der Central European Summer Time (CEST).
Per Klick auf "VORTRAG MERKEN" innerhalb der Vortragsbeschreibungen können Sie sich Ihren eigenen Zeitplan zusammenstellen. Sie können diesen über das Symbol in der rechten oberen Ecke jederzeit einsehen.
Gerne können Sie die Konferenzprogramm auch mit Ihren Kollegen und/oder über Social Media teilen.
Der Track+ besteht aus Präsentationen der Sponsoren und unterliegt somit nicht der Qualitätssicherung des Fachbeirates.
Bitte beachten Sie, dass es für vereinzelte Workshops eine Teilnehmerbeschränkung gibt. Weitere Infos hierzu finden Sie in den Workshop-Beschreibungen.
Thema: Agile
- Mittwoch
21.04. - Donnerstag
22.04.
Ein Release-Prozess in einem großen und komplexen Wasserfallprojekt: Wenige Releases im Jahr, dafür Meilensteine, Quality-Gates, definierte Testphasen und aufwändige Übergaben, Abnahmen, Checklisten und viel Dokumentation. Geplant wird früh und detailliert. Im Vorfeld des Releases kommt es jedoch oft anders. Dazu möglicherweise unterschiedliche Entwicklungsdienstleister und viele Stakeholder und alles in allem sehr viel Kommunikationsaufwand. Wie gelingt in einem solchen Release-Prozess der Wandel für eine agile Zukunft?
Wir berichten aus unserer jeweiligen Arbeits- und Projekterfahrung und sprechen dabei über Themen wie die Analyse bestehender Prozesse und die Identifikation von Verbesserungspotenzialen, die Etablierung einer 3-Amigos-Mentalität, die Forcierung von Testautomatisierung und den Aufbau von Integrationsumgebungen. Fast-Wins wie die Einführung von Mob Testing bei der Integrationsabsicherung werden aufgegriffen.
Zielpublikum: Architekten, Projektleiter, Manager, Entscheider, Tester
Voraussetzungen: Projekterfahrung, Basics in Agilen Methoden
Schwierigkeitsgrad: Basic
Vortrag Teilen
Nach Wasserfall und den iterativen Vorgehensmodellen kam die agile Bewegung. Nun leben wir die agile Arbeitsweise und alles ist besser geworden. Oder doch nicht? Es gibt Projekte die trotzdem nicht richtig laufen? Sind wir wirklich agil geworden?
Wir haben die agile Phase längst verlassen ohne es zu wissen. Wo stehen wir? Sind wir wirklich agil oder leben wir eine andere Form von Wasserfall? Was hindert uns daran, dass doch noch nicht alles ohne Probleme verläuft. Was sind die Probleme und ihre Ursachen? Was macht unsere Arbeit aus und wonach sollten wir streben? Was sind unsere störenden Gewohnheiten und welche sollten wir ablegen?
Diese Fragen wollen wir in diesen Vortrag aufgreifen und aufschlüsseln wie wir unserer Projekte sicher für die Zukunft machen.
Zielpublikum: Developer, Scrum Master, Product Owner
Voraussetzungen: Agile Grundkenntnisse
Schwierigkeitsgrad: Basic
Vortrag Teilen
In der agilen Welt sprechen wir mit gutem Grund von Produkten. Es soll der gedankliche Wechsel von Projekt zum Produkt vollzogen werden. Das ist in vielen Kontexten auch sinnvoll, allerdings laufen wir Gefahr, auch dort Produkte sehen zu wollen, wo Projekte tatsächlich sinnvoller sind.
Der Vortrag diskutiert, wann Projekte sinnvoller als Produkte sind und wie Projekte agil durchgeführt werden können. Der Vortrag stellt dazu Techniken vor und illustriert diese mit Beispielen aus der Praxis.
Zielpublikum: Projektleiter, Scrum Master, Product Owner
Voraussetzungen: Kenntnisse zu agilen Vorgehensweisen (z.B. Scrum)
Schwierigkeitsgrad: Advanced
Stefan Roock hat seit 1999 agile Ansätze in Deutschland maßgeblich mit verbreitet und weiterentwickelt. Zunächst hat er als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner gearbeitet. Heute arbeitet er zusammen mit seinen Kollegen daran, dass Unternehmen langfristig mit agilen Denk- und Arbeitsweisen erfolgreich sind. Dabei fokussiert er auf agile Leadership.
Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, bei User Groups und in Unternehmen. Außerdem schreibt er Bücher und Artikel zu agilen Themen.
Vortrag Teilen
In der agilen Produktentwicklung unterscheidet man zwischen Discovery ('Identifizieren von Features') und Delivery ('Umsetzen von Features'). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie aber geht man damit um, regelmäßig die Flughöhe zwischen Discovery und Delivery zu wechseln und nicht in dieselben Muster wie in der Analysephase des Wasserfalls zu verfallen? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben. Und das alles bei einem festen Endtermin.
Zielpublikum: Software-Entwickler, Projektleiter, Product Owner
Voraussetzungen: keine
Schwierigkeitsgrad: Basic
Vortrag Teilen
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.
Vortrag Teilen
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
Vortrag Teilen
Vortrag Teilen
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.
Vortrag Teilen
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.
Vortrag Teilen
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.
Vortrag Teilen