Sunday 1 September 2019

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.
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

Friday 4 January 2019

Looking back to 2018

So, how was 2018...

Well, short story, it has been interesting.

Basically, because lots of things have changed.

Some change by nature... kids grow, I get older and the cycle of life won't stop for anyone.

Some left after a long plenty life, leaving a trail of knowledge in forms of books and experiences, Gerry Weinberg, thank you so much for all I still have left to learn from you.

Some left way too early, leaving a hole in our hearts, making us appreciate how short life is, and how important it is to share, to love, to live, while we are here, while we are together, Linnea, thank you so much for all the love we have witnessed, I never met you, but I will have a though for you as long as I am in this world.

Yeah... take a breath.

Some things also changed in my shop.

We got a new C level flymate, and as it happens, we changed workflows, mindsets, culture, habits, structures, people... now we estimate how long it takes to build a feature.
If you are worried about the Agile transformation process, don't worry any longer, I have learned that it is a two direction path, and you can either go up or down. It's not easy, but it can be done.
As any change, it has good and bad parts. The good part is that I have seen the team getting conscious   about our culture and values, and why they are important, and why we should take care of them, and boy, I am proud of this team.

In between reorgs, we have updated our user experience, our whole website, we have a new API, a new mobile app, improved performance and got several new payment processing tools, we collect documentation that users need to provide from certain countries, we have built integrations and automations with schools, banks and partners, we built a school in Guatemala.
And you know what... 2018 is good and gone, and we're still kicking and rocking.

The company has grown and changed, and just like a street car, some people decided that this was as far as they wanted to go in this line and went out, some people just got in and are looking after enjoying the ride and some were invited to leave.

I changed role, now I am a Product Analyst, and this is kicking a lot of opportunity for learning.
Some of the learning is a structured learning, that you go and look after, and some other learnings come by serendipity, and that is alright.
Now I write, record, edit, communicate, follow, help, coach as I didn't have time to do before.
Now I follow in twitter interesting product people as John Cutler, Antony Marcano, Alan Cooper and I'm getting into communities such as MTP and Productized.

Good times, yeah!

As for events and conferences...
We went to TestBash Brighton, and got the chance to learn about Modern Testing and many other things.
I gave a talk at the local VLC Testing conference about Cynefin and how testers can take advantage of this model.
We also went to TestBash San Francisco, and got the chance to put faces to many twitter friends from the bay area, as well as listening to many interesting talks.
We also hosted a few TestNight events where we met and talked about performance and tools and testing and things. But lately we haven't scheduled anything since summer. I think we are getting way too busy with work.
Well, fix is on the way, we are hiring! So if you feel like joining our Valencia team, please check this link or get in contact with me.

The family also did some road trips, We went to Murcia to see #43Grupo Corsairs doing their stuff.

We went to Oloron in Southern France, Baden-Baden in Southern Germany and Potes in Northern Spain, all of these went really well, giving us chances to unwind, spend quality time together and meditate about all things while you're driving.

And yeah, since daddy was going to San Francisco, we all took a flight and went around California.

Remember, Good times require some work and planning. Bad times come by themselves.

Looking forward for a great 2019.

Atomic Habits book review

  Atomic Habits is becoming a popular book about dealing with you own habits. The book is an easy read, where concepts are presented in a wa...