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.

Daten sind Macht. Sie haben heute eine wesentliche Bedeutung, da auf ihrer Grundlage vermehrt neue Produkte und Geschäftsmodelle entwickelt und besser informierte Entscheidungen getroffen werden. Aktuelle technische Entwicklungen beginnen sich zu etablieren, um Daten in Datenökosystemen zu teilen, dabei aber als Dateneigentümer gleichzeitig auch volle Kontrolle darüber bewahren zu können. Das ermöglicht es Datenlieferanten, ihre individuellen Rechte zu wahren, und schafft die Grundlage für neue digitale Geschäftsmodelle.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Fachkenntnisse zu digitalen Produkten, Produktentwicklung, Grundkenntnisse Software-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Die Bedeutung von Daten hat in den letzten Jahrzehnten stetig zu genommen. Während Daten früher meist nur als Ergebnis bzw. Nebenprodukt eines Prozesses verstanden wurden, hat sich die Rolle von Daten geändert hin zum Wegbereiter für Prozesse und für Produkte. Häufig werden Daten heute als strategische Ressource und sogar selbst als Produkt gesehen. In Datenökosystemen werden Daten heute genutzt, um neue Geschäftsmodelle zu entwickeln und besser informierte Entscheidungen zu treffen. Endnutzer spielen hier eine kritische Rolle, weil sie als Datenlieferanten häufig weder autonom darüber entscheiden können, wer ihre Daten nutzt, verarbeitet, speichert und bewegt noch darüber informiert werden, welche Datenflüsse überhaupt stattfinden. Eine einmal getroffene Entscheidung, Daten zu teilen, kann häufig nicht mehr vollständig rückgängig gemacht werden. Die seit vielen Jahren, in Medien, gehäuft diskutierten Datenskandale haben dazu geführt, dass Misstrauen bei Nutzern entsteht, was die Entwicklung von Datenökonomien negativ beeinflusst. Datenmissbrauch ist insofern kritisch, da Daten, werden sie heute unreguliert weitergegeben oder in die falschen Hände gegeben, morgen aufgrund technischen und kulturellen Fortschrittes mehr Informationen als heute offenbaren können, was für den Einzelnen potenziell unvorhersehbare negativen Folgen haben kann. Da Nutzer in Bezug auf Datenschutz häufig irrationale Entscheidungen treffen, stehen Unternehmen umso mehr in der Verantwortung, Sorge zu tragen, die Nutzer ihrer Produkte dabei zu unterstützen, ihr Recht auf souveräne Bestimmung über die Verwendung ihrer Daten ausüben zu können. Das hat auch die Politik erkannt und Datensouveränität – eine Ebene digitaler Souveränität – als digitalpolitisches Schlüsselkonzept positioniert und die Entwicklung einheitlicher technologischer Grundlagen gefördert. Die im Vortrag vorgestellten Entwicklungen, rund um die Referenz-Architektur International Data Spaces, ermöglichen die Etablierung dezentraler Daten-Architekturen, bei der Daten in Datenmarktplätzen geteilt und Dateneigentümer verlässlich Nutzungsbedingungen an Datenlieferungen knüpfen können. Auch Projekte wie Solid, von Tim Berners-Lee, zahlen darauf ein, Nutzern die Kontrolle über ihre Daten zurückzugeben. Beide Projekte haben verschiedene Schwerpunkte, können sich bei der Ausgestaltung einer technischen Architektur aber auch sehr gut ergänzen. Ziel des Vortrags ist es, deutlich zu machen, wie aktuelle technologische Entwicklungen es möglich machen wollen, Datenökonomien zu etablieren, die auf gemeinsamen verlässlichen Regeln und Standards basieren, und wie dabei die deutlich sichtbar werdenden digitalethischen Implikationen beim Teilen von Daten effektiv adressiert werden. Außerdem soll gezeigt werden, welche neuen digitalen Geschäftsmodelle damit möglich werden und wie alle Beteiligten dabei von Fairness und Transparenz profitieren.

Datenkonvertierungen sind in fast allen Projekten ein notwendiges Übel. Egal, ob es sich um ein Legacy-System handelt oder ob einfach Daten von einem anderen System übernommen werden müssen.
Trotzdem hat man oft das Gefühl, dass immer wieder von vorne angefangen wird.
Dieser Talk zeigt neben der Planung und Vorbereitung auch einige Tipps & Tricks aus dem Projektalltag.

Zielpublikum: Entwickler:innen, Architekt:innen, Projektleiter:innen, Administratoren
Voraussetzungen: Programmierkenntnisse, Kenntnisse über Datenhaltung, allgemeine Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Ashbys kybernetisches „Gesetz von der erforderlichen Varietät“ besagt, dass die Varietät eines Steuerungssystems mindestens ebenso groß sein muss wie die Varietät der auftretenden Störungen. Da auf den Führungsebenen von Unternehmen als erfolgreiche Stereotypen meist sogenannte "Pacesetter" und "Controller" dominieren, wird klar, dass eine einfache Frauenquote zu Erhöhung der Diversität und damit der Problemlösungskompetenz von Führungsebenen in einer VUKA-Welt zu kurz greift. Der Wandel muss daher viel tiefgreifender und systemischer sein.

Zielpublikum: Manager:innen, Entscheider, Führungskräfte, Personalentwickler, HR, Organisationsentwickler, Projektleiter
Voraussetzungen: Keine speziellen Kenntnisse notwendig
Schwierigkeitsgrad: Anfänger

Extended Abstract
Der geringe Anteil von Frauen in Führungsebenen deutscher Organisationen wird gerne als Beispiel für die noch nicht vollzogene Gleichberechtigung und Chancengleichheit in unserer Gesellschaft herangezogen. Dass es sich hierbei nicht nur um ein moralisches Problem, sondern auch um ein Symptom für die mangelnde Veränderungsfähigkeit und Problemlösungskompetenz von Organisationen in einer VUKA-Welt handelt - also um kritische Faktoren ihrer Überlebensfähigkeit -, wird weniger beachtet.
So besagt Ashbys „Gesetz von der erforderlichen Varietät“ als zentrale Erkenntnis der Kybernetik, dass die Varietät eines Steuerungssystems mindestens ebenso groß sein muss, wie die Varietät der auftretenden Störungen. In einer VUKA-Welt, die Organisationen und Gesellschaft also ständig und immer schneller mit neuen und komplexeren „Störungen“ und Fragestellungen konfrontiert, brauchen wir also im Minimum eine gegengleiche Komplexität und entsprechende Diversität auf der Lösungsseite.

Diversity & Inclusion werden weitgehend nicht nur als soziale Aufgabe angesehen, sondern auch als zentrale Notwendigkeit für nachhaltigen Unternehmenserfolg. Dabei sind schon in Basisfunktionen wie einem "Mein Konto"-Bereich oftmals Fallstricke vorhanden, die auf den ersten Blick wie Hilfestellungen erscheinen. Dieser Talk zeigt einen archetypischen Kontopflege-Bereich, und wie man ihn inklusiver gestalten kann.

Zielpublikum: Entwickler:innen, UX-Designer:innen, Projektverantwortliche
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
Es ist im Grunde zwar nicht schwer, eine inklusive Erfahrung zu bauen, aber es stellt doch alle Bereiche der Produktentwicklung wieder und wieder vor unerwartete Hürden. In diesem Talk wird am Beispiel einer schlecht designten Seite aufgezeigt, wo es hier und dort haken mag, welche Kniffe es einfacher machen, eine positive Erfahrung zu vermitteln, und wie man teilweise die Inklusivität zur Stärke statt zur Schwäche machen kann.

Der CEO der Sustainable Digital Infrastructure Alliance (SDIA) Max Schulze referiert über die Inhalte und Notwendigkeit des Forschungsvorhabens “SoftAWERE”, das vom Umweltbundesamt finanziert durch das BMWi ins Leben gerufen wurde. Ziel des Vorhabens ist die Entwicklung von Kriterien und Messmethoden, um die Energieeffizienz von Software-Komponenten zu steigern und Entwickler*innen Werkzeuge an die Hand zu geben, mit denen sie nachhaltige Entscheidungen abseits von ökonomischen Parametern treffen können.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheidende
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

How will organizations keep agility alive after their initial agile transformation? The question of what happens if agile becomes daily business is even more intriguing in this post-pandemic COVID era. Will AGILE survive these unparalleled insecure times? Participants in this workshop will explore what is needed to sustainably ‘safeguard’ an enterprise agile delivery culture after the initial ‘agile transformation’. The workshop hosts will share their observations of working in a big financial organization and will invite participants to share theirs so that collectively, we can gain insight and define potential countermeasures.

Target Audience: Anyone interested in transformational agility challenges, e.g. Change Lead, Coach, BusArchitect
Prerequisites: None
Level: Advanced

Extended Abstract
Participants in this workshop will explore what is needed to move forward after the initial ‘agile transformation’, to sustainably ‘safeguard’ an enterprise agile delivery culture. The question of what happens if agile becomes daily business is even more intriguing in this post-pandemic COVID era. How will organizations keep agility alive after their initial agile transformation? When organizational systems come under too much pressure; how ‘VUCA’* resistant are our agile enterprise cultures?
Lieke Jansen and Eric Abelen are senior Agile Enterprise Coaches at ING in the Netherlands. They both contributed to ING's Spotify inspired, big-scale transformation towards an agile way of working, some seven years ago. As of then, they have successfully coached a wide variety of departments and organizations within ING to adopt and sustain an effective healthy agile delivery culture. Being key players of a massive enterprise agile transformation, they also observe some challenges related to upkeep of the resulting way of working. Because people come and go, and in our VUCA world business and process change is frequent. What options do we have in this reality of ongoing change to keep the ‘agile enterprise culture’ strong and resilient?
Also, in the Covid pandemic we learned that people and organizations can respond to change quickly, especially those organizations that adopted a culture of agility. But after a period of unparalleled social restrictions, how does this affect our agile corporate cultures? Has the trauma of the pandemic infected us with a renewed urge to feel ‘in control’ of the future and has this irrevocably injured our appetite for organic growth and agility?
In this workshop we will explore this interesting and urgent question together with you. We will share key observations from experience working with a wide variety of delivery and leadership teams and their related organizational structures. We hope that workshop participants are willing to add their observations and experiences to ours. In interactive dialogue sessions we hope to collectively engage in sense-making and to define basic anti-patterns and growth-paths.
( * VUCA = Volatility, Uncertainty, Complexity, Ambiguity)

Mit Hilfe moderner KI-Ansätze wie GPT-2, Tacotron und Conformers haben wir Roboterköpfe entwickelt, die vollständig autonom unter sich eine Kommentarspaltendiskussion führen und somit menschliches Mitdiskutieren überflüssig machen. Das TNG Innovation-Hacking-Team hat einen Prototyp eines Ende-zu-Ende-Systems für Natural Language Understanding entwickelt, bei dem Techniken wie Speech-to-Text (STT), Conditional Text Generation und Text-to-Speech (TTS) zum Einsatz kommen.

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

Extended Abstract
Mit Hilfe moderner KI-Ansätze wie GPT-2, Tacotron und Conformers haben wir Roboterköpfe entwickelt, die vollständig autonom unter sich eine Kommentarspaltendiskussion führen und somit menschliches Mitdiskutieren überflüssig machen. Das TNG-Innovation-Hacking-Team hat einen Prototyp eines Ende-zu-Ende-Systems für Natural Language Understanding entwickelt, bei dem Techniken wie Speech-to-Text (STT), Conditional Text Generation und Text-to-Speech (TTS) zum Einsatz kommen.
Kommentarspalten in sozialen Medien sind zum vorherrschenden Schauplatz des öffentlichen Diskurses geworden. Diskussionen auf Facebook, Twitter oder Reddit sind jedoch berüchtigt für ihre primitive Debattenkultur und Ergebnislosigkeit. Die offensichtliche Lösung für diese enorme Zeitverschwendung ist die vollständige Automatisierung solch fruchtloser Debatten mittels eines Bots.
In diesem Vortrag zeigen wir verschiedene Kernkonzepte des NLP. Anhand von Live-Demos führen wir Sie durch das Scraping von Social-Media-Kommentaren, das Training eines Sprachmodells, die Synthese von Tausenden Stimmen und die Konstruktion von IoT-Roboterköpfen.

