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

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

Mit Microservice-Architekturen & DevOps-Prozessen werden große zentrale Security Gateway-Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern & Security führt zu Effizienzverlusten und Frustration. Besser wäre es, Security-Aufgaben mittels Microgateways zu erledigen. Der Vortrag beleuchtet technische und organisatorische Herausforderungen von Microgateways und zeigt in einer Demo, wie Microgateways genutzt werden können, um existierende Services zu schützen.

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

Extended Abstract
Mit dem Aufkommen von Microservice-Architekturen und DevOps-Prozessen werden große zentrale Security Gateway-Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern und dem Security-Team führt zu Effizienzverlusten und Frustration. Besser wäre es, wenn Security-Aufgaben nahe bei den zu schützenden Services mittels sogenannter Microgateways erledigt würden. DevOps-Teams könnten die Verantwortung für die Sicherheit ihrer Services von der ersten Minute an bis in die Produktion übernehmen (Shift Left). Der Vortrag beleuchtet technische und organisatorische Herausforderungen rund um den Einsatz von Microgateways. Zudem wird in einer Demo gezeigt, wie Microgateways konkret genutzt werden können, um existierende Services zu schützen.

Bei der Berücksichtigung von UX im Software Development sehen sich Unternehmen häufig vor neue Herausforderungen gestellt. Wichtige Faktoren stellen Kosten, Zeit, die nachhaltige UX-Integration in die bestehende Vorgehensweise und spezifische Einschränkungen in der Praxis dar. Im Rahmen des Vortrags bieten wir einen Einblick in unsere Projekterfahrungen sowie die relevantesten Erkenntnisse und präsentieren unsere daraus abgeleitete Vorgehensweise.

Zielpublikum: Entscheider, Projektleiter:innen, UX-Spezialist:innen und -Interessierte, Schnittstellen IT und Fachbereich
Voraussetzungen:Grundkenntnisse menschzentrierter Gestaltung/UX, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Klingt die Berücksichtigung der UX geradezu paradiesisch, zeigen sich dabei häufig unerwartete Herausforderungen. Zwar gewinnen die Relevanz und der Mehrwert der Nutzerzentrierung an Bekanntheit, dennoch besteht nicht selten Skepsis seitens Kollegen oder Kunden. So werden gelegentlich weiterhin Aussagen wie „UX kostet mehr Zeit und Geld“ als Argument gegen die Berücksichtigung von UX in Projekten verwendet.
Daraus ergeben sich für die Integration von UX zunächst zwei Faktoren:

• Kosten: Wie kann eine positive UX erreicht werden, ohne dass die Kosten steigen? Kann ich mittels der Vorgehensweise vielleicht sogar nachhaltig die Ausgaben reduzieren?
• Zeit: Wie kann eine positive UX erreicht werden, ohne dass sich das „Go Live“ verzögert? Kann dies vielleicht sogar beschleunigt werden?

Darüber hinaus sehen sich Unternehmen im Zuge der Berücksichtigung von UX im Software Development vor weiteren organisatorischen Hürden. Häufige Fragen, denen sie sich stellen müssen, sind mitunter:

• Wie kann UX in die bestehende Vorgehensweise integriert werden?• Welche Integrationsansätze gibt es und welcher von ihnen passt am besten für das jeweilige Projekt?
• Wie können wir sicherstellen, dass UX als obligatorisch und nicht nur als „nice to have“ betrachtet wird?
• Welche Methoden der menschzentrierten Gestaltung eignen sich besonders gut?
• Wie ist vorzugehen, wenn kein direkter Nutzerkontakt möglich ist oder besondere Vorgaben vorliegen?
• Wie kann sichergestellt werden, dass neben der technologischen Machbarkeit, der Geschäftsnutzen, die fachlichen Anforderungen sowie die Nutzerbedürfnisse gleichermaßen berücksichtigt werden?

Wir haben uns dieser Fragen angenommen und verschiedene Vorgehensweisen verprobt.
Zu unseren wichtigsten Erkenntnissen gehört, dass der Einfluss menschzentrierter Gestaltung bei richtigem Einsatz über eine positive UX hinaus geht: Nicht nur die Endnutzer sind mit den Ergebnissen zufriedener, sondern auch die Stakeholder, zu denen häufig auch die beteiligten Fachabteilungen zählen. Während eine gemeinsame, kohärente Produktvision und positive UX sichergestellt werden, erfolgt obendrein eine Beschleunigung des Software Developments. Dies führt zu einem nachhaltigen und begehrenswerten Endprodukt. Wie das möglich ist, wird im Rahmen des Vortrags vorgestellt. Wir bieten einen Einblick in unsere Projekterfahrungen und stellen unsere daraus abgeleitete Vorgehensweise vor.

