Eu sou o Paulo Caroli e este é o Podcast Mínimo Viável, onde compartilho conhecimento sobre as novas relações de trabalho e, assim, contribuo para a transformação de um mundo melhor.
Neste episódio do Podcast Mínimo Viável, você vai conferir a primeira parte de uma excelente conversa entre o criador da Lean Inception, Paulo Caroli, e do Product Backlog Building (PBB), Fábio Aguiar. Na oportunidade, os autores contam mais detalhes sobre algumas das características dos métodos, bem como o contexto que resultou na criação das duas iniciativas.
Paulo Caroli: E aí, Fábio. Tudo bom, pessoal? Prazer falar com todo mundo.
Fábio Aguiar: E aí, Caroli. Muito bom estar falando contigo de novo. Estamos juntos, né, que nem a Lean Inception e o PBB. Olá, pessoal!
Paulo Caroli: Bom, para quem acompanha a gente… Eu já te conhecia, né Fábio, na comunidade que a gente conhece muita gente do Brasil, que nem muita gente conhece a gente. E eu te vi, fui assistir tua palestra, como eu sempre faço quando eu vou em algum evento, eu palestro e assisto todas as palestras também, sempre para aprender.
E assisti a tua palestra. Eu acabei de assistir e falei: Fábio, vamos conversar? E a tua palestra estava no teu laptop, a minha no meu laptop. A gente abriu os dois laptops, um do lado do outro e a gente começou a conversar na hora do encaixe, aí você topou.
Você veio dar um treinamento em Porto Alegre, eu lembro disso. Você ia dormir em Porto Alegre e eu não deixei você dormir muito e falei: Fábio, vem aqui em casa, que eu preciso falar contigo e aí o PBB já nasceu como e-book e a gente falou: vamos tentar se falar uma vez por semana, uma vez por mês. Aí, a gente ficou indo, indo, indo e foi evoluindo devagarinho.
Fábio Aguiar: Eu me lembro bem desse dia, Caroli. E aí, foi justamente quando você viu o PBB, você falou assim: Fábio, o PBB é o passo seguinte da Lean Inception. Eu me lembro bem quando você mencionou isso para mim, eu tomei um susto. Mas como Caroli?
E você falou: não, eu vou até funcionalidades, mas aí e para quebrar a história de usuário? Então, o PBB é o passo seguinte da Lean Inception. E eu me lembro que aqui você já incentivou: Fábio, você precisa escrever um livro sobre isso, você vai ajudar muitas pessoas.
E eu até brinquei, não sei se você lembra que eu brinquei contigo: cara, como é que eu vou escrever um livro? Eu só tirava nota baixa, vermelha em português. O que eu vou falar para a minha mãe? Minha mãe não vai acreditar. E foi verdade isso, quando eu falei: mãe eu vou escrever um livro… já chegou o livro… e ela só disse: eu não acredito. E eu falei: foi com a ajuda do Caroli.
Paulo Caroli: Mas é a dupla também. Eu confesso que eu não era de redação, era de matemática, física e em redação eu tinha dificuldade. Mas, a vida é assim: naquilo que a gente tem dificuldade, a gente acaba treinando mais para superar e foi bem legal.
Fábio Aguiar: Sim, sim. E foi justamente a nossa ideia de estar aqui hoje, né Caroli? O PBB e a Lean Inception andam juntos praticamente, né? Então, os dois estão ali, um do lado do outro. O nosso objetivo é justamente estar junto também em alguns momentos, com a comunidade, com as pessoas que estão aí no dia a dia, no treinamento.
Esse papo aqui é um papo superaberto, né, Caroli? Para, justamente, a gente estar aqui juntos também como autores desses dois métodos, né?
Paulo Caroli: Eu vou fazer o seguinte… eu vou te contar um pouco da história que eu tenho com história do usuário, tá? E porque quando eu vi a tua palestra falei: nossa, resolveu o meu problema, meu e de muita gente.
Eu era desenvolvedor que usava métodos ágeis, logo, eu estava muito envolvido com as histórias do usuário. Mas, eu confesso que eu não gostava de escrever história de usuário. Eu gosto do formato, eu gosto do livro, gosto da teoria. Mas, quando eu tinha que me sentar e escrever, eu achava aquilo muito chato.
Em várias vezes, escrevia: como um desenvolvedor, eu quero isso para aquilo. Horrível, né? Não pode escrever para você, tem que ser para usuário final. Mas, eu sabia o que eu tinha que fazer e que não precisava escrever desse jeito. E confesso que é ruim.
Participava de muita Inception. E nas Inceptions antigas, então, era mais chato ainda que, às vezes, a gente escrevia muita história do usuário para aquele release planning muito longo, aí depois tinha que repassar todas para escrever elas bem. Então, para mim era: putz, mas aqui… a tá, história do usuário, mas tudo bem.
Eu trabalhei com o Jeff Patton e o método dele o User Story Mapping era muito bom também. E quando eu criei a Lean Inception, acabo divergindo um pouco do Jeff Patton, porque o User Story Mapping é a jornada do usuário e você quebra aquilo tudo em história, o que eu gosto muito, é muito legal você ver a jornada do usuário e decidir o que você vai fazer baseado na jornada.
Mas, quando eu começo a trabalhar com o Lean Startup, MVP, nem sempre o usuário sabe o que ele quer, nem sempre exatamente a jornada dele vai ser a jornada que você vai fazer com aquela sequência. E eu passei muitas organizações que, às vezes, a decisão do que fazer é baseada, por exemplo, em OKR, era baseada em alguma evolução da arquitetura, às vezes, era baseada na jornada do usuário.
Então, a Lean Inception ela não prescreve que tem que ser exatamente a jornada do usuário. Ela tem influência da jornada do usuário, mas deixa aberta para a gente decidir o que é mais importante. Aquele grupo decide, prioriza, não tem uma teoria definitiva que vai dizer essa é a ordem que se deve seguir. O grupo decide, prioriza e bota na ordem que está o sequenciador e eu paro ali.
Do sequenciador, a gente vai para o Canvas MVP e decide. Só que o que aconteceu? Eu primeiro divergi do Jeff Patton, que é difícil divergir de alguém que tem grande sucesso, e, depois, que acabava a Lean Inception na semana seguinte, o passo seguinte, você tem que quebrar aquilo em história do usuário.
Só que isso não cabia na Lean Inception, porque na Lean Inception eu não podia falar “o quê” e o “como”, tinha que parar no “o quê”, porque a gente está focando no MVP que vai validar aquilo. O “como” tinha que ficar para depois como uma outra coisa, não queria que isso fizesse parte da Lean Inception.
Outra percepção que eu tive: você tirou essa responsabilidade somente da pessoa PO, você fala: ah, não… está aqui uma fórmula, um passo a passo, que no final tem boas histórias e priorizadas. Então, eu achei aquilo magnífico, porque na Lean Inception eu também tirei o foco só de uma pessoa decidir tudo, a gente decide junto.
E o PBB, cara, quando essas duas coisas: uma forma efetiva de escrever história do usuário, que é colaborativa, não sendo dependente somente de uma pessoa, eu falei: putz, encaixou. Aí foi isso, esse apoio e, assim, esse casamento, como tu fala mesmo.
Fábio Aguiar: Então, Caroli, é justamente isso. Eu me lembro que quando criei o PBB, inicialmente, não foi nem com propósito de escrever história de usuário. Foi uma forma de estruturar, organizar o backlog. Eu me lembro que quando eu percebi que a estrutura do PBB, as histórias de usuário já estavam ali, acho que demorou uns três, quatro anos para eu perceber isso.
É claro, quando eu percebi que dava para fazer isso, pensei falta só um detalhe aqui. E aí, fechou aquela estrutura. E é até interessante, quando eu estou dando treinamento, sempre tem um Dev, uma pessoa desenvolvedora e a pessoa sempre fala assim: pô, eu vou automatizar isso aí, porque praticamente para ele já, no final, ele já tem as histórias de usuários, preservando todos os conceitos que têm por trás de histórias do usuário, INVEST, 3Cs, 3Ws, então, tudo o que ele está acostumado.
Claro que hoje a história de usuário se tornou a forma mais usada de representar um PBI. No próprio livro, a gente colocou isso. A gente dá até uma outra opção, que é o modelo ARO, para dizer que não tem só história de usuário. Você pode representar por modelo ARO ou várias formas que têm aí.
Mas, a gente tem que respeitar que o mercado acaba direcionando muita coisa e a história de usuário se tornou um padrão hoje de mercado e é bastante usada.
Paulo Caroli: Mas é um bom formato, né, Fábio?
Fábio Aguiar: É um bom formato.
Paulo Caroli: E ele é simples e completo. Aliás, tu falou PBI, que é Product Backlog Item.
Fábio Aguiar: Isso, a história de usuário na verdade, eu até acho que a gente colocou no livro também. Eu vi até uma pessoa que colocou no LinkedIn essa semana: “nenhum documento em métodos ágeis substitui a comunicação”. Então, a história de usuário ela tem o seu valor, eu creio que por causa disso: ela valoriza a comunicação, é uma representação, é um flash para a comunicação.
Então, é onde o PBB praticamente vai escrever as histórias de usuário para você. Agora, um ponto que você trouxe aqui do PBB: ele traz essa construção do backlog, essa organização do backlog. E quando eu falo organização, eu estou falando ali do triângulo, que é justamente construir, refinar e atualizar.
Você está organizando o backlog. Então, quando eu falo organização, eu estou falando desses três pontos, desses três trabalhos, a gente está no dia a dia, que é backlog emergente. Então, o PBB traz todo esse trabalho, desse triângulo, dessa organização do backlog e de uma forma colaborativa hoje.
Paulo Caroli: Sim, sim.
Fábio Aguiar: Então, todas as pessoas que vão ali atuar vão trabalhar.
Paulo Caroli: Aliás, deixa eu me retratar, porque quem me ouve aqui vai achar que o PBB só funciona depois da Lean Inception. O PBB é completamente autossuficiente. Até quando a gente escreve o livro, eu tive todo cuidado de não assumir que foi feita uma Lean Inception, não assumi que primeiro a gente alinhou sobre o MVP.
Assim, tem muita equipe que vai direto no PBB. Eu mesmo, dependendo da situação, vai direto no PBB. E além né, o PBB ele é tanto para o início quanto para o refinamento contínuo, que a gente precisa sempre. Especialmente nesse mundo de hoje, que a gente não para e define todo o backlog e acabou.
Não, hoje é continuamente. Então, cara, se você fez uma Lean Inception, faz o PBB logo depois e, depois, a cada duas semanas, você vai estar fazendo PBB e refinando continuamente. Diferente da Lean Inception, que são períodos mais largos ou quando começou, quando tem que pivotar ou alinhar, porque a gente ficou completamente perdido.
E, às vezes, a Lean Inception, quando você está completamente perdido, você faz um outro tipo de workshop para alinhamento mais rápido, para não precisar passar por todas as etapas. O PBB não, é muito simples, você faz o PBB completo continuamente. Eu gosto muito do PBB, porque é refinamento contínuo. Não somente uma vez como na Lean Inception.
Fábio Aguiar: Eu me lembrei, Caroli, que quando a gente estava escrevendo o livro, que a gente passou praticamente o quê? Desde 2018… 2017, foi quando a gente se encontrou, aí o treinamento foi em 2018. Então, foram quatro anos até o lançamento do livro, escrevendo o livro, né? O livro demorou tudo isso? Não.
O Caroli mesmo falou: Fábio, preciso aplicar mais o PBB, rodar também, ter experiência com isso para poder te ajudar a colocar isso em um livro. Eu me lembro quando a gente chegou, acho que foram os últimos oito meses até o lançamento, a gente se reunia todo dia à noite.
Paulo Caroli: O último ano foi mais pegado.
Fábio Aguiar: Aí, você falava assim para mim: Fábio, o livro do PBB vai sair mais do o de Lean Inception. Eu disse: o livro do PBB? Não, Caroli, você está falando de Lean Inception há mais tempo, ele está consolidado. E ele disse: não, Fábio, vai, porque a Lean Inception a gente sempre avalia o MVP, aquele trabalho inicial, né?
Já o PBB não, é para o dia a dia, é o que você acabou de falar aqui. É o trabalho do dia a dia. E é muito curioso isso, viu Caroli, porque nesse quase um ano e meio de lançamento do livro, eu praticamente atuo só dando consultoria aí com PBB e eu atuei nesse tempo muito mais trabalhando o backlog existente do que backlog do zero com o PBB.
Até criei um serviço chamado PBB Camp, que aí vai para o campo ali mesmo, trabalhar no dia a dia e como o PBB ajuda a ressuscitar muitos backlogs aí.
Paulo Caroli: Sim, sim.
Fábio Aguiar: Que é justamente o dia a dia, que você acabou de falar aqui.
Paulo Caroli: E o PBB como ferramenta ele é mais enxuto e mais completo. A Lean Inception acaba sendo alguns passos, é um conjunto de ferramental que no final são MVP. O PBB me parece tipo um alicate, você pega ali e foi. A Lean Inception é um pouquinho mais, uma sequência maior, mais ferramentas um pouquinho, uma caixinha de ferramentas maior.
Fábio Aguiar: Eu costumo dizer: pensa num fluxo de Dual Track, então, eu tenho aqui o Discovery e o Delivery. Eu preciso conectar o que está vindo no Delivery com o time que está no dia a dia.
Paulo Caroli: Continuamente, né?
Fábio Aguiar: Continuamente, então o PBB está sempre ligando isso daí. Então, por isso que é construir, refinar e atualização, a retroalimentação do backlog.
Paulo Caroli: Aliás, para todo mundo saber estar, eu teria colocado outro nome no livro. Eu teria usado a palavra refinamento contínuo, mas o Fábio ele já vem falando de PBB há muitos anos e já tinha o Canvas PBB, até o nome PBB a sigla. E ele falou: Caroli, a gente não pode mudar de Building para refinamento.
Eu gosto mais da palavra Refinement, Continuous Refinement. Você tem o Continuous Delivery, que é muito claro, que a gente dá continuamento na produção, tem o Continuous Discovery, que a Teresa Torres lançou muito bem, que acho que faz muito sentido. Eu acho que o nome do que a gente escreveu é Continuous Refinement. Eu respeito, porque já tinha um apelido, já tinha nascido, já tinha um nome, já estava em uso e fui da prática para a teoria, não o contrário.
Fábio Aguiar: O PBB foi criado no início da década de 2010. Trazer um nome hoje que é bem atual para a gente daquela década, não vendia. Então, o Building de construção chamava atenção e aí ficou. Claro, hoje, às vezes, até se você até falar de uma forma ahh, mas construindo, o PBB não é só para construir backlog.
É para construir, refinar e retroalimentar o backlog. É o triângulo que eu acabei de falar aqui. Se eu falar agora a palavra organização, que está todo tempo organizando o backlog. Mas é justamente isso. Foi um momento. E aí acabou pegando. A palavra PBB também fica muito boa de trabalhar e pouco se falou de um nome todo Product Backlog Building.
Paulo Caroli: Até contar uma história. Eu acho legal histórias, que a gente vai contando. Quando eu traduzo o PBB para inglês, eu falei: deixa eu falar com as pessoas que eu conheço para pedir um prefácio. E eu falei com Marty Cagan, só que ele não gosta da palavra backlog.
Há dez anos atrás, talvez, ele até fala fosse no prefácio, mas hoje ele é muito time de produto e falou que não pode ter um backlog porque é continuamente e o time alinhado. Aí, ele falou: Caroli, acho legal o conteúdo, mas eu não posso escrever um prefácio para o livro que tem no nome Product Backlog Building, porque eu vou contra Product Backlog.
Até conversei com ele, falei que entendo o que você fez, acho importante essa coisa do contínuo, mas está no nome. Eu não posso mais falar backlog do produto, o que faz sentido, porque antigamente a gente fazia um Product Backlog enorme, né?
Fábio Aguiar: Sim.
Paulo Caroli: E eu concordo com ele plenamente. É a Lean Inception, a gente vai entender a visão, o plano para o MVP e não tem o backlog do produto, tem em alto nível e o detalhado. Eu entendi completamente e estou em concordância com ele.
Fábio Aguiar: Sim.
Paulo Caroli: Aí, eu falei com o Jeff do Lean UX, que encaixa também. O Jeff tem a visão de UX, também continua, e ele falou: não, com certeza estamos juntos. Ele leu e escreveu para a gente o prefácio em inglês.
Fábio Aguiar: Agora Caroli, uma coisa bem curiosa sobre isso. É até natural assim, para quem está num nível mais estratégico: não existe backlog. Mas, se vocês forem ver, é algo que se tornou até universal no nosso meio. Eu falo: ah, o Scrum apresentou, mas se você for rodar um Kanban, iniciar um fluxo, precisa de um backlog.
Se for em uma porta de uma geladeira de uma casa, tem um backlog lá para organizar o trabalho daquela família, aquelas pessoas que estão ali naquela casa. Então, hoje esse termo se tornou tão universal, é muito comum no nosso meio.
Agora uma coisa pessoal, vamos lá. Eu fui Dev, Carol foi Dev, desenvolvedor, eu também, a gente trabalhou dentro do time e uma coisa que me chama muita atenção desde quando a gente lançou o livro: o PBB ele fica no top 1 lá das categorias de desenvolvimento.
É interessante isso, pois o PBB está ganhando de um livro lá de JavaScript, de Python. Aquilo me chama muita atenção. A gente vai ver o que é: o público não é só PO, PM, mas são pessoas desenvolvedoras também que estão no dia a dia. Então, olha que interessante, pessoal.
E aí, vale essa mensagem aqui, Caroli. Tudo bem, não é backlog, não é pessoa de produto. Mas, pessoal, o backlog é do time, o backlog é como a própria definição fala. É a única fonte de trabalho do time. Então, o backlog tem que respeitar ele como a fonte, a única fonte de trabalho que o time vai se auto-organizar para fazer.
Então, o backlog vai dar o direcionamento do trabalho do time, então a forma do time se auto-organizar. A gente precisa respeitar isso. E, por isso, esse público imenso hoje é de pessoas desenvolvedoras consumindo o livro de PBB.
Paulo Caroli: E eu até entendo essa reação da comunidade, porque, antigamente, a gente focava demais na entrega e muito pouco no resultado. Então, entendo esse empurrãozinho de falar esquece a entrega e vão focar no resultado. Esquece o backlog e vamos focar no resultado, que em inglês é o outcome.
Mas, ao mesmo tempo, o time, as pessoas desenvolvedoras elas precisam do output, da entrega, precisam trabalhar nos entregáveis, nas histórias do usuário. É claro que ter essas histórias entregáveis sem estar conectado cria uma expectativa de resultados, sem entender qual a hipótese que se está validando é péssimo.
Então, não pode. Se você trabalha só com entrega sem entender o resultado, concordo plenamente, joga o backlog na lixeira que não faz sentido se você nem sabe por que está falando aquilo. Mas, se você está alinhado, e aí eu tenho o viés da Lean Inception, porque se você saiu da Lean Inception, não tem como não estar alinhado com o resultado. Você está alinhado com o resultado. Você precisa sim do entregável para alcançar aquele resultado. Mas, eu entendo a reação da comunidade, especialmente, autores como Marty Cagan e por aí porque a gente passou vários anos só focando em entregas, que não é tão pensado o resultado.
Fábio Aguiar: Sim, faz sentido.
E aqui o episódio de hoje. Espero que você tenha gostado. Eu te peço para se inscrever e recomendar esse Podcast na sua plataforma de Podcast preferida, como Spotify e YouTube, e nas redes sociais. Ou, como eu prefiro: recomende aos seus amigos. Assim, você me ajuda com a missão de compartilhar conhecimento sobre as novas relações de trabalho, de forma a contribuir para a transformação de um mundo melhor.
Esse Podcast não tem patrocinadores. Então, se você vem curtindo esse Podcast e quer colaborar com a nossa equipe, vá em www.mepagaumcafe.com.br/caroli. Muito obrigado!
Notas do episódio:
- Inscreva-se na próxima turma do Treinamento Lean Inception
- Inscreva-se na próxima turma do Treinamento Product Backlog Building (PBB)
- Saiba mais no livro Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo
- Saiba mais no livro Product Backlog Building: Um Guia Prático para Criação e Refinamento de Backlog para Produtos de Sucesso