KI und insbesondere Deep Learning sind der Megatrend. Dank leistungsstarker Frameworks sind erste Schritte schnell gemacht. Leider stößt man aber genauso schnell auch wieder an (seine) Grenzen. Passt das genutzte Modell überhaupt zu meinem Problem? Wie sind die gewonnenen Ergebnisse zu bewerten? Kann durch geschickte Veränderung von Modell-Parametern das Ergebnis weiter verbessert werden? In der Session werden wir unser eigenes Neuronales Netz von Grund auf aufbauen und Schritt für Schritt verbessern. Aber keine Angst: „it’s not rocket science“!

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

Extended Abstract
Die verschiedenen KI-Frameworks machen es dem Anwender - auch ohne tiefgehendes Verständnis - relativ einfach, erste einfache KI-Modell aufzusetzen. Leider kommt der erste Frust aber mindestens genauso schnell. Denn nur wenn man die grundlegenden Prinzipien verstanden hat, die sich unter der Haube eines solchen Modells abspielen, wird man auch in der Lage sein, dessen Parameter sinnvoll zu "pimpen". Man sollte also auch als Nicht-Mathematiker die Grundlagen Neuronaler Netze und ihrer wesentlichen Parameter verstanden haben.

Gamification bringt Spaß in den Projektalltag. Aber lohnt es sich überhaupt?
Um dies einschätzen zu können, geben wir einen Überblick über verschiedene spielerische Ansätze, die auf die Qualitätssicherung von Software fokussieren.
Wir gehen darauf ein, wie man Gamification gezielt und im richtigen Maß in Projekte einführt, welche Schwerpunkte gesetzt werden sollten und wie skeptische Kollegen überzeugt werden können.
Damit kann der Vortrag als Entscheidungsgrundlage dienen. Richtig eingesetzt, lohnt sich Gamification!

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

Extended Abstract
Spielerische Ansätze in der Software-Entwicklung sind nicht neu und finden immer häufiger ihren Platz im Projektalltag. Doch kosten diese nicht einfach nur Zeit und Geld? Bringt es überhaupt Vorteile, das Team „spielen“ zu lassen? Und wie misst man Erfolg oder auch das Scheitern einer Spielidee?
Wir zeigen am Beispiel von Gamification-Ansätzen in der Qualitätssicherung, dass diese das Potenzial haben, nicht nur den Projektalltag aufzulockern und den Teamzusammenhalt zu stärken, sondern auch die Softwarequalität spielend zu verbessern. Gezielte Produktverbesserung, z. B. durch Bug-Hunting, wird ebenso adressiert wie systematische Prozessverbesserung, z. B. durch Maturity Poker.
Voraussetzung ist, dass Gamification gezielt eingesetzt wird, um effizient zu sein. Der spielerische Ansatz muss zum Team und zum Projekt passen, Schwächen beheben und auf Lösungen für bestehende Probleme fokussieren.
Der Vortrag will eine Entscheidungshilfe geben, wann sich spielerische Ansätze lohnen und wann man eher auf sie verzichten sollte. Denn nur, wenn sich Erfolge einstellen und Gamification das Projekt voranbringt, stehen alle Beteiligten hinter dem Vorgehen, und die investierte Zeit ist nicht „verspielt".

Schon von Quarkus gehört, dem neuen und effizienten JVM-Framework? Das - nicht unerfolgreich - etablierten Frameworks wie Spring Boot Konkurrenz macht?
Und bist Du daran interessiert, wie man eine Quarkus-App erstellt und - noch wichtiger - Teile davon isoliert testet?
Interessiert? Dann lass mich von unseren Erfahrungen berichten, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

Zielpublikum: Developers
Voraussetzungen: Basic knowledge about JVM languages, JVM frameworks and the microservice architecture pattern
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das relativ junge Quarkus konnte sich zu einem ernst zu nehmenden Konkurrenten für etablierte Microservice-Frameworks wie Spring Boot entwickeln. Das liegt insbesondere daran, dass das leistungsfähige und dennoch leichtgewichtige JVM-Framework es schafft, Startzeiten und Speicherverbrauch von Anwendungen erheblich zu reduzieren. Damit ist es nicht nur für die Entwicklung von Microservices in containerisierten Cloud-Plattformen wie Kubernetes interessant, sondern auch für Serverless Computing.
Und es unterstützt meine Lieblings-Programmiersprache: Kotlin!
Wenn man eine Anwendung mit Quarkus und Kotlin entwickelt, kommt man früher oder später (hoffentlich früher ;-) ) nicht umhin, isolierte Tests zu schreiben. Nur so lässt sich bekanntermaßen automatisiert feststellen, ob sich der Anwendungscode wie erwartet verhält. Und als Kotlin-Entwickler will man dazu bekannte Technologien wie z. B. JUnit und MockK nutzen. Es gibt dabei aber einige wesentliche Aspekte, die beim Testen und Mocking von CDI-Beans in Quarkus beachtet werden müssen.
Interessiert? Dann habt teil an unseren Erfahrungen, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

C++20 is now a year old. Time to take a closer look at the benefits you get when using C++ for standards 11 to 20. You learn about Coroutines by building a coroutine-based parser. The new ranges and the spaceship operator help you write less code. You will learn how Concepts help you to express constraints better and improve error messages. Doing things at compile-time saves run-time. Let‘s see how C++20 improves your code with the new features consteval and constinit. After this talk, you learned some C++20 features and saw the improvements to C++17 code.

Target Audience: Developers
Prerequisites: Knowledge about at least C++11
Level: Advanced       

Extended Abstract
C++20 is now a year old. The major compilers already provide a solid support for the new standard. It is time to take a closer look and figure out the benefits you get when using C++20. Because there are so many improvements in C++20, we will focus on: Concepts, Coroutines, ranges, the spaceship operator, and compile-time evaluation.
Coroutines are the feature that likely will have a strong impact on future finite state machine code. In a brief tour, we will see what we need to do for building a coroutine-based byte-stream parser and how this code is so much more beautiful than without Coroutines.
Less code is always a good thing. The new ranges part of the STL helps us achieve this goal. We will take a brief look at how ranges simplify our code.
Speaking about less code, how about writing a class with all comparison operations without having to write an awful amount of boilerplate code? Sounds good? Then let's see how C++20 helps us there with the spaceship operator.
And while we are speaking about less code, generic programming comes to mind. Concepts give us a whole new way to express constraints and requirements in generic code. Concepts make our code better readable while, at the same time, give us way better error messages.
We don't stop there. Together we will look at the updates to the compile-time world. With consteval and constinit we have two new keywords allowing us new things to do. A lot of former restrictions of constexpr functions were dropped as well. The most popular is probably the ability to dynamically allocate memory at compile-time. We will explore these features using some practical examples.
After this talk, you will have seen the probably most impactful features of C++20. You learned by examples how to use them. The comparisons to pre-C++20 code give you a good understanding of what your benefits are by using C++20.

Bisher gilt die gesetzliche Mindesteffizienz nur für Hardware. Aber auch die Software hat Einfluss auf die Begrenzung der Nutzungsdauer oder den gestiegenen Energieverbrauch. Es ist Zeit, dass Anforderungen an die Effizienz der Verarbeitung, Speicherung & Übertragung der Daten auch für Software gestellt werden. Wie kann man die Umweltverträglichkeit von Software erkennen & messen? Welche Umweltlasten entstehen durch Cloud-Dienstleistungen (s. z.B. Video-Konferenzen oder Streaming)? Der Vortrag wird unter anderem diese Fragen beantworten.

Extended Abstract
Die Grundtechnologie der Digitalisierung ist das Internet und der Rohstoff dabei sind die Daten, die bei jedem Kontakt mit den vernetzten Geräten erfasst und in der Cloud und somit in Rechenzentren verarbeitet werden. Diese Cloud besteht eben nicht, wie Wolken, aus feinen Wassertröpfchen, sondern aus handfesten elektronischen Komponenten, die aus wertvollen Rohstoffen hergestellt und für deren Betrieb viel elektrische Energie erforderlich ist. Gleiches gilt für die vernetzen Geräte, die nur durch die elektronischen Komponenten in der Lage sind zu kommunizieren. Die Software ist die eigentliche Königin in dieser elektronischen Welt. Sie steuert die Hardware und sie speichert die Informationen als elektronische Daten. Sie ist maßgeblich dafür verantwortlich wie energie- und hardwareintensiv eine Funktion ausgeführt wird. Und sie verantwortet zum großen Teil auch die begrenzte Nutzungsdauer der Geräte.

Bisherige gesetzliche Anforderungen an die Mindesteffizienz gelten nur für die IT-Hardware. Das kann ungeahnte Folgen auf den Stromverbrauch und die Nutzungsdauer haben. Die Software hat mindestens einen ähnlich großen Einfluss auf die Energie- und Hardwareeffizienz der Informationsverarbeitung. Jüngste Beispiele zeigen den Einfluss von Softwareupdates auf die Begrenzung der Nutzungsdauer oder auf den plötzlich gestiegenen Energieverbrauch nach einem Software-Update. Es ist somit an der Zeit, dass Anforderungen an die Effizienz der Verarbeitung, Speicherung und Übertragung der Daten auch für Software gestellt werden. Doch wie kann man die Umweltverträglichkeit von Software erkennen und schließlich wie messen? Welche Umweltlasten entstehen durch Cloud-Dienstleistungen, wie die Teilnahme an einer Video-Konferenz oder das Streamen der Lieblingsserie? Der Vortrag wird unter anderem diese Fragen beantworten.

Im Zeitalter der Smartphone-Apps sehen sich viele Entwickler:innen dem immer wieder gleichen Problem ausgesetzt: Wie synchronisiert man Daten zwischen den verschiedenen Clients? Vom Telefon, was zeitweilig offline sein kann, zum Tablet, was überhaupt nur im WLAN hängt, zur Weboberfläche. Auf keinen Fall darf man dem User Konflikte anzeigen, die verwirren nur! “Konfliktfreie verteilte Datentypen” sind die Lösung; eine recht junge Technologie, die verspricht, alle diese Probleme anzugehen

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundkenntnisse Web-Entwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Im Zeitalter der Smartphone-Apps sehen sich viele Entwickler*innen dem immer wieder gleichen Problem ausgesetzt: Wie synchronisiert man Daten zwischen den verschiedenen Clients? Vom Telefon, was zeitweilig offline sein kann, zum Tablet, was überhaupt nur im WLAN hängt, zur Weboberfläche. Auf keinen Fall darf man dem User Konflikte anzeigen, die verwirren nur! Und das alles bitte auch mit Historie und effizient, um Bandbreite zu sparen. Können wir das schaffen? “Konfliktfreie verteilte Datentypen” sind die Lösung; eine recht junge Technologie, die verspricht, alle diese Probleme anzugehen. Dieser Vortrag soll ein Rundgang durch die Forschung & Praxis geben und die (wenigen) Haken aufzeigen.

Ü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.

While Rust is typically pitched as systems programming language, it is equally adept at application development thanks to its high level features and great tooling. In addition to increased performance, native code has the advantage that it can easily be reused across different system components, an advantage even more pronounced in polyglot environments. In this talk, we would like to present our experience of using Rust to write core components in such a polyglot system.

Target Audience: Architects, Developers
Prerequisites: Basic knowledge of Python, Java
Level: Advanced

