Retrospectives are indispensable for continuous learning and improvement in Lean, Agile, DevOps, and other contexts. But too many organizations run retrospectives “in name only,” and fail to generate the value they promise. In this tutorial, Aino introduces common antipatterns that undermine the effectiveness of retrospectives, and shows exactly how to overcome each of them.

In a mixture of short presentations and activities we will look at body language, psychology behind retrospectives, online retrospectives, types of retrospectives, etc.

Target Audience: Facilitators, project leaders, managers, coaches, team leaders, Scrum Masters
Prerequisites: Have facilitated retrospectives or wants to facilitate them in the future
Level: Advanced

Extended Abstract:
Using the familiar “patterns” approach, she introduces antipatterns related to team and meeting structure, inadequate or counterproductive planning, human interaction, and much more. From “blaming and naming” to too much smalltalk, negativity to cultural disconnects in distributed teams, Aino reveals traps she’s encountered in leading hundreds of retrospectives – and presents proven solutions. With her insights and guidance, you can run retrospectives that deliver actionable improvements and concrete value — not just once, but over and over again.

Let’s reflect on the value of variety for avoiding blind spots. For this, we’ll explore some barriers we face when encountering different viewpoints. We’ll practice ways to change perspectives & build on others’ opinions. And we’ll take a look at how small changes in attitude can benefit all of us.

There will be input on general foundations for healthy & productive teams, like psychological safety & having a “good mix” (e.g. in culture, function & gender). We’ll also develop ways to ensure that these rich inputs are applied to a common goal.

Maximum number of participants: 25

Target Audience: Leaders, Developers, Managers, Teamplayers
Prerequisites: Curiosity and willingness to challenge one's own habits
Level: Basic

Extended Abstract:
Some of us have been privileged enough to usually have their voice heard, when they spoke up. That often happened at the price of others not being listened to, their needs and opinions being disrespected and the effects on their wellbeing being ignored. These injustices have been committed across vocations, generations, intentions and cultures. One common denominator for these wrongs is the inability to change perspective. So, let’s start by flexing and training that muscle!

As an introduction to my workshop I will give some input on how I define a healthy team. To me, this has to do with psychological safety and including different views. I will speak about some factors that determine and enable psychological safety, basically that it is safe to show yourself vulnerable. Once we can bring our authentic selves to the table, we need to be seen. This in turn requires the others to be able to change perspective. If we don’t achieve this, we will always risk having huge blind spots, as our own experiences, skills, opinions and backgrounds determine how we perceive our environment.

I will demonstrate the effect of having blind spots with 2-3 fun exercises and reflect the learnings with the participants. We will map this with findings from research on how our cultural backgrounds shape our perception.

In creativity and innovation, we use a range of tools that help people consider different perspectives and look at problems from several angles. I will share some examples and discuss the benefits they bring and how these can be applied outside of creativity workshops.

Then I will outline three concepts I apply in my work: separating different types of thinking, unconditional appreciation and appreciative inquiry. The participants will apply this in an interactive simulation which involves stating an opinion, changing perspective and reflecting on the effects of this.

Finally, I will provide some insights from the field of creativity on how to train our ability to change perspectives and what evaluation and judgment do to our flexibility and our capacity for inclusion.

If the situation warrants it (and the participants wish for it), I will include suggestions how to incorporate the workshop learnings for remote settings.

You will learn

1. why teams need psychological safety and a “good mix” to be healthy,
2. to watch out for some barriers to open minded and inclusive habits and
3. how to train your abilities to change perspectives and be more inclusive.

We know that quality cannot be tested into our products afterwards, but we typically could do much more in our testing approach to built-in quality right from the beginning. But how does this look like in practice?

This interactive tutorial provides practical guidance on the needed strategies, tactics, and practices in different areas, and shares experiences and lessons learned to do better testing in the future!

Maximum number of participants: 25

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

Extended Abstract:
Today we have to 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.

We know that quality cannot be tested into our products afterwards, but we typically could do much more in our testing approach to built-in quality right from the beginning:

• This means even an improvement to classical defect prevention: defect prevention is good, but just “avoiding” some defects does not mean that we build something really “right”.
• This is more than just the trendy shift-left approach in DevOps.

But how does this look like in practice?

This interactive tutorial provides practical guidance on the needed strategies, tactics, and practices in different areas, and shares experiences and lessons learned:

