Hey everyone, how are you?

Some time ago I wrote about the challenge of being a Product Owner of a MarketPlace in Brazil and delivering the MVP in 90 ops, 92 days (we are delayed 2 days …) but today I will talk about what happened after that and how Exploration Days (created by Jurgen Appelo and learned in Management 3.0 Training) helped in the pro-production. Product Owner de um Market Place no Brasil e de entregar o MVP em 90 ops, 92 dias (atrasamos 2 dias…) mas hoje vou falar o que aconteceu depois disso e como o Exploration Days (criado por Jurgen Appelo) ajudou no prós-produção.

Summary of MVP delivery: Practically 92 days of uninterrupted work, washed down with lots of pizza, hamburgers, soda and stress, but it was delivered and everything went well.

• 

What happened next is easy to predict: Calm down, everyone happy forever, running a nice sprint. Of course not, right? LoL

Foi uma loucura total mas em nível + hard:
New product in the air; New technology; New integrations New partners; Product metrics; Improvements; New partners wanting to integrate.
● Nova tecnologia;
● Novas integrações
● Novos parceiros;
● Métricas de produto;
● Melhorias;
● Novos parceiros querendo integrar.

And it was like that for another 2 to 3 months but we were dead tired and in the rush to grow and improve the product we had created many “go-horses”, creating a lot of technical debts. Until we had to take a “forced” break to clean up the house, but how to do that with the backlog growing? Leadership for example, transparency, explicit agreements and Exploration Days.go-horses”, criando muito débitos técnicos. Até que tivemos que fazer uma pausa “forçada” para arrumar a casa mas como fazer isso com o backlog crescendo? Liderança por exemplo, transparência, acordos explícitos e Exploration Days.

I was in the trench with the team, so I was just as tired as they were. You didn’t need to be a Metrics Expert to see that the quality dropped, the bugs grew and the team was on edge.

As I was the Product Owner of MarketPlace, I negotiated with Stakeholders and partners 2 sprints of “break” to fix the house, put the code, body and mind up to date. Otherwise it would not be possible to support the product because people were tired and naturally this reflected in the quality of what we were doing.

I gave transparency to the stakeholders, presenting them with our metrics and the total hours the team was working because it was important for them to be aware. transparência total para os stakeholders, apresentando para eles nossas métricas e o total de horas que o time estava trabalhando pois era importante eles terem ciência.

With that, I made explicit agreements with both stakeholders and the team so that the 2 sprints (2 weeks each) would be dedicated to: acordos explícitos tanto com os stakeholders quanto como o time para que as 2 sprints (2 semanas cada) seriam dedicadas para:

Take a few days off and rest;
Work on anything they wanted, as long as it was related to the product;

I lined up with the team for a few days to take my time off (leadership for example) but I also agreed which days they would be out, thus creating a rest schedule.liderança por exemplo) mas também combinei quais dias eles ficariam fora, criando assim uma escala de descanso.

And that was the backlog of the 1st Exploration days sprint by priority: Exploration days por prioridade:

1. Fix critical bugs
2. Organize and work on whatever you want, but register with Jira to have visibility of what was done and put it into production;

Critical bugs were resolved and were already in production (we had Continuous Integration and Continuous Deploy);
UX / UI improvements had been mapped and some were already underway;
● Melhorias de UX/UI tinham sido mapeadas e algumas já estavam em andamento;
Resumption of the creation and updating of automated tests;
Slack scale created and running;

I thought we would have improvements but I didn’t believe that in such a short time we would have so much cool stuff being done, with the team resting and more engaged. The result was so good, that at the end of the 1st sprint we had already solved most of the technical debits and problems.

• 

With that, in the 2nd sprint we already started pulling new items from the backlog related to improvements and requests from stakeholders and we started to return little by little in our day to day deliveries (but without the frantic pace we were in).

An important learning that I integrated professionally was to create an environment for the team to do experiments, to validate / invalidate hypotheses and not to say HOW things should be done, but rather to present the PROBLEM that we want to solve and the team to seek the best solution. COMO as coisas devem ser feitas mas sim, apresentar o PROBLEMA que queremos resolver e o time buscar a melhor solução.

I had the opportunity to do Exploration Days experiments in other teams that I worked for both Serasa and other companies and the results have always been very good and similar: When the team can choose where to work, they are more engaged and the work usually has an ROI huge for the company because the team ends up working on bugs, improvements, automations and code quality (when we are talking about development team). I used to be a developer and honestly, I loved to see some code I had made and think: wow, this is too good. LoL.

Finally, I recommend watching Ted Talk by Sheena Iyengar: The art of choosing. I think you’ll like it. Sheena Iyengar: A arte de escolher. Acho que vocês vão gostar.

That’s it folks, see you soon in the next article.

If you want to talk more, look for me and I will be happy to talk to you.

See you soon ;-)
Ricardo Caldas