Extended Abstract
While Rust is typically pitched as systems programming language, it is equally adept at application development thanks to its high level features and great tooling. In addition to increased performance, native code has the advantage that it can easily be reused across different system components, an advantage even more pronounced in polyglot environments.
In this talk, we would like to present our experience of using Rust to write core components in such a polyglot system. The systems spans different contexts, from client to cloud, and different programming languages, from Python to Java, respectively. We will showcase how the Rust language itself and its tooling simplified this task and discuss different integration patterns.

Women in technology leave the industry at a higher rate than any other profession. In her invited talk, Nicola Marsden draws on deep research into what women love about work and what they don’t. Together with Karen Holtzblatt, the visionary behind Contextual Design, she has developed a research-driven framework and best-practice interventions to achieve better retention and work life culture for women in technology. She presents the framework and looks at Scrum as an example in terms of challenges and benefits for women.

Target Audience: Managers, Decision Makers, Agile Coaches, Project Leaders, Developers
Prerequisites: Interest :-)
Level: Basic

Die Vergabe von Softwareprojekten und Umsetzung durch Dritte ist ein übliches Verfahren im Umfeld der öffentlichen Hand. Es handelt sich dabei oft um Projekte mit langer Lebenszeit, für die zwar hohe Anforderungen an Wartbarkeit bestehen, aber oft nicht erfüllt werden. Der Vortrag beschreibt Erfahrungen des ITZBund beim Aufbau entsprechender Qualitätssicherungsmaßnahmen. Es werden Möglichkeiten und Grenzen von Coding-Standards sowie Architektur-Vorgaben, deren automatisierte Überprüfung und das Zusammenspiel mit Auftragnehmern beleuchtet.

Zielpublikum: Architekt:innen, QA-Verantwortliche, Entscheider
Voraussetzungen: Software-Architektur, Softwarequalität, Projekterfahrung
Schwierigkeitsgrad: Experte

Was, wenn der Prozess, in den man sich verliebt hat, nicht zur Organisation passt? Unternehmen umbauen? Prozess zurechtbiegen? Vernunftehe führen? Unreflektierte Nutzung des “bildhübschen Scrum” führt oft zu Kündigungswellen, Unzufriedenheit und Burn-out, ohne die erhoffte Glückseligkeit. Muss das so sein?
Scrum ist manchmal die “passende Lösung” – aber kaum jemand beschreibt die Bedingungen dazu und es gibt wenig Aussagen darüber, wie man handeln könnte, wenn die Bedingungen nicht passen. Deswegen versuchen wir das mal.

Zielpublikum: Menschen, die nach einem Weg aus ihrer Scrum-Hölle suchen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Was tun, wenn der Prozess, in den man sich verliebt hat, weder zur Ablauf- noch zur Aufbauorganisation passt? Das Unternehmen umbauen? Den Prozess zurechtbiegen? Doch eine Vernunftehe führen?
Eine unreflektierte Nutzung des “bildhübschen Scrum” führt in immer mehr Unternehmen zu Kündigungswellen, Unzufriedenheit, unwesentlich besserer Produktivität und teilweise sogar zu Burn-outs, nur leider ohne die erhoffte Glückseligkeit.
Aber muss das so sein? Wir meinen: Das muss nicht so sein und das sollte nicht so sein.
Scrum ist nur unter bestimmten Bedingungen “die passende Lösung” – aber kaum jemand beschreibt heute noch diese Bedingungen und vor allem gibt es wenig Aussagen darüber, wie man denn handeln könnte, wenn die Bedingungen nicht passen.
Wir betrachten noch mal die Grundlagenarbeit zu Scrum und beschreiben, was die aus unserer Sicht wichtigsten der Rahmenbedingungen, für die Scrum entworfen wurde, sind.
Und wir stellen vor, für welche der fehlenden Vorbedingungen es gute alternative Ansätze gibt und zeigen, wie einige davon genutzt werden könnten.

Today Computer vision has taken a significant spot in our phones, our roads, our markets that we don’t always even recognize if and where it is deployed. Nonetheless, our industries today have so much potential to automate (using CV) their recurrent tasks to reduce costs, while simultaneously increasing quality of the product and efficiency of the process itself. We will learn about some interesting industrial examples which benefit first-hand from simple automation and perhaps get inspired by it.

Target Audience: Software Developers, Data Scientists, AI Engineers, Managers, Project Leader, Decision Makers
Prerequisites: None
Level: Advanced

Extended Abstract
In the era of Industry 4.0, we are focusing on digitalizing operations using data. We let cameras ‘see’, detect and classify objects and even take some decisions for us. In this talk, we discuss what is Computer Vision (CV), and learn how could different industries benefit / save recurring costs from it. We will discuss some interesting industrial applications of Computer Vision, for you to get some inspiration on how it can potentially help your company grow, or just to understand the advancements in today’s world.
In these 45 mins, we discuss how CV can:
- automate the industrial processes
- be more then more efficient,
- ensure the product quality,
- or detect anomalies.
Using some demos and videos you’ll get the chance to consolidate the knowledge acquired during the talk.

<provocative statement>Manuelles Testen ist die Abarbeitung einzelner definierter Testschritte. Hierfür benötigt es keine speziellen Skills, wir brauchen nur Click-Monkeys – oder?!</provocative statement
<mind change>Falsch! Wir müssen den Menschen in den Fokus stellen. Manuelles Testen sollte vielmehr als “Human Testing” betrachtet werden. Die Tester:innen nutzen all ihre Stärken zum Durchführen der Tests - eigenständiges Denken, neue Ideen entwickeln, sowie kollaborative Ansätze stehen hierbei im Zentrum des „Human Testing“.</mind change>

Zielpublikum: Tester:innen, Testmanager, Product Owner, Scrum Master, Stakeholder
Voraussetzungen: Grundlegende Kenntnisse im Testing
Schwierigkeitsgrad: Anfänger

Extended Abstract
In vielen Projekten erleben wir immer mehr, dass manuelles Testen nur als Abarbeitung diverser Testfälle gesehen wird. Hierfür werden lediglich “dumme” Click-Monkeys benötigt, Tester:innen die Testfälle Schritt für Schritt durchführen und diese nicht hinterfragen.
Aus unserer Erfahrung ist dies ein Unding, setzt die Leistung der Tester:innen herab und verschwendet wertvolle Ressourcen. Die einfache Abarbeitung von Testschritten kann in der Regel automatisiert werden.
Durch den erhöhten Automatisierungsgrad wird mehr Kapazität für den/die Tester:in geschaffen. Manuelles Testen suggeriert die oben beschriebene Abarbeitung einzelner Testschritte, wohingegen Human Testing mehr den Wert des Menschen in den Mittelpunkt rückt. Hierbei kann er/sie seine/ihre Stärken voll ausspielen und zum Beispiel in Testing Sessions auch mal über den Tellerrand hinausschauen, um eigenen Testideen zu folgen oder sich in Themen zu explorieren (beispielsweise via Testing Touren).
Human Testing rückt nicht nur den Menschen in den Mittelpunkt, sondern drückt auch die Wertigkeit des Testens aus. Es ist eben nicht nur die Durchführung manueller Testfälle, sondern vielmehr eine vertrauensvolle Zusammenarbeit mit Fokus auf Qualität.
In unserem Vortrag erläutern wir zum einen die Vorurteile gegenüber manuellem Testen, die uns in unzähligen Projekten begegnet sind, sowie mögliche Ansätze, wieso das manuelle Testen zukünftig als Human Testing zu betrachten ist. Ebenso zeigen wir auf, welchen Standard wir im Testing zwingend erreichen müssen, so dass die Rolle des Testers den verdienten Respekt erhält.

C++ class design has been error prone since the beginning, until Scott Meyers told us about the Rule-of-Three. But even that is not enforced by the language. In addition, C++11 changed the set of compiler-provided special member functions and the intrinsic rules have become more complicated. However, instead of starting from the rules for special member functions, we will look at what role a class type plays and how that maps on what special member functions to define and how, if any. Examples for class roles are Value, Relationship, Manager (scoped, unique, general), Mix-in.  

We will also look at the roles of member variable types that influence or imply the role of the class type. The role of a class will also take out many mysteries of move operations and will lead to clear guidance when and how to provide move operations: for suppressing copying, for managing unique ownership (Unique Manager) or for optimizing object copies (General Manager). We will rehearse the Rule of Zero and learn more about the Rule of Five/Six, the Rule of DesDeMovA, and the Rule of Unique Three. This all will enable you to much more consciously and safely design your class types and combine types of member variables. You will have then the ability to select from a few reasonable combinations from the plethora of possibilities of special member function combinations: {public:,protected:,private:} x {destructor, default constructor, copy constructor, copy assignment, move constructor, assignment} x {noexcept(true),noexcept(false)} x { =default, =delete, {/body/}, not declared } (math as homework)

Target Audience: Developers
Prerequisites: C++ class design
Level: Expert

Many of us have a rough idea of what side-effects are and a vague sense that they're bad. It's a shame we're not more precise about it, because when you really understand side-effects you have an excellent new lens through which you can judge individual blocks of code, larger architectural patterns, and even whole system designs. So let's start by clarifying our understanding of what side-effects are and how to spot them. We'll see how easily they arise, leaving code that's harder to understand, harder to test and harder to decouple. Then we'll look at tools and techniques for eliminating those side-effects where it's possible and managing them where it isn't. Finally we'll zoom out to see how those ideas get expressed in every field of computing, yielding fundamentally different approaches to programming language design, DevOps, system architecture, and database design. There's an iceberg of complexity hiding in your systems' side-effects and by the end of this talk you'll be able to spot it and start tackling it, rethinking the way we deal with data and the systems around it."
 

Software is often resistant to modernization efforts, no matter if it's about phasing out obsolete technologies, migration to the cloud, or establishing modern architecture. The culprit is usually a dependency or obsolete assumption that's too closely coupled to the codebase. But what's the underlying root cause of all that coupling? Often, it's shared, mutable, synchronous state. We will look at a real-world project, and we'll dig ourselves out of the hole it's dug itself into using refactoring, event sourcing, and functional programming.

Target Audience: Architects, Developers
Prerequisites: Some programming
Level: Basic

Extended Abstract:
As shared mutable state is the core paradigm of object-oriented programming, it tends to be ubiquitous in OO projects. How to avoid it then? The example has followed a familiar path: Convenient tooling allowed the project to get off the ground fast, but tied it to its underlying technologies. By the time support for those technologies has expired, coupling has gotten so strong that huge resources are expended on keeping things going "just one more day". If you've seen projects like this hit a wall, this talk is for you.

"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 today’s software-driven world, the integrity of software assets isn’t just a regulatory and compliance requirement, it’s critical for maintaining trust and avoiding irreparable damage to your brand and reputation. We found that Compliance, Software Chain of custody and in-App Security as well as API Security are seen as an overburdened bureaucracy. But they have to be part of your software value stream. So the question is, how they can be so lean, automated and optimized that they can contribute actual value inside your DevSecOps Approach?

Target Audience: Architects, Developers
Prerequisites: Project development experience
Level: Advanced

Extended Abstract
In today’s software-driven world, the integrity of software assets isn’t just a regulatory and compliance requirement, it’s critical for maintaining trust and avoiding irreparable damage to your brand and reputation.
The same also applies to Quality, In-App Security, and API Security in a more and more digitized world.
In a lot of case studies, we found that Compliance, Software Chain of custody and in-App Security as well as API Security are seen as an overburdened bureaucracy. But in all cases, they have to be part of your software value stream.
So the question is, how they can be so lean, automated, and optimized that they can contribute actual value inside your DevSecOps Approach? In the lecture we provide some key insight in how to solve that dilemma and integrate them into your day-to-day work.

