On this site, there is only displayed the English speaking sessions of the OOP 2021 Digital. You can find all conference sessions, including the German speaking ones, here.
The times given in the conference program of OOP 2021 Digital correspond to Central European Time (CET).
By clicking on "VORTRAG MERKEN" within the lecture descriptions you can arrange your own schedule. You can view your schedule at any time using the icon in the upper right corner.
Track: Half Day Tutorial
- Back to Architecture
- Business Agility
- Design Erosion & Learning from Failure
- DevOps & Continuous Everything
- Diversity & Inclusion
- Domain-Driven Design moving forward
- Full Day Tutorial
- Fusion: IT-Future-Society
- Half Day Tutorial
- Modern C++ Programming
- Modern Enterprise Architecture
- Product Discovery, Customer Centricity & RE
- Signature Track: Back to the Future
- Social Integration
- Testing & Quality
- Trends & Techniques
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
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
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
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!
Peter Zimmerer is a Principal Key Expert Engineer at Siemens AG, Corporate Technology, in Munich, Germany. For more than 25 years he has been working in the field of software testing and quality engineering. He performs consulting, coaching, and training on test management and test engineering practices in real-world projects and drives research and innovation in this area. As ISTQB® Certified Tester Full Advanced Level he is a member of the German Testing Board (GTB). Peter has authored several journal and conference contributions and is a frequent speaker at international conferences.
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
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
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
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:
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
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!