Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

Episódio 28: Livro Product Backlog Building completa um ano – Parte 2

27 jun 2022

> Ouça este episódio

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 segunda parte da festa em comemoração ao primeiro ano do Livro Product Backlog Building (PBB). Na oportunidade, o criador do método Fábio Aguiar recebe os profissionais Paulo Igor Godinho e Guilherme Mendes, que compartilham suas experiências com o PBB.

Fábio Aguiar: Bom pessoal, eu vou chamar mais uma pessoa aqui para bater um papo, um grande amigo, Paulo Igor.

Paulo Igor Godinho: Oi Fábio, tudo bem? Boa noite pessoal. Cara é um prazerzão, muito obrigado, fiquei muito feliz aí pelo convite, uma honra estar aqui nesse aniversário. Porque acompanhar desde o nascimento, participar do primeiro ano de aniversário e tudo é muito legal, o crescimento e a extensão que tudo isso pegou foi muito legal.

Fábio Aguiar: A gente até fez né, Paulo, alguns mesversários né.

Paulo Igor Godinho: É mesmo, até coisas presenciais. Exatamente.

Fábio Aguiar: Bom, o Paulo Igor aí né, a gente já é amigo de longas datas, ainda de Belém, da comunidade Tá Safo, que a gente acompanha e eu até trouxe o Paulo aqui, porque ele esteve um momento muito importante do PBB, inclusive, né Paulo, no momento que a gente foi validar o Canvas. Conta um pouco dessa história.

Paulo Igor Godinho: É, foi bom porque nesse… eu lembro bem, que a gente ia trabalhar, eu ia até de carona contigo na época e a gente já ia trocando ideia no carro né sobre as coisas que tu estava lendo, descobrindo e que tu ia experimentar. Aí a gente ia fazer até um projeto, eu acho que foi com a Marinha.

Fábio Aguiar: Com a Marinha, isso mesmo.

Paulo Igor Godinho: A gente foi fazer um projeto com a Marinha… eu lembro até hoje quando a gente chegou lá no comando, sei lá como é que chama lá o local, aí levamos os papéis para colar na parede e a primeira coisa que a gente ouviu foi: olha, não pode colar nada na parede, não pode fazer nada de colar, nada disso.

Aí lá vai a gente escrever as coisas tudo na mão, até que a gente convenceu eles de saírem do quartel, do comando lá e aí sim a gente conseguiu usar a parede para poder sinalizar para eles como era organizar e transformar o negócio em mais colaborativo.

Eu lembro até hoje, também, que foi um soldado lá, alguém, não sei as patentes como é que funciona, e outro que era mais, sei lá, o comandante e o soldado, vamos colocar assim, e o comandante: não, eu vou ficar aqui e só eu quero prestar atenção. Para mostrar quanto o PBB traz essa questão da colaboração.

E o soldado estava lá, pontuando e não sei o que, e o comandante lá só olhando. Isso durou acho que uns 10 minutos. Eu lembro que tem uma foto e eu preciso recuperar essa foto, 10 minutos depois a gente na sessão lá colocando, ordenando falando do fluxo e tudo, aí o comandante já estava em pé, depois a gente tirou foto com ele lá na parede tirando o post it e falando isso aqui não é aqui, isso aqui é aqui, vamos pontuar com isso, vamos alinhar um objetivo aqui.

Eu falei: Olha aí, quem não ia fazer nada né e só ia observar. Então, essa colaboração que o PBB traz é muito legal e uma coisa, que a gente experimenta muito aqui na Idopter Labs e em toda a vez que vai para esse processo, é aquela surpresa no final do trabalho, digamos assim, que é eles terem uma ideia do que eles querem fazer.

Mas, durante o processo todo de construir e ouvindo as colaborações, um falando um pouco para o outro, principalmente, na hora dos Step Maps, que a gente vai trocando ideias e tudo, sai aquele backlog, depois sai a priorização e muitos chegam a falar assim: cara, eu tinha uma ideia, mas não era exatamente como está aí, do jeito que está, está muito legal. A gente terminou uma hoje.