Durch die Gender- und Diversity-Debatte der letzten Jahre sind wir sensibel geworden für den Einsatz einer genderneutralen Sprache und doch fehlen uns manchmal die richtigen Worte oder wir fragen uns: Brauchen wird das wirklich?
In diesem Talk schauen wir uns an:
• Wie kann inklusive Sprache überhaupt aussehen?
• Welchen Einfluss hat unser Denken auf unsere Sprache und unsere Sprache auf unser Denken?
• Welche Auswirkungen haben Sprache und Diversität auf unsere tägliche Arbeit, auf die Anforderungserhebung und das UX-Design?

Zielpublikum: Alle, die sich mit der Frage beschäftigen, ob und wie sie gendergerechte Sprache benutzen wollen
Voraussetzungen: Offenheit
Schwierigkeitsgrad: Anfänger

Extended Abstract
Wann immer wir als Menschen zusammenkommen, suchen wir eine gemeinsame Sprache. In der Regel sind wir uns schnell einig, ob wir Deutsch, Englisch, Mandarin oder Hindi sprechen wollen. Viel schwerer tun wir uns hingegen mit dem bewussten Einsatz einer inklusiven Sprache. Durch die Gender- und Diversity-Debatte der letzten Jahre sind wir sensibler geworden, sehen oft die Notwendigkeit dafür und doch fehlen uns manchmal die richtigen Worte.
Wie sorgen wir dafür, dass jede*r KollegIn und Kunde_in sich in ihrer/seiner Sprache angesprochen fühlt? Wie schreiben wir unsere Dokumente? Worauf achten wir in unserer Software und im UX-Design? Legen wir Standards fest oder fangen wir einfach mal an?
Und: Ist dieses Gendern nicht ziemlich mühsam? Brauchen wir das wirklich?
In unseren Teams arbeiten Menschen zusammen, die verschieden sind in ihrem Geschlecht, ihrer Herkunft, ihrer Ausbildung, ihrer Erfahrung. Wie können wir diese Vielfalt nutzen?

• Wie kann inklusive Sprache aussehen, wie finden wir gemeinsam einen guten Weg dorthin?
• Wie verändert unser Denken unsere Sprache und unsere Sprache unser Denken?
• Welche Auswirkungen hat das auf unsere Anforderungsanalyse oder das UX-Design?

Dieser Talk besteht aus einem Mix aus persönlicher Erfahrung und sprachwissenschaftlichem Hintergrund mit einem Exkurs zu Anforderungsanalyse und UX-Design.

arc42 ist gerade in Version 8 erschienen - Zeit für eine Übersicht der Neuerungen „am lebenden System“: Primär geht's um die Lösungsstrategie, Querschnittskonzepte und Architecture Decision Records. Zusätzlich gibt's die acht wichtigsten Praxistipps für bessere Architekturdokumentation. Insbesondere das Thema "Nachdokumentation" greife ich auf - mit anschaulichen Praxisbeispielen. Schließlich zeige ich Ihnen die Möglichkeiten der "Hilfe zur Selbsthilfe" der neuen arc42 Doku-Website.

Zielpublikum: Architekt:innen, Entwickler:innen, alle, die mit technischer Dokumentation zu tun haben
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das (open-source) arc42-Template, erstmalig erschienen 2005, ist zu einem in vielen Branchen und Organisationen etablierten Hilfsmittel für die Kommunikation und Dokumentation von Software-Architekturen geworden. Passend zu frischen "V8" von arc42 bekommen Sie in diesem Vortrag die aktuellen Änderungen „am lebenden System“ erläutert.
Parallel dazu gebe ich Ihnen die 8 wichtigsten Tipps für pragmatische und zeitgemäße Architekturdokumentation - konkret und praxisnah. Diese Tipps beziehen sich unter anderem auf Lösungsstrategie, Qualitätsanforderungen, Querschnittskonzepte sowie Architektur-Entscheidungen.
Insbesondere erkläre ich Ihnen ein paar geschickte Möglichkeiten der Nachdokumentation - Wie Sie von Null auf eine angemessene Doku kommen, ohne einen lästigen Doku-Sprint einlegen zu müssen.
Und schließlich erleben Sie live die Möglichkeiten der "Hilfe zur Selbsthilfe": Bei den über 300 Tipps, Ratschlägen und FAQs sollte auch für Ihr System etwas zu finden sein.
Zielgruppe: Alle IT'ler, die bereits unter schlechter Architekturdokumentation gelitten haben und/oder Vorsätze für bessere Dokumentation gefasst haben.
## Lessons learned vom Vortrag
* arc42 Version 8: Was ist neu, warum eine neue Version, wie kann ich migrieren
* Wie ich ein bestehendes System effektiv und mit überschaubarem Aufwand dokumentieren kann
* Wie die Teile von arc42 inhaltlich zusammenhängen, und was mir das an Synergien bringt.

Softwareplattformen bieten eine Reihe attraktiver Vorteile: Mit ihnen können neue Produkte nicht nur schneller und kostengünstiger entwickelt, sondern auch neue Einnahmequellen erschlossen werden. Dazu ist es aber notwendig, sie nicht nur richtig zu entwickeln, sondern auch effektiv zu managen. In unserem Vortrag stellen wir Techniken vor, um Plattformen dauerhaft erfolgreich zu nutzen. Dies beinhaltet, eine Plattform als eigenständige Produkt zu managen, einen dedizierten Platform Owner zu benennen und ein Nutzer-zentriertes Mindset zu etablieren.

Zielpublikum: Product Owners, Produktmanager, Architekten:innen, Entscheider (Head of Product, Head of Development)
Voraussetzungen: Kenntnisse agiler Methoden
Schwierigkeitsgrad: Fortgeschritten

Machine Learning-Diskussionen drehen sich oft um Datenbeschaffung, geeignete Werkzeuge und Modelle. Und natürlich um beeindruckende Anwendungen von Spotify, Tesla und Co. Doch wie entstehen ML-Lösungen? Oft scheint Genialität und Zufall bestimmend, doch in dieser Session zeige ich, was wirklich hinter erfolgreichen ML-Vorhaben steckt und wie man erfolgreich professionalisiert. Mit den Überschriften der Architektur-Disziplin sortiere ich die Herausforderungen von ML-Vorhaben und zeige, wie man mit ML nicht nur experimentiert, sondern arbeitet.

Zielpublikum: Entwickler:innen, Architekte:innen, ML-Interessierte, Management
Voraussetzungen: Erfahrung in der Entwicklung von Systemen
Schwierigkeitsgrad: Anfänger

Extended Abstract
Machine Learning-Diskussionen drehen sich oft um Datenbeschaffung, geeignete Werkzeuge und gut verallgemeinernde Modelle. Und natürlich um die beeindruckenden Anwendungen, die Spotify, Facebook, Tesla und andere Firmen bauen. Doch wie entstehen ML-Lösungen eigentlich? Oft scheint Genialität und Zufall bestimmend, doch in dieser Session werfen wir einen Blick darauf, was wirklich hinter erfolgreichen ML-Vorhaben steckt und was es zu bedenken gibt, wenn man Machine Learning professionalisieren möchte.
Mit der Architektur-Brille durchleuchte ich die Gemeinsamkeiten und Unterschiede zu klassischen Softwareprojekten und arbeite neun wichtige Architektur-Themen im Machine Learning-Bereich heraus. Dabei geht es um Entscheidungen zum Technologiestack, aber auch um Zielumgebungen, bzw. den Weg dort hin, methodische und organisatorische Aspekte sowie die Integration von ML-Lösungen in eine Systemlandschaft.
Die Teilnehmer lernen nicht nur fundierte über eigene Vorhaben nachzudenken, sondern sehen auch die neuen Herausforderungen, die Machine Learning mit sich bringt. Abgerundet wird die Session durch einen groben ML-Prozess, der diese Herausforderungen gut aufgreift.

Wenn ein System wächst, wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suiten, die Stunden oder Tage laufen. Das ist lähmend langsam. Wenn die Ausführung aller Tests zu lange dauert, kann man einen Teil der Tests häufiger ausführen als den Rest. Der Schlüssel ist, diese Teilmenge so zu wählen, dass sie in einem Bruchteil der Zeit einen Großteil der Fehler findet. Im Vortrag stellen wir verschiedene Ansätze hinsichtlich Kosten, Nutzen und Anwendbarkeit und Erfahrungen aus Forschung und Praxiseinsatz vor.

Zielpublikum: Entwickler:innen, Tester:innen, Verantwortliche für Entwicklung und Test
Voraussetzungen: Interesse an Software-Test
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Mit dem Alter und der Größe eines Softwaresystems steigt typischerweise der Bedarf für ausgiebige und qualitativ hochwertige Software-Tests. Zudem werden für mehr Anwendungscode auch mehr Tests benötigt. Damit steigt die Ausführungszeit der Tests.
In der Praxis führt das immer häufiger zu Test-Suiten, die Stunden bis Tage brauchen, um einmal zu laufen. Das bringt eine Reihe von Problemen mit sich. Für die Entwickler bedeutet es, dass sie Feedback für den geänderten Code erst eine lange Zeit, nachdem sie die Änderungen gemacht haben, bekommen. Das macht es deutlich schwieriger, die Fehler im Code zu finden und zu beheben. Außerdem werden moderne Verfahren, wie zum Beispiel Continuous Integration dadurch deutlich erschwert. All das mindert den Wert der Tests ausgerechnet für die Systeme, in denen sie absolut essenziell sind, nämlich große komplexe Software-Systeme.
Eine naheliegende Lösung für das Problem ist es, einen Teil der Tests häufiger auszuführen, als den Rest. Die Herausforderung dabei ist, diese Teilmenge an Tests so zu bestimmen, dass man möglichst viel Zeit einsparen kann, ohne die Fähigkeit der Tests, Fehler zu finden, erheblich zu mindern. Um das zu erreichen, gibt es verschiedene Ansätze, von denen jeder Vor- und Nachteile mit sich bringt.
Ein Ansatz ist die Test-Suite-Minimierung. Dabei werden verschiedene Kriterien verwendet, wie testfallspezifische Coverage [1] und Ausführungszeit, um ein Subset von Tests zu wählen, das in einem Bruchteil der Zeit einen Großteil der Fehler finden soll. [2] Ziel dieses Verfahrens ist es, eine Liste von Tests zu wählen, die jeden Tag oder öfter ausgeführt werden kann, um schnelleres Feedback zu ermöglichen. Die vollständige Test-Suite sollte dennoch in regelmäßigen Abständen ausgeführt werden.
Der zweite Ansatz, den wir betrachten, ist die Test-Impact-Analyse. Dabei werden Testfälle aussortiert, die bei ihrer nächsten Ausführung höchstwahrscheinlich keine Fehler finden. Die Annahme, dass ein Testfall beim nächsten Testlauf keinen Fehler findet, begründen wir durch die Änderungen seit dem letzten Testlauf. Ein Test, der keinen Code abdeckt, der seit dem letzten Mal geändert wurde, wird voraussichtlich auch keinen neuen Fehler finden. Zudem werden die Testfälle so sortiert, dass innerhalb der kürzest möglichen Zeit eine möglichst hohe Code Coverage erreicht wird. [3]
Im Vortrag gehen wir auf die Vor- und Nachteile der beiden Verfahren ein und präsentieren unsere Erfahrungen aus Forschung und Praxis.

Weiterführende Literatur
[1] F. Dreier, Obtaining Coverage per Test Case, Masterarbeit (2017)
[2] R. Noemmer, Conception and Evaluation of Test Suite Minimization Techniques for Regression Testing in Practice, Masterarbeit (2019)
[3] E. Juergens, D. Pagano, Test-Impact-Analyse: Fehler früh erkennen trotz großer, langlaufender Test-Suites, OBJEKTspektrum 06/2018,
[4] J. Rott, R. Niedermayr, E. Juergens, D. Pagano, Ticket Coverage: Putting Test Coverage into Context, Proceedings of the 8th Workshop on Emerging Trends in Software Metrics (2017)
[5] E. Juergens, D. Pagano, Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse in der Praxis, Whitepaper (2016)
[6] R. Noemmer, R. Haas, An Evaluation of Test Suite Minimization Techniques, International Conference on Software Quality (2020)