Each project has its own unique technology stack, different business logic and a unique team. The definition of quality in our projects can vary greatly. However, there are good practices that will work everywhere. There are steps that can be taken in every project and team to produce the software of better quality. I will tell you how to improve communication and processes, and what tools we can use not to be ashamed of the fruits of our work. Everything from a programmer's perspective.

Target Audience: Developers and Tech/Project Leaders
Prerequisites: Some experience in profesional software development
Level: Advanced

Extended Abstract
Each project has its own unique technology stack, different business logic and a unique team. Some of us work on mature products that have been in production for many years. Others are constantly struggling to innovate in the race against time. The definition of quality in our projects can vary greatly. However, there are good practices that will work everywhere. There are steps that can be taken in every project and team to produce the software of better quality. I will tell you how to improve communication and processes, and what tools we can use not to be ashamed of the fruits of our work. Everything from a programmer's perspective.

“TDD is when you write tests before implementing the business logic” - a simple sentence that is also often misunderstood.
Moving from one project to another, I have observed how many times people were terrified of TDD. I have been there too.
This session will focus on trying to understand HOW and more importantly WHY you should consider TDD. I've transformed failures from my experience into a series of lessons learned, things that in hindsight should have been obvious.

Target Audience: Architects, Developers
Prerequisites: Basic knowledge in testing techniques
Level: Basic

Neue Ansätze, neue Technologien lösen Probleme – ja, nein, vielleicht?
Hinter den Neuigkeiten stecken oft alte Bekannte. Probleme, die wir lange kennen, sind selten ganz weg - aber immerhin gewandelt, geändert, besser beherrschbar. Neue Lösungen ändern die alten Probleme. Nur, mit steigendem Alter werden sie selbst zum Teil eines neuen Problems?
Das ist das Spannungsfeld für Architekten, die Systeme bauen, die lange leben sollen. Ihre Aufgabe ist nicht nur technologisch; sie sollen auch in alle Richtungen Vertrauen ausstrahlen, dass das Projekt und die Organisation auf dem richtigen Weg sind. Dazu gehört auch, die richtigen Probleme zu kennen und die richtigen Lösungen zu wählen.
Machen Sie mit: in dieser interaktiven Session reden wir darüber. Wir betrachten das Neue und das Mitgenommene, die Lösungen und die Nebenwirkungen, die Stakeholder und ihre Prioritäten.

Zielpublikum: Architekt:innen, und die mit ihnen arbeiten
Voraussetzungen: Rollenerfahrung
Schwierigkeitsgrad: Fortgeschritten

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

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

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

When breaking up our software into modules we all too often forget the important social aspects; how the design affects the teams. We need modules that not only make us efficient but also harmonious.
We know that good fences make good neighbours, but only when the boundaries are placed correctly. We are going to take a closer look at why modularity is needed, what it actually can do for us, and how we can increase our chances of getting it right by taking a systems thinking approach.

Target Audience: Software Architects, Developers, Systems Designer
Prerequisites: None
Level: Expert

Extended Abstract
Modularity is a key aspect of software and architectural design, setting explicit boundaries between different parts of the system. But we have been banging on about this since the 70s, and still we are creating big balls of mud -- now even the distributed kind. Either modularity as a concept is insufficient or maybe there are aspects here we seem to get wrong. We know that good fences make good neighbours, but only when the boundaries are placed correctly. How can we create robust and sustainable modular designs when identifying those boundaries are so challenging?
In this talk, we are going to take a closer look at why modularity is needed, what it actually can do for us, and how we can increase our chances of getting it right by taking a systems thinking approach. The claim made is that a holistic view of the problem space is critical; one that considers all its parts, including the business and all the people affected. Software development today is inherently a sociotechnical endeavour and any modularisation effort, be it information hiding, SOA, microservices, DDD, Team Topologies and more, must take this into account in order to be able to create solutions that are sustainable and have the necessary conceptual integrity.
In summary, this talk will help you piece together all of the these good modularisation practices and understand the theory behind them, improving your holistic system design skills, and enabling you to create requisite coherence in your designs. Maybe this will guard you against the dreaded distributed big ball of mud, the killer of agility and productive collaboration.