Oredev Conference 2025 - Day 1

Learning and Improvement Conferences

Attending Öredev 2025

I was excited to attend my 3rd Öredev conference and my first as a member of the Program Committee.

In 2017, I spoke at Öredev on Reducing the Fear of Go Live.

Last year, I went to Öredev as an attendee.

This year, I was a co-chair of the Quality and Test track alongside Maria Kedemo.

In my opinion it was the best of both worlds, where as a speaker/program committee member, you get invited to speaker events such as the sauna and the speakers dinner, at the same time as an attendee/program committee member, you get to enjoy the conference and not worry about giving a talk.

Photo in Malmö town hall

Another photo in Malmö town hall

Buffet dinner

The bulk of our work was done over the course of several months earlier in the year where we reviewed proposals, discussed them etc.

In this blog post (and the upcoming ones for Day 2 and Day 3), I will share some notes on most of the talks I attended. (I can’t share notes for all of the talks I attended as some of my notes didn’t make any sense to my future self/I couldn’t read my handwriting)

Collective Risk Management by Joshua Kerievsky

In this talk, Kerievsky shared his experiences in software product development on building a more integrated, adaptive approach to managing risk together as a team.

“For Product Owners to succeed, the entire organization must respect their decisions.”

“The Product Owner is one person, not a committee…Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”

-The 2020 Scrum Guide

“XP teams practice refactoring mercilessly. Anytime you see duplication, you eliminate it. Any time you see something that could be clearer, you make it clearer. Anytime you see a more general way of doing something, you make it more general.”

-Kent Beck

XP has a practice called Collective Code Ownership. “Anyone can change any code, anywhere, at any time.”

“The reason risk management is hard to do in a typical corporate culture is that it encourages you to deal explicitly with uncertainty .” -DeMarco & Delister in Waltzing with Bears, Managing Risk on Software Projects

What Is Psychological Safety?

“Psychological safety is broadly defined as a climate in which people are comfortable expressing and being themselves.”

-Amy Edmondson, author, professor, speaker

In such an environment, you are not afraid to:

“The chief motive of all human actions is the design to avoid anxiety.”

-Ibn Hazm, 994-1064 AD

Sufficient design may be excellent to poor design, based on the context at hand.

I believe this was in reference to the fact that you don’t always have to aim for amazing design but sometimes good enough is, in fact, good enough.

Don’t let seniority, obedience or tradition impede innovation. Empower people to safely experiment and measure the impact of their ideas.

This shows how important psycholgoical safety is.

Make problems visible

The software kept crashing. PO was trying to add more features but they had magic spaghetti code that had to be addressed first. Kerisevsky printed out the longest function and taped it together as a scroll and showed it to management. (And filmed it with a camera). This showed management what the team was dealing with and how complex the code was.

Useful Resources Mentioned:

Is Your Culture Risk Managed or Risk Averse?

XP Practices that mitigate risk

Probabilistic Forecasting with Monte Carlo Simulations

Collective Risk Manageemnt Supporting Practices

Reframing a Career: Tester to CTO by Katrina Clokie

This was a talk I was particularly excited about. Clokie is someone I have looked up to since the start of my career. In New Zealand, I worked at same consultancy as her at the start of my career and interviewed her in 2015 on my Youtube channel.

Clokie reflected on her career journey over the past two decades and identified how the skills she learned as a tester were reframed in her role as a CTO.

At the start of her talk, she provided context that she wasn’t just a tester (no one is) but that she wrote a book, organised meet ups, had a testing magazine and was (is) a prolific blogger in the testing space.

Below are some lessons she has learned in her career:

You can reach a point in you career that your own manager is so busy to help you as much.

You can reach the end of the path but not sure where to go next, this often means that you may need to take a jump into the unknown/ something different.

She also shared her experiences in having job ads where there is a disconnect about the job advertised and the job that actually exists and talked about how her identity was closely aligned with software testing (through her book, other work).

What skills can you reframe (moving from a tester to a CTO role)

Katrina shared her thoughts on Stakeholder Management and how she has gone about it as a CTO:

Strategic Thinking

Useful Resources Mentioned:

Career journey from Tester to CTO

Lean Trade Me Dashboard

Leading Complexity: Modeling What the Moment Needs by Xin Yao

Xin Yao shared some conversation models she has found useful when leading in complex situations. There were also some audience participation in this session where we exchanged ideas with our neighbours.

I didn’t take as many notes in this talk as I found her slides were better at articulating the information in a visual way but below is a quote that I took note of:

“One of the ways of thinking about leadership is thinking about convening conversations that might not happen otherwise.. and having the courage to do that.” -Patricia Shaw

Complexity Leadership definition

Global Employee Engagement Status

Modeling Contexts

Global Employee Engagement Status

The Dissent Conversation

The Invitation Conversation

Pre-decided outcome example

Prompts for bringing up topics that seem to be off the table

The Ownership Conversation

The Commitment Conversation

The Gifts Conversation

Useful resources mentioned:

Everything the Tester in your life wants you to know about testing but is too afraid to tell you by Vernon Richards

Richards’ talk filled the room with laughs and nods of acknowledgement. This showed that indeed, he spoke about what testers want others to know, but are too afraid to say.

I’m very happy that he was able to reach non-testers with this talk and present it at a developer conference.

Some of the things testers are afraid to tell developers include:

A lot of what drives a tester’s career arc is the phrase: “This would be easier if I could…”

As a tester becomes more senior, it becomes less about finding bugs and more about changing the system in which they work - so they can do their job.

Vernon shared that the tester’s role is fairly unique in this way. Often testers have to address how the team works, for the tester to do their job effectively.

The Testing Career Arc

The Authority Gap

Decoding Synthetic Monitoring: A Journey from E2E UI Tests to Service-Level Probes by João Proença

Proença shared his experience using Synthetic Monitoring in his organisation and some advice on whether to know this could be relevant in your setup.

They faced the challenge of having different teams, different contexts, different technologies.

Why don’t we use existing UI tests cases/scenarios in production for monitoring purposes? (Testing the core features) But they had to be careful because UI TESTS can be flaky.

Don’t over utilise UI automation - there are times it makes sense and other times it doesn’t.

What is Synthetic Monitoring anyway?

Prometheus probes: What if we chained HTTP requests together mimicking use cases/ what the front end would do from the API perspective?

You can set up more sophisticated alarms/ rules where people only get notified if 2/5 probes fail (for example). With great speed comes great flexibility.

Some reasons to consider Synthetic Monitoring:

Useful Resources Mentioned

Problem with UI Approach

Prometheus Probes

Metrics in Honeycomb

Context switching when investigating problems

Learning and Improvement Conferences