• Requirements and test-driven approaches (xTDD)
• Utility trees and quality models
• Scenario descriptions and test design techniques
• Design strategies and design tactics
• Design for Testability and test architectures
• Mindset by example

Attend this tutorial and do not only learn what built-in quality really means but be enabled to apply the strategies, tactics, and practices as a major lever for better testing in the future!

Statische Typsysteme sind im Frontend angekommen! Anders als das populäre Typescript geht ReasonML - die Sprache des React-Erfinders Jordan Walke - noch einen Schritt weiter und bringt eine funktionale Programmiersprache in den Browser.

Mit der Sprache kommt die Neudefinition des React-Frameworks: ReasonReact. ReasonReact bietet einen typsicheren Weg, um Komponenten in einer JSX-ähnlichen Syntax zu erstellen.

Inhalte des Workshops:

• Modellieren mit dem Typsystem
• Frontend in ReasonReact
• Unit-Tests in bs-jest

Maximale Teilnehmerzahl: 12

Teilnehmer:innen benötigen vorab auf ihrem lokalen Rechner ein lauffähiges Node.JS und Visual Studio Code.

Zielpublikum: Entwickler:innen, Architekt:innen, Frontender
Voraussetzungen: Grundlagen der Webentwicklung, eigenes Notebook mit NodeJS und Git
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Statische Typsysteme sind im Frontend angekommen! Populär wurden sie dank Typescript und Flow. ReasonML - die Sprache des React-Framework-Erfinders Jordan Walke - geht noch einen Schritt weiter und bringt eine funktionale Programmiersprache aus der ML-Familie in den Browser. ReasonML kombiniert die Semantik von OCaml mit der gängigen Syntax von JavaScript.

Mit der Sprache kommt die Neudefinition des populären React-Frameworks: ReasonReact. ReasonReact verwirklicht endlich die ursprüngliche Vision des React-Schöpfers - ein voll auf funktionale Programmierung ausgerichtetes Frontend-Framework! Das Framework ist bereits mit Hooks und Reducern ausgestattet. Es bietet außerdem einen typsicheren Weg, um Komponenten in einer JSX-ähnlichen Syntax zu erstellen - ohne die Notwendigkeit einer Überspezifizierung, dank Reasons ausgezeichneter Typ-Inferenz.

In diesem Workshop

• werfen wir einen Blick auf die Konzepte der Sprache ReasonML.
• modellieren wir eine Domäne mit dem algebraischen Typsystem.
• erstellen wir eine einfache Frontend-Anwendung in ReasonReact.
• schreiben wir Unit-Tests mit bs-Jest.

Mit ITIL4 steht seit Februar 2019 ein Framework für agiles Service-Management bereit, das das "alte" ITIL explizit in Richtung von agilen Ansätzen öffnet und für eine neuartige Nutzung bereit macht. In der Tat kombinieren viele Organisationen verschiedene Konzepte, um ihre IT effektiver zu gestalten und agile Ansätze zu skalieren. In diesem Workshop werden die Neuerungen durch ITIL4 kurz dargestellt, mit DevOps zusammengeführt und dann anhand ausgewählter Aspekte die Skalierungsmöglichkeiten für hoch performante IT-Organisationen erarbeitet.

Zielpublikum: Führungskräfte im IT-Management, Teamleiter:innen, Service-Manager:innen, Scrum Master, Product Owner
Voraussetzungen: Allgemeine Erfahrungen in der agilen Software-Entwicklung oder im Betrieb von Applikationen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Für agile Organisationen steht ITIL als verstaubtes und stark reglementierendes Framework. Die ITIL-Prozesse und Vorgaben stehen in vielen Unternehmen als Gegensatz zu autonomen und selbstorganisierenden DevOps-Teams. Spätestens wenn mehrere Teams an einem Produkt arbeiten, agile Entwicklungsteams aus vielen Menschen bestehen und die Betriebstätigkeiten wirklich in den DevOps-Teams etabliert werden müssen, stellt sich die Problematik der Skalierung. Aufgrund der jahrelangen Erfahrung des Autors in beiden Welten wird ITIL4 als idealer Ansatz für eine sofort nutzbare Skalierungsmethode erläutert. ITIL4 hat sich neu erfunden und kann bspw. sehr schön über den Value Stream-Ansatz mit DevOps kombiniert werden. In diesem halbtägigen Workshop stecken knapp 2 Jahre Erfahrung in der Konzeption und Durchführung sowie mehrere Inhouse und offene Seminare.

