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.

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.

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.

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!