E foi bem bacana, porque esse cliente chegou meio que com o mockup montado… olha, isso aqui que eu quero fazer, como a gente costuma dizer aqui na Idopter Labs: a gente precisa se apaixonar pelo problema, não pela solução. Então, a gente vai descobrindo a solução que tem que aprender por ela né e o PBB é uma ferramenta fantástica para iniciar esse processo.

E aí esse cliente já trouxe, a gente falou: não, a gente vai fazer um processo aqui com vocês, vamos mapear desde a visão, entrar ali em persona, feature e tudo para vocês entenderem e para a gente entender melhor.

Eu costumo convencer eles falando assim: não é para vocês, porque vocês já sabem qual é a solução que querem construir. É para a gente que a gente quer aprender sobre a solução que vocês estão trazendo.

Aí eles: Não, beleza, então vamos fazer o processo. A gente faz o processo e, quando chega no final, nesse que a gente fez, no final, a gente faz a priorização e mostra que desse mockup, desse MVP que vocês tinham trazido como solução, dá pra gente experimentar muita coisa antes, muito menor e muito mais rápido.

Que é uma coisa que a Andrea estava comentando, de conseguir trazer uma visão melhor de validação ali do que eu preciso de um backlog mais enxuto e efetivo para a gente chegar lá e isso aqui eu consigo levar logo, validar, trazer um feedback, melhorar e rodar ciclicamente o PBB de novo, de novo, de novo e refinando ali continuamente trabalho e aí é fantástico.

Eu lembro dessa época da Marinha e também um outro projeto em que rolava o backlog, o Canvas, vamos trabalhar e sentava lá e chamava o Filipe, a gente vai fazer agora esses itens e conversava, fazia, acabou o trabalho, enrolava, levava debaixo do braço e ia embora de novo.

Fábio Aguiar: Eu sempre estava com o Canvas dentro da mochila. Mas, Paulo, acho que um ponto importante que tu trouxeste aqui é esse de colaboração do PBB. Eu admiro muito o fato que o Paulo ainda é um técnico e o creio que o Paulo vai se manter ainda mão na massa por muito tempo, pelo perfil, e ele consegue passear rapidamente no nível estratégico assim, de uma forma, que eu acho que ele é um dos profissionais mais completos que a gente tem hoje assim e eu admiro muito o Paulo por isso.

E um ponto que ele trouxe aqui que eu acho muito importante do PBB que é a colaboração. E um ponto, Paulo, que eu sempre falo: o PBB ele traz o time de volta para essa discussão. Tu como Deve aí, que nunca tira a mão da massa, apesar de ir muito pro estratégico, está conduzindo uma empresa, você sabe muito bem disso, trazer o time de novo para essa discussão.

Acho que, por algum momento, a gente vai assim afastando o time desse processo e aí, às vezes, a própria comunidade, o Paulo citou isso aqui né, muitos PM estão ali, querendo até anular a palavra backlog, talvez um framework como o Scrum apresentou.

A gente fica com esse termo, com esse nome, com o artefato por um bom tempo até vir um outro nome aí, mas acho que a forma de trabalho vai continuar. Mas, acho que o ponto é esse: o PBB traz o time de volta e aí como costumo dizer: o Guia do Scrum fala que o dono do backlog é o PO. O PM tem uma visão mais estratégica que é isso mesmo.

Mas, para mim, sempre quem vai ser o dono do backlog é o time, porque é o backlog vai dar o direcionamento ao trabalho do time, é o time que vai consumir o backlog. Então, esse ponto da colaboração do time é trazer de volta, né Paulo, e acho que é isso tá e essa é minha surpresa: uma coisa que eu noto muito, por exemplo, o livro ele está numa categoria, ele chega a primeiro, aí eu fico vendo os livros que ficam em segundo, terceiro, quarto é só livro de programação.

