A PO’s View on Releasing


… and what that means for the tester.

I’m still in the Healthcare project where we’re strangling small pieces of functionality out of a big monolith of software that was built over the course of 20+ years.
Next month, we’ll put our first real strangled functionality into production. In a docker container. With horrible UI. Yes, releasing is a matter of months for us. That’s not what I’m worried about right now.

The past week, I noticed myself saying: “I don’t care about quality.” and “We don’t need to fix that logical gap.”. Things I wouldn’t be able to reconcile myself with when I was a tester. My view on releasing, and the quality of said release has changed as well.

That ‘I don’t care about quality’ was mainly to make a point. It wasn’t correct. I just care less about certain aspects. The UI is not well structured, black and white and far from appealing. But everything we need is there. Looking at our new screen, any user will curl their upper lip.

Additionally, when you open a (closed) file from last year, you’ll get a blank screen. No user friendly message, apology or workaround. It’s not optimal, but it’s just not important to me and I’ll gladly defend that to anyone.

What does interest me are two very different aspects: Security and Performance.
(This is by the way why RiskStorming is such a great workshop to do in the beginning of such a project. As this information shouldn’t come as a surprise to anybody.)

Positive User Feedback is currently a low priority for me. We’re doing a very minor change when it comes to our users. However, the change touches upon some very important data. Data you don’t want to have stolen. That’s my first priority.
The second one is successfully working closer with our Operations department. The better we can make that collaboration, the easier we’ll have it in the future.
A third priority is making it run smoothly in production at all. If it’s a flop, it’s merely a flip of a parameter to revert.

These kind of decisions don’t make me particularly popular with the testers in the team.
I apologise for this, yet they are the product of careful listening and thinking.


Skiing with Team members

What does this mean for Testers?

In the aforementioned context, it can be daunting to be a tester. They might feel out of the water concerning expected expertise and they might feel discouraged because many issues are dismissed.

Consider this: I’m currently laying tracks for a train to cross America East to West around the 1860’s. I expect it to be bumpy. I expect troubles. The passengers should have a good chance of arriving at the other side, but in the face of danger, we should be able to turn back. The testers can’t safeguard this project from bandits, explosions, landslides,… They also can’t simulate half of these things or more as they lack expertise, resources,…
However, they can gather information on as many potential points of failure as possible and provide possible alternatives.

They might not know Security Testing or Performance Testing, but they know Risks and have the skills to identify weaknesses.
I expect them to use their words and arguments to do everything in their power to make sure I abandon the project as a whole.
… and have the patience, respect and open mind to accept unpopular decisions made by the PO.
Not that this has been an issue as of late, but I clearly remember my own frustration when faced with what my testers are facing now. I guess it’s never too late for some lessons in humility.


How my Testers help Me


In the beginning of last year, I moved from a Test Consultant to a Product Owner role and I haven’t written much since. Gaining so many insights over that period from: My role change, remote working teams, testing strategy workshops in other companies, Agile transformation of a HealthCare company and much more. It’s been a tumultuous year, but a rollercoaster in learning and insights. The end of the ride is not in sight.

My first insight I wish to explore is how I, as a PO, am dependent on testers: My in-team tester, our automation specialist and the separate team of testers.

In my role, I am mainly concerned about delivering a quality product that people are sufficiently happy with. It shouldn’t be stellar. It doesn’t have to be perfect. It has to be an improvement. 

That’s the context I work in. We’re trying to replace a big monolith of ancient software into smaller pieces of understandable, working software using strangling patterns.

A strangling pattern in short: You identify the boundaries of a piece of functionality, you build a completely, separate duplicate of the functionality and feed the exact same inputs to both pieces of functionality in a test or production environment. Then you monitor the outcomes. When, over time, the outcomes are consistently the same you can replace the old functionality with the new.

This pattern is used in situations where functionality has become so complicated, so bloated that any change can cause a ripple effect across the software destroying just about anything.


Team Day in the mountains

The Team Tester

Given this situation, I rely highly on the software testers. My team’s tester has been working for the company a lot longer than I have and has a wealth of knowledge when it comes to the application and its history. That’s why me and the team need him to:

As Early As Possible:

  • Warn us about possible points of failure;
  • Inform us about potential risks and their outcomes;
  • List problematic parameters and outliers that we might forget;
  • Talk to & prepare other testers about the changes that are coming.

During Development:

  • Support the team by providing information, good and bad, about the current state of the product;
  • Inform the PO about the progression on achieving of sprint goals or not;

After Development:

  • Support me in handing over the changes to our most direct stakeholders;
  • Hand over the changes to the separate test team so that they can see what actually was finished.

In other words, he’s a bit out guardian angel. Not the kind to swoop in and save the day, but the fairy-god-person type that’s always watching our backs and supports us to overcome problems ourselves.

The Automation Specialist

