Architekturentscheidungen werden häufig und zumeist implizit getroffen. Da eine Dokumentation dieser nur selten erfolgt, existiert Wissen über diese nur in den Köpfen der Entwickler und eine Weitergabe des Wissens ist schwer bis unmöglich. Ein Wildwuchs verschiedener Implementierungsstile und eine Erosion der Architektur ist der logische Schluss.

Am Beispiel wird gezeigt, wie die Arbeit mit Michael Nygards ADRs erfolgreich etabliert werden kann, um Entscheidungen zu dokumentieren, und welche Tools existieren, um deren Umsetzung automatisiert zu prüfen.

Zur Teilnahme benötigt wird ein Laptop mit Google Chrome oder Mozilla Firefox.

Maximale Teilnehmerzahl: 30

Zielpublikum: Softwareentwickler:innen sowie Architektinnen und Architekten mit Nähe zum Code
Voraussetzungen: Erfahrung im Umgang mit einer IDE
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Dieser Workshop möchte mit Michael Nygards "Architecture Decision Records" (ADRs) einen leichtgewichtigen Ansatz zur Dokumentation und Kommunikation von Architektur-Eentscheidungen aufzeigen. Am Beispiel soll erläutert werden, wie sich das Treffen und Kommunizieren von Entscheidungen mit ADRs effizient in den Entwicklungsprozess integrieren lassen. Das Hauptaugenmerk liegt dabei insbesondere in dem Nachvollziehbar-Machen der Entscheidungen für alle Entwickler. Es wird gezeigt, wie sich ADRs mit AsciiDoc versioniert und nachvollziehbar im Projekt integrieren lassen, diese zentral allen zur Verfügung gestellt werden können und wie die Einhaltung der Entscheidungen automatisiert geprüft werden kann. Der Workshop basiert auf den Erfahrungen bei verschiedenen Kunden, bei welchen die Dokumentation mittels Architecture Decision Records erfolgreich eingeführt wurde.

The Scrum Guide lays out the rules of the game called Scrum. Beyond it, there are known "secrets" necessary to making Scrum work—but most teams never get to them.

Scrum experts have been working for years to collect and write these nuggets down as patterns. The seminar is based on the book "A Scrum Book" — a de facto standard for Scrum, and a definitive exposition of the why behind everything Scrum. You'll learn about Scrum at a deeper level than you probably reached during your CSM, PSM, or CSPO training — focusing on your team's special needs.

Maximum number of participants: 30

Target Audience: Scrum team members (all Scrum roles); managers and other players in organizations using Scrum
Prerequisites: Basic Scrum familiarity (any Scrum certification, or membership on a practicing Scrum team)
Level: Advanced

Extended Abstract
When you have a new child in your family, there are a lot of things you need to know that aren't in the owner's manual. What? You didn't get an owner's manual with your child? Even Scrum has an "owner's manual" called The Scrum Guide — but all it does is to provide a dry, formal description of the boundaries of Scrum. Yet there are known "secrets" to making Scrum work, but, unfortunately, some teams never get to them.

Scrum community experts have been collecting these secrets for years, and working together to write them down as patterns. The seminar is based on the book "A Scrum Book" — a de facto standard for what Scrum means, and a definitive exposition of the why behind everything Scrum. Even the inventor of Scrum, Jeff Sutherland, now uses them as a central part of his training and of describing Scrum. And now they’re freely available to you. Come and learn how to use them and what they mean to your organization, and how you can use them to chart a powerful new direction of kaizen for your Scrum team! You'll learn things about Scrum at a deeper level than you probably reached during your CSM, PSM, or CSPO training — and the seminar is focused on your team's special needs.

There will be exercises to develop pattern sequences from the pattern language, and to identify solutions to your own impediments using patterns. The session culminates with an exercise where you assess your own Scrum team and develop a concrete action plan to remedy the gaps between your current practice and those parts of Scrum that will move you forward. In the end, the goal is to move beyond Scrum — and this session lays the foundations for you eventually to do that.

We encourage you to attend as Scrum team, perhaps using this event as a retrospective!

Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high.

To address these challenges the right timing in testing is critical but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on timing in testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve timing in testing – because it is time to act now!

Maximum number of participants: 50