Mas por que tá aqui, né? Mas é esse o ponto, o Deve, quem está no time, do dia a dia ali, gosta do PBB, porque trouxe de volta para essa discussão.

Paulo Igor Godinho: E ficava muito preso esse trabalho para o PO, para o PM, quando abriu, esse exemplo que tu carregava debaixo do braço o backlog é um exemplo claro, porque o próprio desenvolvedor ele olha aquele backlog e ele consegue ver a representação que aqueles itens nada mais são que o caminho para alcançar um objetivo e é uma das coisas que eu acho fantásticas é a gente sempre alinhar os times pelo objetivo.

É muito legal começar o PBB falando de problema e expectativa, porque a gente está tentando alcançar um objetivo. O PBI e os itens que estão lá no backlog, durante o desenvolvimento, como são ciclos de aprendizado, podem mudar ainda. Aqui, a gente tem uma ideia inicial, mas as coisas podem mudar, podem descobrir coisas durante as iterações, por isso que a gente faz várias iterações para a gente ir aprendendo.

Então, vai acontecer isso. Mas uma coisa que o PBB já faz alinhamento e que ajuda muito o time também fazer essa reflexão durante os movimentos é a gente estar focado no objetivo, o que isso está me ajudando em termos de expectativa, em alcançar em termos de expectativa? Não fica orientando o time por história, não orienta o time por tarefa, orienta o time por um objetivo a ser alcançado, uma visão a ser alcançada.

Esse alinhamento que o PBB faz e vai refinando e vai fazendo várias e várias vezes ajuda a gente sempre a ter uma visão bem clara e aí todo mundo seguir esse caminho de: ah, por que a gente está fazendo isso? Porque a gente quer alcançar esse objetivo, é isso que a gente quer validar, essa expectativa que a gente quer entregar e não essa história que eu quero entregar, a história é só um passo para a gente poder alcançar aquilo.

A gente fica numa orientação num nível muito mais alto, digamos assim, para todo mundo, para o time inteiro e isso é muito bom.

Fábio Aguiar: Paulo, o papo está muito bom, mas a gente tem que ir para o final aqui, mas, assim, Paulo, hoje o PBB faz parte até da Idopter Labs.

Paulo Igor Godinho: É, na Idopter Labs, no processo inicial a gente sempre, principalmente, produtos, que chegam como a ideia ainda, o problema, a gente começa sempre pelo processo ali de Lean Inception, PBB, alguns que são projetos que já existem alguma coisa a gente já faz a reflexão também no PBB para poder mapear tudo, deixar bem alinhado, conhecer quem são as personas, quais são os objetivos, que problema eu quero resolver.

É aquela história né muitos chegam com a gente falando assim: eu quero isso aqui, constrói isso para mim, mas eu não quero só construir uma solução, eu quero resolver um problema e, para isso, a gente precisa entender mais o problema e aí o PBB é uma ferramenta excepcional para a gente aprender e é o que a gente utiliza aqui na Idopter Labs no fluxo para desenvolver e entregar os softwares que a gente entrega para o mercado.

Fábio Aguiar: E aí, Paulo, eu sempre te peço, não sei se você já encontrou… ele bateu a foto lá dos marinheiros, teve uma hora que a gente saiu do Canvas, eles tomaram conta, o Paulo bateu uma foto e a gente falou: esse Canvas vai ser um sucesso. Você já tem a foto, Paulo?

Paulo Igor Godinho: Cara, eu tenho em algum lugar, em algum backup, eu vou procurar aqui, eu vou achar essa foto no comando. Eu vou achar as duas, que é o comandante atrás da mesa, que ele não ia colaborar, e depois ele lá na parede, lá apontando. Tem essas duas fotos lá.