Nichtfunktionale Eigenschaften haben entscheidenden Einfluss auf Software-Architekturen. Ihre effektive Umsetzung ist daher kritisch.

Das Tutorium führt in szenariobasierte Architekturerstellung und -bewertung ein (u.a.mit ADD, ATAM, CBAM). Um das konzeptionelle Wissen gut zu verankern, führen die Teilnehmenden praktische Übungen durch. Adressiert werden auch Fallstricke und wie sie sich vermeiden lassen, ebenso wie Beteiligung und Verantwortlichkeiten verschiedener Rollen.

Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Praxiswissen Software-Architekturen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bekanntlich haben nichtfunktionale Eigenschaften den größten systemischen Einfluss auf Software-Architekturen.

Attribute-Driven Design (ADD) illustriert, wie sich Qualitätsattribute gezielt in Architekturen einfügen lassen.

Methoden wie ATAM (Architecture Tradeoff Analysis Method) und CBAM (Cost Benefit Analysis Method) sind nützlich, um Software-Architekturen hinsichtlich nichtfunktionaler Eigenschaften zu überprüfen. Alle genannten Methoden basieren auf Szenarios.

Das Tutorium führt in die Grundlagen szenariobasierter Architekturerstellung und -bewertung ein. Um das konzeptionelle Wissen gut zu verankern, führen die Teilnehmenden praktische Übungen durch. Das Tutorium adressiert dabei auch Fallstricke und wie sie sich umgehen lassen sowie die Beteiligung und Verantwortlichkeiten verschiedener Rollen beim szenariobasierten Vorgehen.

In diesem Tutorial wird gezeigt, wie man das Sec in seinen DevOps-Workflow integrieren kann. Am Beispiel einer einfachen vorbereiteten App werden wir unter Zuhilfenahme von Open-Source-Tools bekannte Sicherheitslücken in Drittanbieter-Bibliotheken und Containern suchen, zusätzlich werden wir auch die APIs der Anwendung mit einem dynamischen security-scanner angreifen, der einfache Angriffe ausführen wird.

Weiterhin werden die Teilnehmenden sich damit beschäftigen, wie sich eine CI-Pipeline mit diesen Techniken erweitern lässt.

Maximale Teilnehmerzahl: 10

Benötigt wird ein Laptop mit folgender Software:

• Docker
• Java
• Nutzung von maven oder gradle (muss nicht installiert sein, es sollte aber Zugriff auf maven central erlaubt sein)

Zielpublikum: Entwickler:innen
Voraussetzungen: Kenntnisse von Java und maven/gradle. Wissen über Continuous Integration hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Im Tutorial soll vermittelt werden, dass man auch ohne viel Sicherheits-Erfahrung durch (automatisiertes) Tooling schon während der Entwicklungszeit, aber auch im Betrieb, viel über die eigene Anwendung und deren Schwachstellen lernen kann, aber auch Prozesse erarbeiten muss, um diese zu beheben.

Beispiele werden anhand einer vorgegebenen Java-Anwendung erarbeitet, die auf Basis von Springboot, maven/gradle gebaut wird und mit REST-APIs arbeitet.

Wir werden uns mit Dependency-Check beschäftigen, um bekannte Sicherheitslücken in der Anwendung zu finden und zu behandeln, für Container werden wir clair oder trivy kennenlernen.

Um auch zur Laufzeit der Anwendung Angriffsmöglichkeiten zu erkennen und vorzubeugen, wird die API der Anwendung mithilfe von ZAProxy angegriffen

Die Integration in die vorhandene CI-Pipeline zeigt auch die Automatisierbarkeit, bringt aber nicht nur Vorteile mit sich, "free" gibts eben nicht "gratis".

In einer abschließenden Diskussion möchten wir zusammen mögliche Einschnitte, aber auch Verbesserungspotenzial und mögliche Prozessänderungen besprechen.

Für den Workshop sollte ein Rechner mit lokalem Docker daemon vorhanden sein.