Target Audience: Test Architects, Test Engineers, Product Owners, Quality Managers, Software Architects, Developers
Prerequisites: Basic knowledge about testing and quality engineering
Level: Advanced

Extended Abstract
Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high. Our test systems increase in size, volume, flexibility, velocity, complexity, and unpredictability. Additionally, digitalization requires more than just a face lift in testing.

To address these challenges the right timing in testing (“when to do what kind of testing and how?”) is critical, but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on timing in testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve timing in testing – because it is time to act now!

Some of the areas in testing that are covered in the tutorial are:

• When to do what kind of testing in the lifecycle – agile, lean, DevOps, and beyond
• Testing too early vs. too late – risks and opportunities
• Test automation and the test pyramid – shift-left, shift-right
• When to stop testing – test exit criteria
• Repetition in testing – regression testing

Security is an important topic, especially when developing software. But it is seen as complex and is holding everyone back, often put off until the end and delegated to an external person or group.

To be effective security needs to be a continuous part of the development process and to involve the whole team.

Security games can help to achieve this. They involve the whole team and facilitate the learning and application of security principles. They offer a way to integrate expert knowledge and make security less scary, maybe even fun.

Maximum number of participants: 50

Target Audience: Architects, Developers, Project Leaders, Testers, Security Experts
Prerequisites: General interest in security, basic development experience
Level: Basic

Agile Coaches und Scrum Master sind in Transformationsprojekten besonders gefordert. Es braucht kontinuierliche Selbstreflexion und Klarheit, um in einer Veränderung eine neue Kultur vorzuleben und dabei selbst in Balance zu bleiben. In der Sozialen Arbeit ist Supervision der Standard und ein elementarer Teil der Qualitätssicherung, sowie der Burn-out-Prophylaxe für Mitarbeiter:innen. Wird es Zeit, auch im agilen Unternehmenskontext Supervision als Standard anzubieten? Wir glauben schon!

Maximale Teilnehmerzahl: 20

Zielpublikum: Scrum Master, Agile Coaches, Agile Führungskräfte
Voraussetzungen: Coaching, Neugierde auf sich selbst, Selbstreflexion
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das Wort Supervision kommt aus dem Lateinischen und bedeutet so viel wie „von oben betrachten”. Hier wird das eigene berufliche Handeln mithilfe eines Supervisors - der den „Blick von außen bzw. oben“ mitbringt - reflektiert. Supervision unterstützt das professionelle Handeln und macht Dynamiken, Zwickmühlen und Unausgesprochenes besprechbar.

Wir zeigen, was Supervision ist und auch was die Unterschiede zwischen Coaching, Supervision und Therapie sind. Außerdem erläutern wir, was Rahmenbedingungen und Handlungsanlässe für Supervision sein können.

Die Teilnehmer:innen werden Supervision in der Praxis erleben, Tools zur eigenen Supervision kennenlernen und sich - falls gewünscht - aktiv einbringen können.

Wir möchten so einen Beitrag für die Professionalisierung der Arbeit von agilen Führungskräften leisten, indem wir bewährte Qualitätsstandards der Sozialen Arbeit mit dem wirtschaftlichen Kontext verbinden.

Do you know that some forecasts project that in 2030 IT will account for 21% of all energy consumption? So, if we do not change the way we implement software, we will contribute to the increase in the carbon footprint. This means it is about time to take another look at how agile development can help decrease energy consumption.

In this workshop, we'll explore how the agile principles can guide us to more sustainability, and we'll provide you with concrete ideas for increasing sustainability in your product development.

Maximum number of participants: 100

Target Audience: Developers, Managers, Scrum Master, Product Owners, Coaches, ...
Prerequisites: Basic knowledge in agile would be helpful
Level: Advanced

Extended Abstract
The Agile Manifesto captures "better ways of developing software" yet, could this better way also take the environmental, economic, and social footprints of your software into account?

Software lifecycle creates direct and indirect carbon emissions: it has a footprint, worsening environmental problems. So, this session tries to provide the first answers to "how can the agile principles contribute to or guide sustainability?" In this workshop, we want to examine how the principles of the Agile Manifesto can provide guidance for implementing sustainability in IT.

In this workshop, we will explore the impact of the agile principles on sustainability, and how a greater awareness can change our current way of working for providing our contribution to addressing climate change.