From Tester to Product Owner

Now that I have done my first 6 months as a Product Owner, I would like to write about four tools I had on my tester belt that came handy when it was time to do the Product Owner thing.

Broken clutch cable == no problem!#Vespa life! #Px200 pic.twitter.com/liaZBaJYDf

— Jokin Aspiazu Jensen (@JokinAspiazu) April 18, 2018

1. Problem bash.
In software testing, doing a bug bash is about getting people around some software, defining the scope and the mission and letting people work around the feature trying to find as many bugs as possible.
As Product Owner, there has been a couple of times where we performed a problem bash, where we sat the whole team around a problem, and talked about how we were going to approach the solution. Once we got the understanding of what the problem was, and what a solution might look like, I started writing the user stories, but not before.

In both cases, you get the benefit of diverse points of view, you get the benefit of a shared process of learning, you build the team that is going to work on the solution, and both cases are a fun thing to do.

2. Cynefin for Product Owners. 
Cynefin is a framework for understanding complexity. Testers who know about this framework know what kind of testing is best depending on the situation the project is in, so, depending if you are learning, if you have experience, or if this is a crisis situation, different techniques should be applied to the development process and the testing.
When it comes to Product Owning, when it comes to writing stories for the team to work on, I realized that we could use the framework.

Simple, When there is no learning to do, when everybody knows and understands what needs to be done. Simple problems can live in the backlog for months waiting to get some time window to get solved, and if all you have are simple problems, you can work in slow one month sprints. Simple issues are rare.

Complicated, When only somebody in the team has the expertise to work in the problem, then writing the issue is not enough, now we need to make sure the availability of the one who understands the problem, and that this person can help others understand it as we fix it. Also complicated is when the learning has a impact in other teams, say Operations or Customer Support, then the learning that will happen with the solution needs to be planned and shared. When you have several complicated issues, you want to move to shorter sprints, say two or three weeks, so you can get the feedback from the involved teams about how all these changes are doing.

Complex, When nobody in the team, the company or anywhere else has solved this problem before, then we need some space to experiment in a safe way, to understand first and learn after. Once you get into this complex problem point, estimations about when solutions will get done are meaningless, since you can not predict the time you need for discovery. When we got into a complex scenario, I tried to run the backlog without a defined sprint, and even that the first weeks the team ran quite well, while everyone was aligned and working in the same problem, it happened that as the weeks passed, we kind of missed the pace you get when you work on sprints, and we moved back to one week sprints.

Chaotic, You run into chaotic situations when the team needs to solve situations without considering backlog, when you are impacting users in production or when you put the business into risk. When this happens, you need to understand that the flow of information is going to be different, that your stakeholders are now support or infrastructure teams, that you need to help for the stabilisation of the problem first, and then do the analysis and the learning.

Disorder, Good old Disorder is when you are not aware of the right situation. So you ask the team to handle a certain problem in a way that doesn't match with the situation the team is in.

3. Context Driven Product Owning.
When I started testing software, the Context Driven Testing approach got me hooked, I understood how to get out of testing with test cases, I understood how I should better use my time as a tester, and when I moved into an agile team, it helped me to fit into this new mindset. Also the community around this principles happened to be very supportive for me, at that moment.
So, when I moved into Product Owner role, I could still make good use of the principles that were defined. I'll give you my top three:

• People, working together, are the most important part of any project’s context. And when we say people, it is not limited to the development team, it has to be wider, and include other teams in the company, Operations, Support, Infrastructure, Security... and also teams who work for other companies trying to build integrations.

• Projects unfold over time in ways that are often not predictable.
  Sometimes you start a project that seems to be the most important thing to work on, and as the project evolves, and the learning happens, some of the assumptions we started with will fade away, developers might run into technical issues that were not anticipated, or anything in between, from marriage, birth and other vital issues, to legal, compliance or whatever other happenings. When you are going to run projects, you better get ready for this, and deal with it.

• The product is a solution. If the problem isn’t solved, the product doesn’t work.
  Sometimes we might develop the solution we want to do, with this team, in the time we want to spend working on it... and once we have built it, we find out that the problem doesn't really fix into our solution, or that now that we have built something new, we run into new issues.

4. Storytelling.
As a tester, you soon understand that part of your success is how well developers are able to understand your bug reports. Writing "This is not working" is not an option, and you need to elaborate your writings, after all, this is your contribution to the team, so you need to learn how to do this.
When you move to Product Owner, the team trusts you to help them understand the problems we want to address, so again, writing "Just do this" is not an option.
A model I find useful, is Campbells Hero Journey, so before I start writing my user stories, I do a sketch about the problem, the characters, the stages and the story line, and once I have this clear, I would start writing my user stories.

I started testing software because the boss had fired all the testers he had in the shop.
I started as Product Owner because C-level director told my manager to change my career, starting tomorrow.
There is a pattern here, I'm not worried about this and the learning curve is exciting and challenging.

I think just as Software Testers come from anywhere, we can move to many roles as well, we can learn new ways to test, we can manage people, or we can try new disciplines, as I am doing with Product Owning.

As long as there is a journey, there is discovery, learning, challenges and a nice project to work on, it's going to be fun.

5. Celebrate
Wait, there is another one... When you manage to complete a project, a milestone, a tricky integration, make some time, grab the team and celebrate. We are all together in this.

Salva, Manel, Andoni, Edgar, Jaume, me, Manel, Paco and Albert