For many embedded C++ applications, compliance with the AUTOSAR or Misra rules is required. Among them is AUTOSAR Rule A18-5-5 which does not allow memory allocations with new. Since new and delete violate A18-5-5, the default STL containers must not be used in applications requiring AUTOSAR compliance. This holds for many embedded applications. With the allocators available since C++17 in the namespace std::pmr (polymorphic memory resources) these requirements can often be satisfied.

Target Audience: Architects, Developers, Project Leader
Prerequisites: Good C++ knowledge
Level: Advanced

Extended Abstract
For many embedded C++ applications, compliance with the AUTOSAR or Misra rules is required. Among them is AUTOSAR Rule A18-5-5.
Memory management functions shall ensure the following:
(a) deterministic behavior resulting with the existence of worst-case execution time,
(b) avoiding memory fragmentation,
(c) avoid running out of memory,
(d) avoiding mismatched allocations or deallocations,
(e) no dependence on non-deterministic calls to kernel.

This rule has far-reaching consequences, because per default the C++ standard library containers allocate their memory with new and free it with delete. These calls
• do not have deterministic execution times.
• can cause memory fragmentation.

Since new and delete violate A18-5-5, the default STL containers must not be used in applications requiring AUTOSAR compliance. This holds for many embedded applications.
With the allocators available since C++17 in the namespace std::pmr (polymorphic memory resources) these requirements can often be satisfied. This means that, for the first time in the history of C++, the containers and algorithms of the C++ standard library can be used in applications that require AUTOSAR Rule A18-5-5.

The purpose of Serverless is to focus on writing the code that delivers business value and offload undifferentiated heavy lifting to the Cloud providers or SaaS vendors. Today’s code quickly becomes tomorrow’s technical debt. The less you own, the better it is from the maintainability point of view. In this talk I will go through examples of the various Serverless architectures on AWS where you glue together different Serverless managed services, significantly reducing the amount of the code written to perform the task. Own less, build more!

Target Audience: Developers, Architects, Decision Makers
Prerequisites: Basic understanding of AWS Serverless Services
Level: Advanced 

Ein altes Klischee lautet: “Führung ist böse! Und wer führen will, ist böse."
Neue Generationen von Mitarbeitenden erleben Verantwortung, Wirksamkeit und Sinn bewusster. Jeder hat seine eigene Vision und ist voller Energie. Aber keiner kann den andern überzeugen. Wenn Führung tabu ist, dann ist das Team wirkungslos. Sinnhafte, menschliche Führung gibt es und man kann sie lernen! Der Weg dorthin ist mit harten, unbequemen Themen versehen. Diesen Konflikt wollen wir aufzeigen und eine angewandte Lösungsstrategie anbieten.

Zielpublikum: Manager, Führungskräfte, Entscheider
Voraussetzungen: Führungserfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Ein altes Klischee mancher Agilisten lautet bis heute: “Führung ist böse! Und wer führen will, ist böse."
Die neue Generation von Mitarbeitenden (er)lebt Eigenverantwortung, Wirksamkeit und Sinnorientierung jedoch viel bewusster. Jeder hat seine eigene Vision und ist voller Energie. Aber keiner kann den andern überzeugen. Wenn jetzt Führung tabu ist, dann ist das Team (oder gar eine ganze Organisation) wirkungslos.
Die gute Nachricht ist: "Das sinnhafte und menschliche Führen von Mitarbeitenden gibt es und man kann es lernen!" Die negative Nachricht: “Der Weg dorthin ist kein Kuschelkurs!”. Es gibt die Situationen, wo man durch die harten und unbequemen Themen navigieren muss.
Diesen Konflikt wollen wir aufzeigen und eine Lösungsstrategie anbieten, die erfolgreich in Unternehmen angewandt wird.

These 1: Erst wenn man auch bereit ist, jemanden zu feuern, der dem Team schadet, ist man bereit
These 2: Erst wenn man sagen kann: Ich habe entschieden …!, ist man bereit

“Bereit” heißt: Ich kann übergehen in ein Führungsverhalten, das vertraut, weil zurück vertraut wird.
Wir gehen auf verschiedene Führungsstile ein, die alle notwendig sind und beherrscht werden müssen, um echte, moderne Führung zu ermöglichen. Dabei geht es nicht nur um die Entwicklung der Mitarbeiter im Team, sondern vor allem auch um die persönliche Weiterentwicklung der Führungskraft.

Der verstärkte Einsatz von Microservices führt zu einer erhöhten Kommunikation zwischen den Systemkomponenten. Bei der technischen Realisierung sind REST-Schnittstellen für die synchrone und Message Broker für die asynchrone Informationsverteilung weit verbreitet. Wenn es aber um den Inhalt und die syntaktische Struktur der Nachrichten geht, kann es leicht zu einer babylonischen Sprachverwirrung kommen. In diesem Vortrag betrachten wir verschiedene Ansätze, um einer solchen Sprachverwirrung Einhalt zu gebieten.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Der verstärkte Einsatz von Microservices führt zu einer erhöhten Kommunikation zwischen den Systemkomponenten. Bei der technischen Realisierung sind mittlerweile REST-Schnittstellen für die synchrone und Message Broker für die asynchrone Informationsverteilung weit verbreitet. Wenn es aber um den Inhalt und die syntaktische Struktur der Nachrichten geht, kann es leicht zu einer babylonischen Sprachverwirrung kommen.
„Ach, das Feld. Ne, das haben wir doch umbenannt“ oder „Dieses Feld haben wir doch schon vor Wochen entfernt und dies über … bekannt gegeben“ dürften bekannte Sätze sein, wenn man den Gesprächen der beteiligten Entwickler lauscht.
In diesem Vortrag möchte ich vor allem im Hinblick auf einen asynchronen Nachrichtenaustausch einige Ansätze betrachten, um einer solchen Sprachverwirrung Einhalt zu gebieten. Anschließend werden wir einen Blick auf die schema-basierte Lösung werfen, die wir im aktuellen Projekt einsetzen.

