Fala galera, tudo bem?

Algum tempo atrás eu escrevi sobre o desafio de ser 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.

Resumo da entrega do MVP: Praticamente 92 dias de trabalho ininterruptos, regado à muita pizza, hambúrguer, refrigerante e stress, mas foi entregue e deu tudo certo.

• 

O que aconteceu depois é fácil prever: Calmaria, todos felizes para sempre, rodando sprints numa nice. Claro que não né? LoL

Foi uma loucura total mas em nível + hard:
● Produto novo no ar;
● Nova tecnologia;
● Novas integrações
● Novos parceiros;
● Métricas de produto;
● Melhorias;
● Novos parceiros querendo integrar.

E foi assim por mais uns 2 a 3 meses mas estávamos mortos de cansaço e na correria de crescer e melhorar o produto tínhamos criado muitos “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.

Eu estava na trincheira com o time, então estava tão cansado quanto eles. Não precisava ser um Expert de métricas para ver que a qualidade baixou, os bugs cresceram e o time estava no limite.

Como eu era o Product Owner do Market Place, negociei com os Stakeholders e parceiros 2 sprints de “break” para arrumar a casa, colocar o código, corpo e mente em dia. Caso contrário não seria possível sustentar o produto pois as pessoas estavam cansadas e naturalmente isso refletia na qualidade do que estávamos fazendo.

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

Com isso, fiz acordos explícitos tanto com os stakeholders quanto como o time para que as 2 sprints (2 semanas cada) seriam dedicadas para:

● Tirar alguns dias de folga e descansar;
● Trabalhar em qualquer coisa que quisessem, desde que estivesse relacionada ao produto;

Alinhei com o time alguns dias para eu tirar as minhas folgas (liderança por exemplo) mas também combinei quais dias eles ficariam fora, criando assim uma escala de descanso.

E esse foi o backlog da 1ª sprint de Exploration days por prioridade:

1. Corrigir bugs críticos;
2. Se auto organizem e trabalhem no que quiserem, mas cadastrem no Jira para termos visibilidade do que foi feito e colocar em produção;

● Bugs críticos foram resolvidos e já estavam em produção (tínhamos Continuous Integration e Continuous Deploy);
● Problemas de performance do Banco de Dados e aplicação foram mapeados e já estavam sendo corrigidos;
● Melhorias de UX/UI tinham sido mapeadas e algumas já estavam em andamento;
● Retomada da criação e atualização dos testes automatizados;
● Escala de folga criada e em execução;

Eu achei que teríamos melhorias mas não acreditava que em tão pouco tempo teríamos tanta coisa legal sendo feita, com o time descansando e mais engajado. O resultado foi tão bom, que ao final da 1ª sprint já tínhamos resolvido grande parte dos débitos técnicos e problemas.

• 

Com isso, na 2ª sprint já começamos a puxar novos itens do backlog relacionados às melhorias e pedidos de stakeholders e fomos voltando aos poucos no nosso dia a dia de entregas (mas sem o ritmo frenético que estávamos).

Um aprendizado importante que integrei profissionalmente foi de criar um ambiente para o time fazer experimentos, validar/invalidar hipóteses e de não dizer COMO as coisas devem ser feitas mas sim, apresentar o PROBLEMA que queremos resolver e o time buscar a melhor solução.

Eu tive oportunidade de fazer experimentos de Exploration Days em outros times que trabalhei tanto na Serasa como em outras empresas e os resultados sempre foram muito bons e parecidos: Quando o time pode escolher onde trabalhar, eles ficam mais engajados e normalmente o trabalho tem um ROI enorme para a empresa porque o time acaba trabalhando em bugs, melhorias, automações e qualidade de código (quando estamos falando time de desenvolvimento). Eu já fui desenvolvedor e sinceramente, adorava ver alguns códigos que tinha feito e pensar: nossa, tá bom demais isso. LoL.

Para terminar, recomendo assistir à Ted Talk da Sheena Iyengar: A arte de escolher. Acho que vocês vão gostar.

É isso pessoal, nos vemos em breve no próximo artigo.

Se quiser falar mais me procure que ficarei feliz em conversar contigo.

Abraços e até a próxima.
Ricardo Caldas