Fábio Aguiar: Muito bom, Paulo, valeu, cara, valeu por estar compartilhando.

Paulo Igor Godinho: Valeu, gente, uma boa noite e obrigado pelo convite. Parabéns pelo sucesso, parabéns pelo PBB e vida longa ao PBB.

Fábio Aguiar: Obrigado, um grande abraço aí, Paulo.

Bom, eu vou chamar agora aqui o Guilherme aí que nos presenteou aí. Oi Guilherme, fala mais aí quem é você e a sua experiência com o PBB. Compartilha com a gente.

Guilherme Mendes: Legal, muito boa noite aí pessoal, estamos juntos e não tem como estar diante dessa turma né, dessa dupla e não estar agradecido né, o Fábio, o Paulo e toda a equipe dele aí, sempre contribuindo muito para a comunidade.

Apesar de ser recente o meu contato com o PBB, o pessoal lembrou da época né, de 2010, e é uma época que me remete também a uma vivência assim de um ambiente que o livro transparece ser dentro de uma empresa um pouco menor, mais familiar, que tinha aquela figura do desenvolvedor, que colaborativamente se envolveu com o backlog, com usuário e isso foi o que chamou bastante a minha atenção.

Porque essas pequenas empresas hoje, muitas delas, elas se tornaram grandes empresas e com certeza o PBB está aí para tirar toda aquela organização que aquela pessoa tinha, que é o nosso ilustre aí, que se transformou nessa ferramenta incrível e tem sido muito útil aí para nós. Então, só agradecimento aí para vocês.

Fábio Aguiar: Foi, justamente, aí Guilherme que o PBB nasceu ali, no início de 2010, apesar de já ter ali 10 anos do Manifesto Ágil e tudo, mas o mato ainda era muito alto né. Então, eu costumo dizer que é a primeira fase do Manifesto Ágil, estamos descobrindo maneiras melhores de desenvolver software e, de fato, a gente teve uma década ali o início de 2010, a segunda onda ali da agilidade, a gente começou a cortar esse mato.

Não só o PBB, mas tem muita coisa aqui no Brasil, tem o PBB, tem a própria Lean Inception aqui do Paulo Caroli, tem o Fluxo Unificado, tem o Learning 3.0, tem o Agile Coaching DNA, então, tem muita coisa que está nascendo aqui.

Eu acho que o nosso próprio cenário né, o Brasil é muito complexo, então, isso ajuda a imergir muita coisa boa aqui do Brasil. A gente acaba exportando também. Deve estar com um mês que a gente lançou o livro do PBB em inglês e ficou uma semana como o livro lá mais vendido dos livros lançados na Amazon Americana.

Então, mas você vê como é, tem muita gente, a gente consegue exportar e muita gente valorizando o que sai daqui.

Guilherme Mendes: Sensacional, o que eu acho incrível né e o que a comunidade já vinha trazendo, que tinha uma geração muito grande de  valor é gestão visual e o fluxo linear de todos os passos do PBB, que na minha experiência é o que tem ajudado muito, até o Canvas e todo material ali muito bem elaborado, disponível no site e tal.

Toda essa gestão visual e a dependência de uma etapa com a outra e como que você consegue relacionar a compreensão, tanto do que o time mesmo consegue enxergar o estado atual dele e aonde, até no final, na elaboração de uma história aquilo foi impactado.

O pessoal estava falando de Continuous, de iteração e eu estou numa etapa em que está acontecendo justamente isso. Eu não uso Scrum hoje no contexto em que eu estou trabalhando, mas eu uso o Kanban e eu sou uma prova de que o PBB é completamente adaptável para qualquer outro método ou framework.

E pensando em upstream, eu consigo hoje fazer um desenho de um fluxo em que cada etapa em determinado acordo, independente da ferramenta que eu esteja usando para controlar o fluxo, eu consigo determinar em conjunto com a equipe os acordos que a gente vai ter para cada uma das etapas.