Diese Diskrepanz hindert uns daran, Dinge umzusetzen, von denen wir eigentlich wissen, dass sie notwendig und sinnvoll sind. Das passiert uns als Individuen genauso wie ganzen Organisationen. Viele Unternehmen signalisieren, dass Diversity und Inclusion einen hohen Stellenwert für sie haben (https://www.charta-der-vielfalt.de). Oft bleibt es dann beim Appell: Seid divers!
In diesem interaktiven Vortrag nähern wir uns den „Scripts“, die im Kontext von „Diversity und Inclusion“ unterbewusst ablaufen und unser Handeln beeinflussen.

Zielpublikum: Alle Interessierten, Entscheider und Führungskräfte, Agile Coaches, Scrum Master
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das nehmen die Teilnehmenden mit:
• Was hindert uns daran, auf eine Erkenntnis ein Handeln folgen zu lassen
• Erkennen der eigenen Unconscious Biases
• Kognitive Dissonanzen erkennen
• Eigene „Scripts“ erkennen und verstehen
• Strategien zum Erzeugen neuer „Scripts“
• Transfer auf die eigene Organisation

Der Modularity Maturity Index (MMI) bewertet die Langlebigkeit von Architekturen aus drei verschiedenen Perspektiven: Modularität, Hierarchisierung und Muster. Man kann den MMI sowohl zur initialen Standortbestimmung einsetzen, also um festzustellen, ob das eigene Softwaresystem eine langlebige Architektur hat bzw. wie weit es davon entfernt ist. Außerdem kann man den MMI verwenden, um seine Software-Entwicklung über den gesamten Lebenszyklus der verschiedenen Systeme regelmäßig auf ihre Langlebigkeit hin zu überprüfen.

Zielpublikum: Software-Architekt:innen, Softwareentwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Ich stelle sowohl den von uns gewählten Prozess der Architektur-Bewertung als auch die Prüfkriterien vor und erläutere die typischerweise getroffenen Maßnahmen und Konsequenzen. Mein Ziel ist, dass andere Architekt:innen in die Lage kommen, solche Analysen selbst durchzuführen.

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.

Sie wollen sehen und ausprobieren, wie sich aktuelle Frameworks und Modelle beim Erkennen und Erzeugen deutscher Sprache schlagen? Dann sind Sie hier genau richtig. Probieren Sie online mit uns aus, wie gut freie Modelle inzwischen sind, die Sie unabhängig von den Großen auch lokal nutzen können: Sei es für Sprachbefehle, das Erkennen von Kundentelefonaten, das Erstellen von Audio zur Barrierefreiheit und was deren Grenzen und Vorurteile sind.

Zielpublikum: Sprachversteher:innen, Entwickler:innen
Voraussetzungen: Internetfähiges Gerät fürs Probieren
Schwierigkeitsgrad: Anfänger

Extended Abstract
KI ist nicht mehr ganz so Hype wie vor 2 Jahren und aktuell stehen ethische Themen zu Recht im Nachrichtenfokus. Dabei geht manchmal etwas unter, dass es gerade jetzt gute, frei verfügbare Modelle und Frameworks gibt, um Projekte mit deutscher Sprache und KI umzusetzen. Daten müssen nicht mehr an die Hyperscaler gesendet werden, Frameworks sind in Minuten nicht Stunden installiert und die Erkennung kann an bestimmte Branchen oder Szenarien angepasst werden.
Sie erfahren auf technischer Ebene, wie Spracherkennung und Spracherzeugung mit moderner KI grundsätzlich funktionieren und welche starken Veränderungen sich gerade im letzten Jahr durch neue Algorithmen und Modelle ergeben haben. Wir verwenden in unseren Beispielen Google Colab mit freien deutschen Modellen, die Sie selbst ausprobieren und später erweitern können. Die Beispiele sind an typische Projekte aus der Praxis angelehnt. Die Ersteller der Algorithmen haben häufig einen Forschungsfokus und begnügen sich mit guten Erkennungsraten, aber konzentrieren sich nicht auf den täglichen, skalierbaren Betrieb. Hier stellen wir vor, welche Frameworks heute produktiv einsetzbar sind. Im Bereich der Transkription sehen Sie, wie Diktate automatisiert verschriftlicht werden können und welche Fallstricke dabei lauern. Und beim Erstellen eines KI-Nachrichtensprechers können Sie sich von der Qualität seines bairischen Dialekts überzeugen. Außerdem gehen wir auf weitere typische Einsatzszenarien ein.
Auf organisatorischer Ebene nehmen Sie mit, dass ein Projekt zur Modellerstellung nicht immer so läuft, wie es auf Charts aussieht und was Sie schon jetzt dagegen tun können, auch wenn das Projekt erst in 2 Jahren beginnen sollte. Dabei stellen wir auch vor, mit welchen Daten KI-Modelle am besten trainiert werden sollten und wie man Vorurteile und andere ethische Probleme erkennen und möglichst vermeiden kann. Dabei gehen wir auch auf die Erkennung von Dialekten ein, deren Erkennung den Großen durchaus noch Sorgen bereitet.

Der effektive Einsatz einer Testautomatisierungslösung steht und fällt mit den verwendeten Werkzeugen. In dem Vortrag stellen wir die Ergebnisse einer wissenschaftlichen Arbeit zur Erstellung eines Kriterienkataloges für die Auswahl des passenden Testautomatisierungswerkzeugs für unsere Projekte vor. Dabei wurden die Kriterien und deren Gewichtung nach Vorgehensmodellen, Technologie, Einsatzgebiet sowie dem Blickwinkel der Rollen evaluiert. Die Anwendung des Kriterienkatalogs soll leichtgewichtig sein und Vorgaben des agilen Manifests befolgen.

Zielpublikum: Tester:innen, Agile Teams, Testmanager:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse Testen/Testautomatisierung, Projekterfahrung, Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Der effektive Einsatz einer Testautomatisierungslösung steht und fällt mit den verwendeten Werkzeugen. Für die gezielte Auswahl der Werkzeuge und besonders für die Begründung gegenüber dem Management benötigen Projekte daher einen Katalog von Kriterien. Dabei unterscheiden sich die Kriterien bzw. deren Gewichtung je nach Einsatzgebiet, Vorgehen, Technologie und besonders der Rolle des Betrachters.
In dem Vortrag stellen wir die Ergebnisse einer wissenschaftlichen Konzeption eines Kriterienkataloges für die Auswahl der passenden Testwerkzeuglösung im Rahmen der Testautomatisierung für die ZEISS Digital Innovation vor. Dabei wurden die Kriterien und deren Gewichtung unter anderem nach den verwendeten Vorgehensmodellen (Agile, Scaled, Klassisch), der verwendeten Technologie, dem Einsatzgebiet sowie den Blickwinkeln der unterschiedlichen Rollen evaluiert.
Als Endergebnis soll es möglich sein, passende Testautomatisierungstestwerkzeuge je nach Projekteinsatz anhand des Kriterienkatalogs evaluieren bzw. empfehlen zu können. Durch die flexible Entscheidungsvorlage soll sichergestellt werden, dass die im Kundenprojekt eingesetzten Testwerkzeuge allen relevanten Anforderungen des Projekts, aber auch des Unternehmens entsprechen. Dabei soll die Anwendung des Kriterienkatalogs leichtgewichtig sein und besonders die Vorgaben des agilen Manifests befolgen.

New MISRA C++ 202x are coming. This release will address modern C++ and thus is relevant not only for safety critical code in the automotive sector, but also for day-to-day C++ development. Expect the new MISRA rules to be less "miserable" for your day-to-day coding and use static analysis tooling to enforce them. Understand what kind of C++ will be considered unsafe, get examples of guidelines and learn which rules better to suppress in static analysis tools in non-safety-critical software.

Target Audience: Developers
Prerequisites: C++
Level: Advanced 

Extended Abstract
New MISRA C++ guidelines are coming. In contrast to the previous release in 2008, MISRA C++ will address modern C++ as it is used in modern automotive systems. It is expected that other domains with safety critical software will incorporate MISRA C++ as well. In addition many of the rules, especially those supported by corresponding static analysis tools, can make your own C++ coding practices better. The talk briefly introduce the development of safety critical software, highlight some of the modern MISRA C++ rules applicable to all kinds of code and will also show corners of the rule set, better avoided for "normal" C++ code. The latter is important to know, when you are asked to retrofit your code to the output of a static analyzer tuned to MISRA-C++.
* History of MISRA C++ guidelines
* Peculiarities of software development for safety-critical systems
* Example guidelines and how they influence coding
* "strong stuff" that should not bother in normal C++
* Outlook on further revisions

Wenn Nicolai Josuttis am Abend des zweiten Konferenztages zusammen mit seinen Gästen die IT-Branche „auf die Schippe nimmt“, ist beste Unterhaltung garantiert. In gemütlicher Atmosphäre lassen die herausragenden Vertreter des IT-Business das letzte Jahr mit einem Augenzwinkern nochmals Revue passieren.

Moderation: Nicolai Josuttis

Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Kenntnisse Microservices
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.

What have we learnt from the transformations in large companies? And how can that help you improving your chances for success?

The DACH30 group is a workgroup of experienced transformation drivers and coaches from over 30 large companies across different industries. One sub-workgroup has been working on these two questions and we recently published our findings.

In this workshop we will share our transformation experiences and work out with you on patterns, that have proven to be helpful in driving agile transformations successfully.

Target Audience: Leaders especially on executive level and organizational development coaches
Prerequisites: Experiences in driving an agile transformation in a large organization
Level: Advanced

Extended Abstract

As internal Agile Transformation Coaches from large enterprises we have been supporting quite a number of transformations in various contexts. And as members of a workgroup for Business Agility we were asking ourselves „What can we learn from the different company transformations in the different markets and branches with different cultures? Is there anything they have in common?“ We were quite thrilled to identify some principles and helpful insights and learnings based on success and failures which we found applicable to most of the transformations.

To provide inspiration for others, executives and leaders especially, we summarized these principles and learnings in a Transformation Travel Guide for Growing Adaptive Organizations, including a Travel Map, Travel Tips and also some exemplary Travel Routes based on real-life case studies.

In this session we will provide an overview on the Travel Guide and some deeper insights into learnings from two Transformation Journeys. Study.

Our focus is not on scaling Agile working but rather on achieving Agility on an enterprise level. Hence we are not only looking towards Agile but rather at various methods, thinking models, and techniques in order to find the right approach for specific business problems to solve and for developing organizational towards more adaptivity and resilience.

We are a smaller group from the DACH30 Initiative working on ‚Growing Adaptive Organizations’. growing-adaptive-organizations.org

(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.

Wollen wir unseren Enkeln eine lebenswerte Welt hinterlassen, müssen wir das grundlegende Paradigma unseres Wirtschaftssystems umbauen: Weg vom ausbeuterischen Wirtschaften, hin zu einem regenerativen, demokratischeren und inklusiven Wirtschaften.

Der Vortrag ist ein Plädoyer dafür, nicht auf Politiker, Konzernchefs oder ein Wunder zu warten, sondern selbstbewusst aktiv zu werden. Wir stellen erste Ansätze vor, wie Agilität konkret genutzt werden kann, um den Umbau der Wirtschaft in Angriff zu nehmen.

Zielpublikum: Manager:innen, Entscheider:innen, Projektleiter, Teamleiter, ...
Voraussetzungen: Fachkenntnisse agiler Methoden,
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Vor über 20 Jahren entstand das agile Manifest, das eine radikal neue Arbeitsweise für die Software-Entwicklung proklamierte. Was damals von vielen belächelt wurde, ist heute auch außerhalb der Software-Entwicklung gang und gäbe. Wir haben gesehen, dass agiles Arbeiten Teams effektiver machen und damit das Leben von Menschen positiv beeinflussen kann. Doch auch wenn sich das „Wie“ des Arbeitens verändert hat: Neue Geschäftsmodelle sind dadurch kaum entstanden.

Heute stehen wir jedoch vor einer neuen, ungleich größeren Herausforderung. Wenn wir unseren Kindern und Enkeln eine lebenswerte Welt hinterlassen wollen, müssen wir das grundlegende Paradigma unseres Wirtschaftssystems umbauen: Weg vom ausbeuterischen Wirtschaften, das Finanzmittel konzentriert und massive Ungleichheit erzeugt, hin zu einem regenerativen, demokratischeren und inklusiven Wirtschaften.

Die Sache ist: Einerseits weiß kaum jemand genau, wie nachhaltige Geschäftsmodelle tatsächlich aussehen müssen, welche Technologien noch entstehen und sich durchsetzen werden. Andererseits läuft uns die Zeit davon. Es herrscht Unsicherheit, gepaart mit Zeitdruck.

Genau das ist doch das ursprüngliche Spielfeld agiler Denk- und Arbeitsweisen! Gerade die Community hält alle Tools in den Händen, mit denen Unternehmen regenerative Geschäftsmodelle entwickeln können, die sogar wirtschaftlicher sind als die existierenden. Lasst uns doch die Zukunft gemeinsam gestalten, so wie wir es vor 20 Jahren schon mal gemacht haben. Arbeiten wir mit Unternehmen und Menschen, die diesen Planeten durch enkelfähiges Business erhalten wollen!

Der Vortrag ist ein Plädoyer dafür, nicht auf Politiker, Konzernchefs oder ein Wunder zu warten, sondern selbstbewusst aktiv zu werden. Wir stellen erste Ansätze vor, wie Agilität konkret genutzt werden kann, um den Umbau der Wirtschaft in Angriff zu nehmen.

This is a letter from the future: we are working in an organization in a galaxy not so far away … we have a #diverse #social #digital #remote #culture - and we will tell you how we got there. We leave it open to the audience to guess how far this future is away. Or how near they want it to be. Disclaimer: may contain fragments of reality.

Target Audience: Manager, Idealists, Realists, Change Makers
Prerequisites: Open mind
Level: Basic

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

Eine „menschzentrierte“ digitale Transformation ist in aller Munde. Aber wie gelingt diese? In diesem Vortrag werden wir einen Überblick über existierende Reifegradmodelle zur Menschzentrierung und User Experience (UX) geben sowie die damit verbundenen Potenziale diskutieren. Ausgehend davon berichten wir aus unserem Beratungsalltag bei diversen Organisationen über Stellschrauben, wie sich in der Organisation für das Thema Human-Centered Design sensibilisieren und die Reife zur Menschzentrierung Schritt für Schritt erhöhen lässt.

Zielpublikum: Projektleiter:innen, Manager, Architekt:innen, Entscheider, Produktmanager, Product Owner
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
In der Vergangenheit war die Konzeption von Softwarelösungen stark von dem Versuch geprägt, alle Anforderungen im Vorfeld zu sammeln und dann eine Lösung zu entwickeln. In der Praxis hat sich jedoch gezeigt, dass gerade komplexe Herausforderungen nicht im Voraus durch Anforderungen spezifiziert werden können. Vielmehr ist es so, dass die Anforderungen erst durch die Auseinandersetzung mit konkreten Lösungen geklärt werden können. Ein Ansatz, der sowohl durch die agile Entwicklung als auch durch eine Fokussierung auf die Endanwender (Human-Centered Design; kurz HCD) thematisiert wird. Ein guter Research-orientierter Konzeptionsprozess, der Evidence-basiert statt auf Annahmen beruhend stattfindet, wird damit zum kritischen Erfolgsfaktor.

Um eine positive Experience der Menschen (User Experience; kurz UX) mit den Systemen zu fördern, ist HCD ein wichtiger Faktor im Software-Engineering. Damit HCD im Software-Engineering seine volle Wirkung entfalten kann, muss es jedoch optimal integriert werden. Es sollte die agile Haltung (Agilität), die kontinuierliche Lieferung von Ergebnissen unterstützen (Continuous Delivery) und seinen Beitrag dazu leisten, Verschwendung wie unfertige Arbeit, spätes Umlernen oder Defekte zu vermeiden (Lean Development/UX).

Pragmatische Ansätze dazu werden bspw. unter dem Stichwort "Continuous UX" bzw. „Lean UX“ diskutiert. In der Praxis stellt sich derzeit jedoch die Frage, wie eine gute HCD in dem beschriebenen situativen Umfeld effektiv etabliert werden kann. Zwei wesentliche Werkzeuge für die Steuerung sind zum einen die Reife von Prozessen und zum anderen die Reife in Bezug auf personelle Fähigkeiten und die Organisationskultur. Modelle, die auf eine übergreifende strategische Organisationsebene abzielen, adressieren in der Regel die allgemeine Entwicklung einer Kultur, in der HCD über alle Bereiche des Unternehmens hinweg manifestiert und gelebt werden soll. Modelle, die sich an ein Produktteam richten, fokussieren dagegen den Prozess zwischen den Team-Mitgliedern und die vorhandene Kompetenz in Bezug auf HCD, damit ein brauchbares Produkt entwickelt werden kann. Modelle, die auf der Produktebene angesiedelt sind, messen den spezifischen Reifegrad bzw. die Qualität des Produktes selbst.

In diesem Vortrag geben wir einen Überblick über existierende Reifegradmodelle zu Human-Centered Design und User Experience und diskutieren die damit verbundenen Potenziale und Notwendigkeiten. Ausgehend davon berichten wir aus unserem Beratungsalltag bei diversen Organisationen über Stellschrauben, wie sich in der Organisation für das Thema HCD sensibilisieren und die Reife Schritt für Schritt erhöhen lässt.

Die Teilnehmenden am Vortrag werden lernen,

• was Human-Centered Design ausmacht,

• mit welchen Maßnahmen die Überzeugungsarbeit gelingen kann,

• was dafür nötig ist, den Aspekt der Menschzentrierung nachhaltig zu etablieren sowie

• auf welche Aktivitäten im Projekt zu achten ist, damit das Projektergebnis dies auch widerspiegelt.

Um die Wiederverwendung von komplexen UI-Komponenten zu ermöglichen, haben wir eine interne Web-Components-Library entwickelt, die einen technologieneutralen UI-Styleguide implementiert. So soll zusätzlich ein einheitliches Look-and-Feel über verschiedene Anwendungen hinweg erreicht werden. Wir möchten im Vortrag unsere Erfahrungen teilen bzgl. Framework-Neutralität, Accessibility, Contribution-Modell, Dokumentation, Dokumentation, CI/CD und der Abstimmung mit Produkt-Teams auf der einen und UI/UX-Verantwortlichen auf der anderen Seite.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung, Grundwissen Web
Schwierigkeitsgrad: Fortgeschritte

Extended Abstract

Wenn in einem Unternehmen eine Vielzahl an Front-End-Anwendungen entwickelt wird, stellen sich früher oder später Fragen wie: Wie können wir ein einheitliches Look-and-Feel sicherstellen? Können wir Dinge wiederverwenden und den Entwicklungsaufwand gering halten? Und wie erreichen wir einen Wiedererkennungswert der Anwendungen? Die Entwicklung eines firmeninternen Styleguides bzw. Design-Systems und entsprechende Component-Libraries sind ein naheliegender Ansatz, jedoch steckt der Teufel wie so oft im Detail. Denn in modernen Projektsetups möchte man den einzelnen Teams ja möglichst wenige Technologievorgaben machen, was eine Herausforderung für projektübergreifende Komponenten-Bibliotheken darstellt. Darüber hinaus stellt die Entwicklung einer Bibliothek ganz andere Anforderungen an den Entwicklungsprozess als beispielsweise eine Endkunden-Software. Themen wie Dokumentation, Abwärtskompatibilität, Einbindung der UX-Teams, Maintenance, Accessibility und der Umgang mit sich teilweise widersprechenden Anforderungen und Erwartungen sind besondere Herausforderungen.

Wir wollen im Vortrag von unseren Erfahrungen bei der Entwicklung einer Web-Components-Bibliothek für den konzernweiten Einsatz in unterschiedlichen Web-Projekten berichten.

The adoption of static analysis of C++ and Java requires that the findings and errors can be prioritised in an efficient way. Our work shows that Machine learning (ML) can support this presentation of static analysis results to end-users. The ML engine learns from the codebase itself, and also observes the violations that the user fixes and which he ignores. The ML uses this to suggest the next best violations to fix, relying on probability of violations to be harmful or most likely to be a noise.

Target Audience: Developer Managers, R&D Managers, Software Architects, Software Engineers
Prerequisites: English, Software development, Coding experience, C++, Java, C#.
Level: Expert

Extended Abstract
Static code analysis is often understood as a mandatory part for checking the source code compliance to government and industry regulations, company-wide guidelines and practices. It can play, however, a more fundamental role in estimating the quality of the code in general, understanding the amount of technical debt, creating the strategy to reduce the amount of technical debt, as well as a helper in making decisions on how to speed up the development by creating a more maintainable, understandable, sociable codebase.

However, by its nature, static code analysis is bound to produce a large amount of noise and false alerts that can distract the team from the actual bugs in the code and prevent them from working thoroughly with the findings. One of the reasons for that is the level of soundness of the static analysis tool. If we want to be sure that the analysis is bound to find all errors in the code, the static analysis tool has to report all possible candidates. The more sound the tool is configured to be, the larger the number of the possible errors is reported, which increases the number of false positives as well.

To improve the user experience of working with static analysis technology, we have developed a machine learning (ML) based approach to presenting the results of the static analysis to users. The ML engine can learn from the code base itself, from a user's preferences, as well as from the interaction within the team. At the code level, our engine learns from the syntactical and semantical structure of the analyzed code to understand which violations are more likely to cause more harm, which violations are more likely to be noise, what underlying problems can be fixed to drastically reduce the number of reported violations. At the user level, the ML engine observes which violations the user fixes and which violations the user ignores. Based on these observations, the ML engine builds a model and uses it to suggest the next best violations to fix.

Maintaining a database containing millions of products can be very challenging, especially when the information you require of these products is subject to changes over time.

We show how we used state of the art Deep Learning methods (such as Transformers, BERT) in connection with smart text matching in order to extract relevant information from free-form text.

We also explain how we leveraged the existing database to create an automatically labelled training dataset.

Our model enables us to continuously update idealos database automatically.

Target Audience: Decision Makers, Technical Project Leaders, Developers
Prerequisites: Basic knowledge of machine learning methodology
Level: Advanced

Extended Abstract

To maintain idealos product base, product information in the form of values of predefined product attributes needs to be extracted from free-form text product descriptions.

Before the use of a Machine Learning based solution, this process required a lot of manual work to define rules to extract this information. There is also a high effort connected to keeping these rules consistent across the whole database and different types of products, especially since the source of this information (the product descriptions) as well as the required information (the product properties) are subject to changes over time.

In this talk we present a machine learning solution, based on fine tuned state-of-the-art models such as BERT, which is able to extract product information automatically from product descriptions with production-ready performance.

Our solution contains two different models, each following one of the well-known problem settings in Natural Language Processing (NLP): Semantic Segmentation of text (also known as Token Classification) and Question Answering. We will present both models in detail, as well as discussing their advantages and disadvantages for solving the task at hand and how we measured its performance (metrics).

We will also emphasize the importance of identifying aspects of your data that ensure that the developed model can actually fulfill your business needs before curating your dataset.

This highlights another benefit of implementing a Machine Learning model for a huge database: You will get sanity checks of your existing data “for free”, as consistent data is a prerequisite for a successful Machine Learning project.

One problem that is very common in large organisations is that there is often no or only very little training data in the form of labels for specific text sections available. We show how we mitigated this problem by leveraging the existing database to generate a large artificial training dataset. This allowed us to only use a few thousand manually labelled examples for training and testing to reach sufficient performance.

To continuously deliver IT systems at speed with a focus on business value, high-performance IT delivery teams integrate quality engineering in their way of working.

Quality engineering is the new concept in achieving the right quality of IT systems. Testing only after an IT product was developed is an outdated approach. Built-in quality from the start is needed to guarantee business value in today’s IT delivery models. Quality engineering is about changes in skills, organization, automation and quality measures.

Target Audience: All people involved in high-performance IT delivery teams
Prerequisites: General knowledge of IT delivery
Level: Advanced

Extended Abstract

To continuously deliver IT systems at speed with a focus on business value, high-performance cross-functional IT delivery teams integrate quality engineering in their way of working.

Quality engineering is the new concept in achieving the right quality of IT systems. Testing an application only after the digital product has been fully developed has long been a thing of the past. More is needed to guarantee the quality of applications that are delivered faster and more frequently in today’s high-performance IT delivery models. It is about achieving built-in quality. The road to quality engineering means changes in terms of starting points, skills, organization, automation and quality measures.

Our new VOICE model guides teams to align their activities with the business value that is pursued, and by measuring indicators, teams give the right information to stakeholders to establish their confidence that the IT delivery will actually result in business value for the customers.

Teams benefit from the clear definition of QA&Testing topics that are a useful grouping of all activities relevant to quality engineering. Organizing topics are relevant to align activities between teams and performing topics have a focus on the operational activities within a team.

Also, to be able to deliver quality at speed, for today’s teams it is crucial to benefit from automating activities, for example in a CI/CD pipeline, whereby people must remember that automation is not the goal but just a way to increase quality and speed.

In this presentation the audience will learn why a broad view on quality engineering is important and how quality engineering can be implemented to achieve the right quality of IT products, the IT delivery process and the people involved.

This presentation is based on our new book "Quality for DevOps teams" (ISBN 978-90-75414-89-9) which supports high-performance cross-functional teams in implementing quality in their DevOps culture, with practical examples, useful knowledge and some theoretical background.

In large software projects the assessment of the impact of a code change can be a cumbersome task. If the software has grown and shows an evolutionary design there are always unwanted side effects.

Change control boards are established. But on what data do they judge what can happen with the changes? Very often there is the HIPPO syndrome which means it is the highest paid person's opinion.

In this talk we will show you ways to come to a deterministic prediction of the impact, what data you need and what you can do with it.

Target Audience: Architects, Test Managers, Developers, Testers
Prerequisites: Basic knowledge of collected data in software projects
Level: Advanced

On-Call is an increasing reality for developers, especially when a site has strict uptime requirements. And sadly, the experience often sucks. It's easy to mandate 24x7 support, it's much harder to set it up in a way that doesn't make the life of the people in the rotation miserable.
I want to talk about improving alerting. I'm focusing on creating high-quality alerts that trigger when they should and don't trigger when nothing is happening. Continuous tuning, automation, and using the right metrics are core parts of this process.

Target Audience: Developers, Architects, DevOps, Operators
Prerequisites: Monitoring, operating production software
Level: Advanced

Extended Abstract
Do you believe in “you build it, you run it”? What if you have on-call rotations, where you are responsible 24x7 for the health of a system? Nothing is quite so infuriating as a collection of poorly structured alerts that trigger randomly.
So, let’s do better! I want to talk about how to improve your monitoring capabilities. There are a few topics I want to touch:

• Reduce the noise
• Automate as much as possible
• Build actionable triggers
• Tune your monitoring constantly

After this talk, you’ll have concrete actions to make your engineers’ life easier when on-call.

krankheitsbedingt ein kurzfristiger Wechsel

Content Management Systeme, Web-Browser oder Betriebssystem: Viele der Produkte und Services die wir täglich nutzen werden mittlerweile als Open Source Projekte realisiert. Durch den hohen Einfluss, den die Open Source Entwicklung mittlerweile auf die digitale Welt hat, findet man allerdings auch viele unterschiedliche Aussagen über dieGefahren und Vorteile von Open Source Produkten. Vor allem wenn man sich selber noch nicht intensiv mit der Thematik auseinander setzen konnte ist es hierdurch schwer, fachlich korrekte Bewertungen zu Open Source Produkten treffen zu können.

Basierend auf der Mitarbeit an verschiedenen großen Projekten in der Eclipse Foundation und des Java Ökosystems werde ich in diesem Vortrag nicht nur die theoretische Definition von Open Source vorstellen, sondern auch zeigen, wie Open Source Projekte in der Praxis entstehen und weiterentwickelt werden. Wir werden uns auch anschauen, warumOrganisationen Software als Open Source veröffentlichen und welche neuen und interessanten Geschäftsmodelle sich hierbei ergeben. Hierbei werden auch die Themen wie Lizenzen, Security und Support von Open Source Produkten angesprochen, welche durch Beispiele wie OpenSSL und den 2014 veröffentlichten Heartbleed-Bug konkretisiert werden.

Das im Vortrag vermittelte Wissen soll helfen, Open Source Software besser verstehen und einschätzen zu können. Mit diesem Fachwissen können die verschiedenen Gefahren und Vorteile, die durch die Nutzung von Open Source Komponenten entstehen, in Zukunft besser beurteilt werden.

The idea of looking at your organization as a single coherent system is tempting, but is it realistic? If it isn't, what does that mean for software developers, and how can we make discoverable what we are developing? This talk looks at organizations as ecosystems rather than as systems, and asks what that difference means for software development. It all boils down to focusing on software as components implementing business capabilities, and how to best capture these capabilities and make them findable and useful as reusable components.

Target Audience: Developers, Architects, Project Leaders, API Strategists
Prerequisites: API Basics, Large-scale information systems
Level: Advanced

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

If any person or groups of people feel unwelcome because of the language being used in a community, its products, or documentation, then the words should change. We can choose words that are precise, not dependent on metaphors, and convey messages without negative connotations.
We will discuss the process of auditing our own work and identifying divisive language. We will also talk about methods to standardize replacements and collaborate with writers and product developers to carry out these changes in a sustainable way.

Target Audience: Content creators (writers, developers, etc.) and management
Prerequisites: None
Level: Basic

Das Agile Manifest erschließt „bessere Wege, Software zu entwickeln“. Könnte dieser bessere Weg auch den CO2-Fußabdruck der Software berücksichtigen? Einer Prognose zufolge wird die IT bis 2030 21 % des weltweiten Energieverbrauchs ausmachen. Ändern wir die Art und Weise, wie wir Software implementieren, nicht, werden wir zur Erhöhung des CO2-Fußabdrucks beitragen. Es ist also Zeit zu prüfen, wie agile Entwicklung dazu beitragen kann, den Energieverbrauch zu senken und für mehr – ökologische, soziale & wirtschaftliche – Nachhaltigkeit zu sorgen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider, ...
Voraussetzungen: Kenntnisse des agilen Manifests/agiler Entwicklung von Vorteil
Schwierigkeitsgrad: Fortgeschritte

Extended Abstract
Vor zwanzig Jahren, als das Agile Manifest erstellt wurde, gab es zwar die Klimakrise bereits, aber zu wenige Menschen waren sich ihrer bewusst. Jetzt ist die Zeit, einen weiteren Blick auf das Manifest zu werfen, um zu verstehen, was es zu mehr Nachhaltigkeit beitragen kann. Nachhaltigkeit wird hier als ein Blick über den Tellerrand verstanden, der die Integration der ökologischen, wirtschaftlichen und sozialen Perspektiven umfasst (nach dem Drei-Säulen-Modell, engl. triple bottom line). Dabei geht es nicht darum, Nachhaltigkeit aus anthroposophischen Gründen zu verfolgen, sondern zu verstehen, dass Nachhaltigkeit im Laufe der Zeit immer mehr zum Schlüsselfaktor wird, der über das Überleben von Unternehmen sowohl bei der Suche nach Talenten als auch nach Kunden und Märkten entscheidet. Aus diesem Grund haben bereits jetzt einige Unternehmen eine*n Nachhaltigkeitsbeauftragte*n im Unternehmen, um die ökologische, soziale und wirtschaftliche Nachhaltigkeit sicherzustellen.

In dieser Session geht es darum, das Bewusstsein für unseren Beitrag zu mehr Nachhaltigkeit zu schärfen und zu verstehen, wie uns die Prinzipien des agilen Manifests dabei unterstützen können. Darüber hinaus soll die Session dazu dienen, herauszustellen, was unsere Verantwortung ist und wie wir gewährleisten, dass wir dieser Rechnung tragen.

Take-Aways

• Grundverständnis über Nachhaltigkeit entwickeln
• Verstehen, wie die agilen Prinzipien Orientierungshilfe für mehr Nachhaltigkeit bieten können
• Ideen entwickeln, mit welchen Strategien das Thema in der eigenen Organisation mehr Nachdruck erhält
• Größeres Bewusstsein für den eigenen Einfluss auf mehr Nachhaltigkeit

Besides IoT and Machine2Machine communication Digital Twins are a cornerstone of the fourth industrial revolution. In general, a Digital Twin is the virtual replica of a physical object or system. But what does this mean in detail – what are the ingredients of a Digital Twin? How can Digital Twins be built and utilized and what value do they bring? This talk gives an overview of different types of Digital Twins, different applications from public to industrial utilization and architectural approaches how to create and execute them.

Target Audience: System Architects, product owners, software engineers
Prerequisites: None
Level: Basic

Der Vortrag beschreibt, wie man von einem operativen Wertstrom (z. B. Beantragung eines Kredits) zur Ableitung von Features kommt und diese in MVP (Minimum Viable Products) und Folgereleases priorisiert.

Wir schauen uns dabei Werkzeuge, wie z. B. Customer Journeys, Feature Mapping, Ideation und Priorisierungsmethoden an. Das Ganze wird anhand eines Beispiels/Fallstudie aus einem unserer großen Delivery-Projekte aufgezeigt.

Zielpublikum: UX, Architekt:innen, Entwickler:innen, Projektleiter:innen, Projektmanager:innen, Product Owner, Product Manager
Voraussetzungen: Basiswissen im agilen Requirements Engineering
Schwierigkeitsgrad: Anfänger

Extended Abstract

Der Vortrag beschreibt, wie man von einem operativen Wertstrom (z. B. Beantragung eines Kredits) zur Ableitung von Features kommt und diese in MVP (Minimum Viable Products) und Folgereleases priorisiert.

Wir starten damit, uns anzuschauen, was ein operativer Wertstrom ist und warum es vorteilhaft ist, sich nach diesen zu organisieren. Im nächsten Schritt leiten wir aus diesem Wertstrom eine Customer Journey Map und gehen auf Werkzeuge, wie z. B. Personas und Empathy Maps ein. Danach leiten wir aus der Customer Journey eine Feature Map ab und gehen hier auf verschieden Ideation-Tools ein. Zuletzt zeigen wir, wie man aus der Feature Map das MVP und weitere Releases bestimmen kann, hier gehen wir auf verschiedene Priorisierungsmethoden ein.

Der Vortrag soll aufzeigen, wie man in der Entwicklung von neuen Produkten vom Wertstrom mithilfe von Customer Journeys und Feature Mapping zum MVP kommt. Das Ganze wird anhand eines Beispiels/Fallstudie aus einem unserer großen Delivery-Projekte aufgezeigt.

Der Umfang der MLOps-Prozesse und -Technologien hängt von dem AI "Maturity Level" der jeweiligen Organisation ab. Das Umsetzen von kanonischem MLOps kann zu einer unnötigen Komplexität in der Architektur und Organization führen. Das “AI Readiness”-Framework definiert den Reifegrad einer Organisation bei der Nutzung von ML/AI und ordnet es in eine der drei Stufen ein: Tactical, Strategic und Transformational. In dem Vortrag gehe ich auf die drei “AI-Readiness”-Stufen ein und zeige, wie man eine MLOps Roadmap ableitet.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Machine Learning-Enthusiasten, Data Scientists
Voraussetzungen: Allgemeines Verständnis über Machine Learning
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Der Umfang der MLOps-Prozesse und -Technologien hängt von dem AI "Maturity Level" der jeweiligen Organisation ab.

Das “AI Readiness”-Framework definiert den Reifegrad einer Organisation bei der Nutzung von ML/AI und ordnet es in eine der drei Stufen ein:

Tactical, Strategic und Transformational.

Es ist essenziell zu verstehen, dass die Verwendung von Machine Learning Tools und Techniken in diesen Phasen in einem Reifeprozess verläuft. Von dem manuellen und dem Ad-hoc-Deployment, über die Implementierung von ML Workflows/Pipelines, bis hin zu Continuous Training und dem automatisierten Deployment von ML-Modellen.

Im Vortrag gehe ich auf diese drei “AI-Readiness”-Stufen ein und zeige, wie man die nächsten Schritte (MLOps Roadmap) ableitet

Die Praxis in den agilen Teams ergibt immer größeren Bedarf an grundlegenden Testfähigkeiten auch für klassische Entwicklerrollen. Aber oft fehlen die entsprechenden Expertisen und die Akzeptanz für das Testen. Nötig ist eine stärker ausgeprägte Kultur des Testens als Schlüsselfaktor für den Erfolg agiler Projekte. Daher wurde vom GTB auf Basis des etablierten „Certified Tester“-Quasistandards für Testing-Skills ein auf die Bedürfnisse von Entwicklern zugeschnittener Kanon an Testwissen und ein praxisbezogener Kurs als Hilfestellung definiert.

Zielpublikum: Entwickler & Tester, Architekt:innen, Productmanager:innen, DevOps, Qualitätsmanager:innen, Entscheider, Human Resource
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract

Agil ist weiter auf dem Vormarsch und aus unserer Praxis wissen wir, dass gerade in der agilen Welt die Komplexität der Aufgaben im Team und Anforderungen an die Qualität der Produkte stetig und rasant zunehmen. Schnelle Entwicklungszyklen und Technologien wie KI, Machine Learning und IoT erhöhen den Druck auf die Projekte.

In den agilen Projekten werden Entwickler:innen zunehmend mit Testaufgaben betraut und Tester:innen zunehmend mit der Entwicklung von Testautomatisierung. Daher ergibt sich in den Teams ein wachsender Bedarf an grundlegenden Testfähigkeiten auch für die klassischen Entwicklerrollen im Team. Allerdings weisen viele agile Projekte missionskritische Lücken in der Qualitätssicherung auf. Zwei Schwerpunkte sind hier entscheidend: fehlende Akzeptanz für das Testen in den agilen Teams und oft fehlende Testexpertisen.

Um dies zu adressieren und zu verbessern, benötigen wir ein stärkeres Bewusstsein für die Herausforderungen und Fallstricke und eine stärker ausgeprägte Kultur einer Qualitätssicherungs-Community. Wir sehen deutlichen Bedarf an Verbesserung der Testexpertisen über alle Testaspekte und Teststufen als Schlüsselfaktor, Produkte nachhaltig und erfolgreich agil zu entwickeln. Was wir in anderen Worten ermöglichen müssen: Entwickler:innen können testen und Tester:innen können Automatisierung entwickeln. Und wir benötigen dafür die nötige Unterstützung aus dem Management.

Aber welche Testthemen sind zu stärken oder überhaupt zu etablieren? Und welche Testexpertisen werden dafür benötigt? Basierend auf dieser Frage wurde vom GTB (German Testing Board e.V.) ein auf die Bedürfnisse von Entwickler:innen zugeschnittener Kanon an Testthemen und Testexpertisen definiert. Dieser Kanon soll Entwickler:innen die Möglichkeit geben, die für die Erstellung der Software benötigten Kenntnisse über Testgrundlagen systematisch aufzubauen und zu erweitern.

Darauf basierend hat GTB auch einen Lehrplan "A4Q Testing Foundations for Developers" auf Basis des seit vielen Jahren etablierte Quasistandards des „ISTQB® Certified Testers“ entwickelt. In dem Lehrgang wird auch auf Hands-on-Aspekte viel Wert gelegt, d.h. es wird auch programmiert. Kanon und Kurs sind als Handreichung zu verstehen, Akzeptanz für das Thema Testen und die nötige Systematik der Testexpertisen im Team zu stärken. Die damit gewonnene gemeinsame Sprechweise hilft auch dabei, dass sich Entwickler:innen und Tester:innen bei ihrer Arbeit noch besser verstehen.

Due to the capabilities of Kubernetes, the usage of patterns rises to solve complex questions, but causing often confusion and unnecessary implementations. This talk intends to show what are the right scenarios for and for which cases another pattern is more suitable.
In this talk, Max will introduce you to various patterns, often misused by running applications and services within Kubernetes. The focus will be on structural patterns like Sidecars and Ambassadors as well as more advanced patterns like Controller and Operator.

Target Audience: Architects, DevOps Engineers, Platform Teams
Prerequisites: Good Understanding of Kubernetes
Level: Basic

Additional Information:
From this talk, you should take away in which scenario a pattern will suit most likely and how you can implement it. We will also look critically at the usage of these patterns.