How can we get better as software designers? By becoming more aware of our design heuristics and intentional as we cultivate and refine them. Heuristics aid in the design and even determine our attitude and behavior. We each have our own set of heuristics that we have acquired through reading, practice, and experience. In this session, you are presented with a modelling problem that you will try to design in groups. Let us share these heuristics during a modelling session!

Maximum number of participants: 24

Target Audience: Software Architects, Senior Developers
Prerequisites: Senior developers and architects
Level: Advanced

Extended Abstract:
How can we get better as software designers? By becoming more aware of our design heuristics and intentional as we cultivate and refine them. Heuristics aid in the design and even determine our attitude and behavior. For example, agile developers value frequent feedback and decomposing larger design problems into smaller, more manageable chunks that they design and test as they go. We each have our own set of heuristics that we have acquired through reading, practice, and experience. Let us share these heuristics during a modelling session!

In this session, you are presented with a modelling problem that you will try to design in groups. During designing, we will rotate observers that will capture and map heuristics they see happening. Once everyone observed the group will share and discuss the heuristics they observed. Finally, we will wrap-up with the whole group explaining and sharing the key heuristics used in each group.

Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session.

Maximum number of participants: 75

Target Audience: Architects and Developers
Prerequisites: Java Programming
Level: Advanced

Extended Abstract:
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session and you will be in a good position to put Reactive to use on your projects. We will start from foundational building blocks and scale up to full Reactive implementations. If you bring your laptop and Java 1.8+ or C# for .NET Core 2.1+ you can try out Reactive during the session.

Jeder von uns kennt Performanceprobleme. Diese zu erkennen und zu beheben, ist eine Kunst. Nicht immer liegen diese Probleme aber am eigenen Code. Es ist somit unabdingbar, die Welt abseits des eigenen Codes kennenzulernen.

Hierfür benötigt es neben soliden technischen Kenntnissen auch Kreativität, Einfallsreichtum und ein wenig Fingerspitzengefühl im Umgang mit Menschen. In diesem Workshop erarbeiten wir uns dazu das notwendige Handwerkszeug: Die Hard- und Softskills zur Lösung von Performanceproblemen.

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

Extended Abstract:
Jeder von uns kennt Performanceprobleme. Diese zu erkennen und zu beheben, ist eine Kunst. Nicht immer liegen diese Probleme aber am eigenen Code. Es ist somit unabdingbar, die Welt abseits des eigenen Codes kennenzulernen.

Und hier kann es schwierig werden. Denn bei der Lösung von Performanceproblemen sind wir auf die Hilfe von anderen angewiesen und müssen unsere eigene Komfortzone verlassen.

Hierfür benötigt es neben soliden technischen Kenntnissen auch Kreativität, Einfallsreichtum und ein wenig Fingerspitzengefühl im Umgang mit Menschen. In diesem Workshop erarbeiten wir uns dazu das notwendige Handwerkszeug. Dazu stellen wir sowohl technische Methoden (Hardskills) vor als auch Methoden aus der Kommunikationslehre und dem Coaching-Umfeld (Softskills). An einem konkreten Fallbeispiel wenden wir diese direkt an und sammeln Erfahrungen für den Einsatz in der Praxis.

Functional programming is the future of software development. As software gets ever more complex, unintended side effects flourish - you push on one side, and something unexpected squirts out the other. Functional programming cuts down on complexity through high-level abstractions, and avoids unintended side effects through pure functions. The result is simple and elegant code that captures the essence of the problem you're trying to solve. Fortunately, functional programming is easy to learn, and this tutorial will get you started.

Maximum number of participants: 48

To follow along with the tutorial, we recommend that you download the Racket software:
https://racket-lang.org/
If you use your OS's package manager to install Racket, make sure you install its IDE, DrRacket

Target Audience: Developers, architects
Prerequisites: Basic programming knowledge
Level: Basic

Extended Abstract:
Functional programming is the logical continuation of object-oriented programming: OOP managed to encapsulate mutable state with the goal of ultimately eliminating it one day, and functional programming finally realizes that vision. Language implementations have been mature and robust for many years now, and the practical functional languages - Haskell, OCaml, Scala, Clojure, F#, Racket, Erlang, Elixir, Swift - all have thriving communities and ecosystems. Moreover, decades of experience and research teaching functional programming have produced effective didactic approaches that enable anyone into programming to easily get into FP. The time to get started is now!