Então, sei lá, a gente vai fazer um Discovery, um Research, beleza, a gente vai descobrir quais são as personas, a gente vai atualizar nossas personas. A medida em que as nossas funcionalidades, os incrementos foram acontecendo, as nossas personas foram mudando e a gente sempre vai lá e faz esse refresh lá no Canvas.

Então, acho que o poder né do PBB, dessa geração, atualização, o poder dele se tornar adaptável a qualquer a qualquer método ou framework é sensacional e gera muito valor até para pessoas que, de repente, não tiveram muito contato com a ideação, com talvez até com o Lean, com o MVP e ele facilita.

Não é à toa que o Paulo, em 2017, ele chegou e falou: meu, vamos conectar, porque a gente vai acertar, é carta na mão que vai dar tudo certo. Eu estou vivendo isso. Eu posso confirmar que isso é uma verdade.

Fábio Aguiar: E Guilherme, você trouxe agora também uma visão muito boa: o PBB não é só para Scrum, ele se encaixa muito bem com Kanban e qualquer outro processo. Eu acho que, apesar, o livro fala de Scrum, a gente nem abordou nada sobre fluxos, sobre Kanban, até para dar um crédito, um respeito ao próprio Scrum que apresentou esse termo, esse artefato chamado backlog que hoje se tornou universal.

Como você mesmo falou: posso usar com Scrum, posso usar com Kanban que é o mesmo fluxo do backlog. Então, eu posso usar com qualquer outra forma de trabalho e eu costumo dizer: se você for numa casa hoje, é capaz de você ver um backlog na porta da geladeira.

Guilherme Mendes: Exato e é engraçado como você conhece o PBB e você sempre usa ele né, até no dia a dia, pera aí, quem que vai usar isso aqui. Recentemente, a gente viu um episódio né de um treinador famoso, com uma marca de isotônico famosa, e aí, na hora, veio na minha cabeça o PBB e eu falei: caramba, como que as pessoas não pensaram ainda que existe um grupo ali de pessoas que utilizam aquele produto também. A gente fala muito de desenvolvimento de software né, mas essa realidade eu acho que ela transpõe, ela vai para desenvolvimento de produtos, de matérias, outras coisas e eu acho que é incrível.

Fábio Aguiar: Esse ponto é importante também, o Caroli até colocou aqui: um Produto Brasileiro de Belém – PBB e a Micaela está falando justamente isso, viu Guilherme, ela começou a usar o PBB para projetos que não são de software, então, os projetos dela são na área de saúde e super funciona.

E é justamente isso: acho que o PBB se encaixa muito bem para qualquer contexto tá, que é você precisa de uma única fonte de trabalho que é backlog. Então, a ideia é justamente essa você pode apenas, é como eu falo, você apenas renomeia, adapta a nomenclatura ali e já aplica para qualquer contexto.

Até uma vez a minha filha queria usar na escola e eu criei o PBB Kids, aí aonde tinha persona, a gente colocou lá pessoas, aonde tinha funcionalidade, nós colocamos atividades e aonde tinha os PBIs colocamos PBIs tarefas, só que dizia que iam tratar com tarefas.

Só fica claro ali um formato que você vai organizar seu backlog, mas a dinâmica do PBB, a aplicação do método é a mesma. E aí eu queria deixar aqui, pessoal, quem tiver como a Micaela, que tiver tendo experiências com o PBB fora do contexto de produtos, de software, compartilhe com a gente.

A gente quer começar a catalogar essas experiências até para compartilhar com outras pessoas. Então não sei, né Caroli, pode até ser um e-book aí lá na frente com essas experiências, PBB for all. Então, assim tá, de qualquer contexto e a gente pode, justamente, começar a compartilhar. Então, manda um e-mail para a própria Caroli no [email protected], que a gente vai começar a compartilhar.

