Take a Mess, Make a Mess, Fix the Mess - hands-on lab

Ever seen a code that needs modifications, lack tests and you fear touching would break the working software somewhere else? In this hands-on lab, we learn a way to take a mess - a working code that does provide value every single day - turn that code into testable, cover it with tests and then to use a counter-intuitive way to refactor that code into something where domain concepts find their own places while making modifications easy.

The legacy code dilemma is real - When we have to change code, we should have tests in place. To put tests in place, we often have to change code.

Thus, taking an untested mess is a challenge we face in real life. In this hands-on lab, we go learn thinking on how to approach such a challenge, safely. It also covers why is it important to add test cases - and when? In the lab, we also learn about test readability - and finally how to make a (different) mess to let the design to find it’s shape.

This lab is has 3 steps:
- Turn hard-to-test code into easy-to-test code
- Write test cases
- Find a business abstraction thinking outside-in

Take a mess. Make a mess. Fix the mess.

Ever seen a code that needs modifications, lack tests and you fear touching would break the working software somewhere else? In this talk, we learn a way to take a mess - a working code that does provide value every single day - turn that code into testable, cover it with tests and then to use a counter-intuitive way to refactor that code into something where domain concepts find their own places while making modifications easy.

Taking an untested mess is a challenge we face in real life. This talk is based on a series of exercises that can be worked on separately, built into a bigger code challenge. The talk goes through the thinking on how to approach such a challenge. Why is it important to add test cases? Why is it important to make the production code testable, in order to be able to test it? Why test readability is so important? And then - how to make a mess to let the design to find it’s shape.

This talk has 3 concepts
- How to turn hard-to-test code into easy-to-test code
- How to write a test case (and why)
- How to find a business abstraction thinking outside-in

Test everything like (it was) a unit test

Writing automated tests that are stable, fast and independent can be easy and cost efficient. With this model explained in this talk, Aki shows how this can be applied all the way to figuring out testing strategies for event-driven micro service architecture.

In modern software development, we programmers often experience unit tests that are brittle, hard to read and needs constant maintenance. And the other end of automated testing we often have is often hard-to-maintain end-to-end tests. It does not need to be like that.

In this talk, we will learn a model that is designed to empower participants with comprehensive insights and actionable strategies to enhance the stability, speed, and independence of unit tests. It also introduces a pattern that helps to more write maintainable and readable system level tests, especially within the context of event-driven microservices.

Because in the realm of agile software development, mastering the art of effective automated testing is essential. The reason Aki goes on stage to share this talk is to inspire you to learn and practice more these skills in your production app.

After this talk, you will learn to
- take ownership of test strategy as a whole team
- write stable, fast and independent unit tests
- write tests for event driven microservices
- plan automated testing strategy for a whole app.
- See how automation enables contemporary exploratory testing.

Empathy @ Work

A dance between truth and care - or how to speak up with courage while caring for the whole.

Viktor E. Frankl says: "Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.”

Empathy @ Work workshop is focused on exploring what happens in that space and to learn to regain the consciousness of the choice we always have.

The space is where we can explore what is truly true, what is happening within me - learning to connect to self and to listen oneself to understand what is important to us and what drives us forward. Then, in the choice, we can learn to make a conscious decision whether to listen the other emphatically or to express ourselves in a way that we maximise the odds to stay in connection with the other.

Studies (Nicole Forsgren et al., Brené Brown, Project Aristotle, etc) tell, that trustful relationships have strong positive correlation to organisational performance. And that trust is built in the smallest of moments through *paying attention*, *listening* and *gestures of genuine care and connection*. Empathy @ Work, based heavily on NVC, is a way to build trustful relationship and meaningful conversations and in that, does have strong positive (yet, second order) correlation to organisational performance.

The core learning we want to convey is to be inspired to *speak the most truth I have access to with the most care I have capacity for.* Because that does take individuals, teams and organisations forward.

Bridge the gap with empathy

We all have been in conflicts with our peers. We all have witnessed conflicts our peers have had. This is normal and part of our work and as it often is said: “conflicts are good, they even help us in becoming better in our craft”. Sadly, many of the conflicts in IT do have a destructive power of right-wrong thinking, strong opinions clashing with each other and such. These are not the “constructive conflicts” we often read in books and articles.

In teams with such destructive conflicts, imagine a person whose presence changes the dynamics in a way that brings people together in connection.
Imagine a person, who helps both sides to listen to each other in an argument, and enabling them to find a novel solution that is built on top of both ideas.

Would you want such a person in your team?
How about you become this person in your team?

This talk will explain 3 levels of empathy (cognitive, emotional and compassionate) and we will learn that we can get going even if only applying the cognitive empathy - through helping people see the point of view of the other without judging it.

This talk is for anyone who wants to help people bridge the gap of disconnection in situations of conflict.

Given to - Turning feedback upside down

Feedback loops is in the core of agile - it’s in the core of learning and growth. Yet we fail in giving/receiving meaningful personal feedback that people can hear and process. All this, even though there are many trainings and sessions on how to give feedback - and even when we are mindful on how to give it.

What if giving feedback is not where our focus should be the most?

What if the important thing is first to focus on receiving feedback rather than giving it?

In this talk, we will walk together through a model on how we can receive feedback in a way that we can understand the core of what the other wants to convey to us while also encouraging the other to give (more) feedback. This enables us to tap into the potential of finding the known unknowns (what other people see of us, but we don’t) - a crucial aspect of personal growth.

When we experience the joy of authentic feedback, to really listen the other on what is important for them to say - to listen the gift of feedback - then we can appreciate the challenge of giving it and steps on how to really make it meaningful. And at the same time, we can learn all the essential parts that can help us give meaningful feedback to others.

What we claim is, that experiencing the benefits of really listening feedback someone gives to us, is a crucial step for us in learning to set the stage for giving feedback. Because we also learn how to make the situation safe for both.
As Ruth Bebermeyer said in the poem Given to [edits by me],

> When you give to me [feedback], I give you my receiving [of the feedback]. When you take from me, I feel so given to.
>