If you’re not making mistakes, you have no chance to learn enough! This is especially true in complex situations, where, more often than not, the difference between a success and a failure can only be seen in hindsight. Which is why it pays off to dare new things, even if that might mean you can go wrong–as long as you don’t make the same mistake twice!

In this interactive talk we will explore how psychological safety, creativity, complexity and motivation are connected. And we will exercise our “No Blame – More Flame” mentality.

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

Extended Abstract:
Let’s remember, that in the beginning of IT and software development there was no chartered territory. There was no right or wrong path – great minds dared to venture on into new lands. And sometimes they failed. Spectacularly or subtle, with a chance of correction or at huge (monetary) sunk costs. But always with great learnings, albeit not always good documentation.

Yet in school and in life we often get punished for failures. And as a result, we learn that pointing the blame away from ourselves pays off. This is not only bad for the climate and culture in a team or in an organization, it is also detrimental when it comes to our ability to learn. Especially in uncertain and complex contexts, where this ability is crucial to survive and thrive. When we block our learning capabilities, we lose our powers to deal with the unknown, to adapt to new and emerging information, to explore solutions. This inhibits progress and kills motivation.

While most of the above facts are common sense or even common knowledge, it is quite hard to break the mental and behavioral habits we were taught throughout education and our work-lives.

In this talk I will summarize the concept of psychological safety and the effects of a psychologically safe culture on creativity and solution focus in teams. I will introduce a “tool” to adopt a more open-minded and learning focused mindset. The participants will get the opportunity to discuss how the tool can be applied in their individual contexts. Also, I will let the participants exercise a method which helps to change the interpretation of mistakes as something dangerous and evil to something viewed as valuable and helpful. The method uses failures as steppingstones to come up with improved solutions, which not only enhances the results but also lets us question our mistake-habits. Finally, I will wrap things up by speaking about how handling errors affects motivation.

When facilitating retrospectives, there is often a focus on the agenda, the activities and the experiments you take away from the retrospective. Also, there might be a technical theme for the retrospective, but the people and the process for cooperation and communication is often what you end up discussing.

I will provide you with tips and tricks for how to avoid neglecting the human aspect of your retrospectives; the trust, the different personality types, the feeling of safety, and what you can pick up from the body language.

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

Ein weit verbreiteter Glaube ist, dass nur konstante Teams langfristig zu hochperformanten Teams werden können. Jede Veränderung löst Teamprozesse aus, die das Team daran hindern, sich auf das Wesentliche zu fokussieren. Doch passt das nicht immer zum Kontext, in dem wir uns bewegen. Im Vortrag geht es um einen dynamischeren Ansatz, in dem sich die Teams nach Anforderung unterschiedlich formen. Neben dem Konzept geht es in dem Vortrag auch um die dafür notwendigen Rahmenbedingungen.

Zielpublikum: Projektleiter:innen, Scrum Master und alle, die mit größeren Teams arbeiten
Voraussetzungen: Grundkenntnisse von agilen Methoden und Teamdynamiken
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In verschiedenen Projekten stellen wir immer wieder fest, dass es ein sehr starres "Die Teams müssen konstant sein"-Denken gibt. Das ist auch häufig nützlich, aber nicht immer. Wir haben gute Erfahrungen mit dem Konzept von Floating Teams gemacht. Diese arbeiten an einem zentralen Backlog und bilden sich für jede Aufgabe neu. Entstanden ist das Konzept in einem Projekt, wo am Beginn nicht klar war, wie wir die Teams gut aufstellen können. In der Selbstorganisation haben sich nicht, wie erwartet, konstante Gruppen herausgebildet, sondern ein sehr gut funktionierendes, dynamisches Gebilde. Rückblickend wurde deutlich, dass ein zentrales Backlog, ein gemeinsames Big Picture (hier durch Story Mapping) und Erfahrung in der Arbeit in echten Teams notwendige Voraussetzungen sind.

Ich möchte mit diesem Vortrag Denkanstöße geben, aus dem starren Denken "konstante Teams" auszubrechen, und eine andere Option der Zusammenarbeit aufzeigen. In Trainings stelle ich es mittlerweile parallel zu anderen Skalierungsframeworks um zu zeigen, dass man mit sehr einfachen Mitteln, ohne komplexe Frameworks und Änderungen schon zu der Entwicklung guter Produkte beitragen kann.

As architects become more senior, we are expected to contribute to growing the product, the organization, and the people. This session explores three roles of an architect that help them meet these expectations: architect as leader, as mentor, as coach. This session offers practical tools, methods, and frameworks that help both experienced and aspiring architects succeed in each of these roles.

Target Audience: Architects, engineers, developers, managers, senior/principal/distinguished engineers
Prerequisites: Curiosity about how architects can be effective leaders, mentors, and coaches
Level: Advanced

Wieso haben wir so häufig das Gefühl, nur von Idiot:innen umzingelt zu sein? Was schürt in uns den Verdacht, dass die anderen immer so blöd sind? Wieso sind Geschäftsführer:innen so ignorant und verschwenderisch, Entwickler:innen so borniert, Admins so unfähig und Projektmanager:innen so ahnungslos? Wieso versteht eigentlich niemand Agile?

Wir wollen die Symptome der Idiotie betrachten und Ursachenforschung betreiben; herausfinden, warum wir selbst idiotisch sind und weshalb wir viel mehr Zeit zum Lernen brauchen.

Zielpublikum: Jeder, der mit anderen Menschen zusammenarbeitet
Voraussetzungen: Man hat sich dabei erwischt, andere für idiotisch zu halten
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wieso haben wir so häufig das Gefühl, nur von Idiot:innen umzingelt zu sein? Was schürt in uns den Verdacht, dass die anderen immer so blöd sind? Wieso sind Geschäftsführer:innen so ignorant und verschwenderisch, Entwickler:innen so borniert, Admins so unfähig und Projektmanager:innen so ahnungslos? Wieso versteht eigentlich niemand Agile?

Wir wollen die Symptome der Idiotie betrachten und Ursachenforschung betreiben; herausfinden, warum wir selbst idiotisch sind und weshalb wir viel mehr Zeit zum Lernen brauchen. In diesem Zusammenhang werden wir uns Cognitive Biases, Logical Fallacies, Heuristiken und das Fixed und Growth Mindset ansehen.