Guilherme, nosso tempo está apertando aqui cara, mas muito obrigado por ter vindo. Obrigado pelo carinho com o PBB.

Guilherme Mendes: Imagina, eu que agradeço a oportunidade e estamos juntos. Vou acompanhar vocês sempre. É sempre muito conteúdo, muito embasado, muito bom. Quero ter oportunidade de conhecer vocês pessoalmente e tá aí relatando cada vez mais aí o sucesso dos produtos, das ferramentas de vocês.

Fábio Aguiar: Muito bom, muito bom. Não deixa de compartilhar nas redes aí com a gente a tua experiência com o PBB. Valeu viu. Muito obrigado.

Guilherme Mendes: Muito obrigado, valeu!

 

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

Confira a íntegra da Festa de 1 ano do PBB
Agenda Treinamento Construção do Backlog do Produto
Adquira o Livro Construção do Backlog do Produto
Treinamento Lean Delivery com Métricas Ágeis, por Andrea Pinto e Paulo Caroli
Você tem cases de PBB para compartilhar? Escreva agora o seu relato para [email protected]

Caroli.org

Caroli.org is a hub for agile methodologies, innovation, and digital transformation, founded by Paulo Caroli, author of Lean Inception and Team OKR. We help organizations move from project to product and from strategy to execution, offering training, and consulting in Lean Inception, OKRs, Data Mesh, and agile transformations—empowering teams to align, validate, and deliver real business value.
#116: Quando os OKRs Atrasam: Ajustar o Prazo, Mudar o Plano ou Recomeçar?

#116: Quando os OKRs Atrasam: Ajustar o Prazo, Mudar o Plano ou Recomeçar?

Nem todo OKR é alcançado no prazo previsto. Mas quando isso acontece, qual é a melhor decisão? Estender o prazo, revisar as iniciativas ou abandonar o objetivo e começar de novo?
Neste episódio, Paulo Caroli discute os motivos mais comuns para um OKR atrasar, como diferenciar um problema de execução de uma mudança de contexto e quais critérios ajudam a decidir o próximo passo. Um bate-papo sobre aprendizado, adaptação e como usar os OKRs da forma certa para gerar resultados — sem transformar o framework em uma burocracia.

ler mais
#115: Do OKR Estratégico às Iniciativas: Centralizar ou Desdobrar?

#115: Do OKR Estratégico às Iniciativas: Centralizar ou Desdobrar?

Quando uma organização define seus OKRs estratégicos, qual é o melhor caminho para transformá-los em iniciativas concretas? Neste episódio, exploramos duas abordagens bastante utilizadas:
1️⃣ A liderança define os OKRs estratégicos, escolhe as iniciativas e depois distribui a execução entre os times.
2️⃣ A liderança define os OKRs estratégicos, compartilha a direção com os times, que então criam seus próprios Team OKRs e definem as iniciativas mais adequadas para contribuir com os resultados.
Quais são as vantagens, riscos e contextos ideais para cada modelo? Como equilibrar alinhamento estratégico, autonomia dos times e velocidade de execução? Uma conversa prática para líderes, gestores de produto, agilistas e profissionais que buscam conectar estratégia e entrega de forma mais eficaz.

ler mais
#114: Team OKR + Team Topologies: Estruturas ou Jetskis?

#114: Team OKR + Team Topologies: Estruturas ou Jetskis?

Team OKR + Team Topologies: Estruturas ou Jetskis?

Como aplicar Team OKR e Team Topologies em grandes empresas que ainda operam com estruturas organizacionais baseadas em áreas e funções?
Neste episódio, discutimos o desafio de alinhar estratégia e execução em organizações complexas, explorando o contraste entre equipes estáveis e os “Times de Jetski” — modelo utilizado pelo iFood para acelerar iniciativas estratégicas. Também abordamos a Curva de Tuckman e os impactos da formação e evolução dos times na geração de valor.

ler mais

Pin It on Pinterest