To be honest, when it comes to automation on the service or UI level, it’s not profitable for us yet. Our specialist has her hands full maintaining old selenium scripts for the big monolith. Voices constantly rise up whether these scripts are worth the investment time and again. For now, we persist.

Next to the maintenance, she’s also involved in pair development with the others in the team, learning about implementation new user stories. She’s involved in pipeline improvements and team discussions about for example: the depth and effort the team wants to put in TDD practices and so on.

With our move to Windows containers for our test systems and hopefully also production, she’ll have her hands full supporting the team in providing checks and information on stability.
For I want them to streamline everything so well, that in the future they can give me a button: a button that I can push at any time, that deploys our current devbranch into production.


OktoberFest, with the Alps in the background

The Separate Test Team

This is a whole different article that needs to be written. Potentially, this is the point in the Agile Transformation that has had the biggest change and effect on the reliability of our releases of all.

In the past year, I’ve seen our releases go from “Always going horribly wrong, needing four to five hotfixes” to “A release with scheduled hotfixes” to “A stable release with little to no problems.”
These changes can be attributed to changes across the whole development process, but it is a marvel to observe how much more efficient the test team has become.

I saw them, under guidance of great test consultants, abandon most of their documented test scripts and develop mindmaps and checklists. They focused on efficiency, speed and supporting rather than complaining, defending and acting like martyrs.

To Conclude

The testers I work with cover a lot of ground. They focus on results and moving forward, by amplifying the team through information. Information that is actionable and valuable.

It hasn’t always been like this. Together, we’ve come from a very ‘structured’ process where people were working in separate roles on a monolithic software problem, making our situation worse and worse by the day.
What turned it around was:

  • Problems being made visible;
  • Protection being provided by (and from) management;
  • People’s roles being mixed;
  • Teams getting a vision, but otherwise left to their own devices;
  • Relentless positivism;
  • Strong consultants that support with knowledge and learning.

Little change after little change each of us started to see a little light in the darkness. That’s all one needs to keep moving forward. So we joined hands and started in that direction together.


Part of the team, chilling

Product Owner of Test Automation


2018 is another year of change for me. I packed everything I needed in 4 bags that fit my bike and on the morning of the 3rd of January started pedaling south.
Tom Waits – Whistle down the wind in my ears.


Wind in my back, sun in my face. It felt as if something beckoned me, helping me forget what was left behind.

Car, house, job, security, city, comfort, relationship… everything was sacrificed. At least for now. In return I got freedom and a different kind of comfort. I can do whatever I want, enjoy what comes my way and seize all the wonderful opportunities that would otherwise make me think twice.

Since then, I’ve arrived in Munich, a bustling city. Met with QualityMinds, a wonderful company and rejoined with friends who showed to be more than true to the name.
Vera & Marcel have been absolute angels. Supporting me by opening up their home, workplace, baking birthday cake, being motivators and listening to my stories. Vera even found an ideal job for me.

Product Owner of Test Automation

A change in roles comes with an interesting set of insights. I had never been a Product Owner before, nor is my technical prowess in Test Automation of much note.

I do have a knack for connecting people, empowering people and strategising in function of change. Because of this, I’m sure I can add value over the coming months. In my years of being a tester in a SCRUM team, I figured out that the nature of the Product Owner role is hands-off, enabling and providing feedback. However, what I didn’t see before was the effort it takes in finding out how to balance the following:

  • What needs to be done to satisfy our stakeholders in the short term?
  • What can be done within the current constraints?
  • What does the team like to do?
  • What does the team need?
  • What can we do in function of the long term vision?

I feel a tension between now and later, us and them, needs and wants and I like the implications this has. It means my reporting and communication needs to be better. It means I need to listen as much as I talk. It means that I need to direct now to have others evolve later.

Personal introspection and (hopefully) progress, I love it.

For now, I visualise myself sitting at a table on which a massive boardgame is displayed. I’ve only just gotten to know the other players. This game has been going on for some time and I’m the new player. I see the cards I hold and plan for success whilst guessing for surprises that will sweep my feet from under me. I plan now to act later, slowly positioning allies, empower certain areas and planting ideas in the other player’s minds.
The path to victory lays before me, but so are the hazards and changes.

A good strategy goes a long way, but needs hard work, luck and support from others to succeed.

The Strategy

Phase 1:

  • Become a functional SCRUM team that adds value by means of either added confidence or fast feedback.
  • Build a stable and maintainable checking framework as a team.
  • Build a strong relationship with Stakeholders

Phase 2:

  • Coach and strengthen automation practices throughout the development life-cycle by example.
  • Support Testers through handy tools and automating the boring stuff.
  • Provide compelling data and reports to stakeholders who need to make decisions.

While a Strategy is rather deterministic for now, the tactics will certainly change over time. My first challenge is in splitting up the base tactics into workable tasks. Secondly, listening to the team on how they deal with this and how they would move forward.

I’m anxious to find out how things evolve from here.