Ask Kanban para sua daily não ser um status report

Você provavelmente já deve ter ouvido milhares de vezes as pessoas questionarem a utilidade das daily meetings. Bom, esse post não é sobre isso, mas sobre uma alternativa que pode ajudar seu time a extrair o máximo possível e de uma forma fluida e confortável.

Quando falamos de daily meeting não é incomum as pessoas torcerem o nariz e falar que não gostam, mas que sempre acabam fazendo porque alguém mandou. Nos times que eu já tive voz para demonstrar minha opinião, ou nos times que eu liderei eu tentei interpretar o motivo disso acontecer.

Minhas hipóteses são meio óbvias, mas as vezes nós precisamos falar o óbvio em voz alta pra ganhar a boa vontade das pessoas. E o óbvio, nesse caso, eu resumo em dois componentes: primeiro que pessoas tem problemas com coisas sem propósito — especialmente reuniões. E acredito que isso se agrave quando estamos falando de um público muito técnico, que, nesse cenário, são representados pelas pessoas desenvolvedoras de um time; o segundo é que ninguém gosta de ser cobrado — especialmente em público.

Com base nessas duas premissas iniciais, eu passei a observar e a tentar empregar um modelo que eu comecei a usar quando trabalhei no Nubank em um dos times de produtos de Cartão de Crédito. O Ask Kanban.

Aqui vai um pequeno disclaimer. Eu não tenho estatísticas pra apresentar e comprovar com números, mas em todos os times que esse processo foi adotado, havia processos periódicos de avaliação de saúde do time. Pode ser que você conheça pelo nome de Healthcheck. E esse modelo de daily, na maioria dos casos ganhou destaques positivos relacionados a melhoria dessa cerimônia em especial. E eu digo que isso se deu na "maioria dos casos" porque, se tem uma coisa que eu aprendi nesses 15 anos de mercado, é que times são organismos vivos. O que poderia ser diferente, afinal é composto por pessoas com culturas e histórias de vidas diferentes.
Dessa forma, cada time desenvolveu sua própria cultura e essa foi alterada a cada pessoa que entrava e saía.

Bom… se um time é um organismo vivo, eu acho um tanto quando inocente acreditar que um modelo desenvolvido por um grupo de pessoas funcione para todas as outras infinitas combinações de outras pessoas, não é mesmo? Afinal, quando eu digo que um time é um organismo vivo, quero dizer que um grupo mutável de pessoas tem suas peculiaridades, medos, conclusões, culturas etc. E esse grupo de informações é constantemente alterado com a percepção individual de cada membro desse time sobre novos fatos que ocorrem.

O modelo tradicional

Eu não acredito que o modelo tradicional de daily com as características perguntas (O que você fez ontem? O que você fará hoje? Existe impedimento?) seja ruim, mas acredito que o tempo não fez bem a elas. E veja: a culpa nem é delas, mas dos climas das empresas. Mas isso é papo pra outro texto. No fim o que temos com essas perguntas é exatamente o problema que falamos no início desse texto: primeiro que as pessoas se veem cobradas e em público, pois a premissa dessa reunião é estar sempre com o time todo reunido. E o problema aqui talvez nem seja a cobrança (antes que venha algum mal amado dizer que as pessoas hoje não aguentam ser cobradas), mas sim a autocobrança de não ter conseguido fazer evoluir em alguma tarefa e isso ficar evidente para o time inteiro; Por outro lado as pessoas entram já sabendo que esse será o tom da reunião e começam a questionar a relevância da reunião. Esse é o momento que esbarramos no outro fator que fazem as pessoas desistirem dessa cerimônia.

O Ask Kanban

Pensando nessa questão, quando trabalhávamos juntos no Nubank, minha querida Leticia Alves sugeriu que tentássemos adotar um novo modelo que premiasse o andamento do trabalho e não a relação pessoal entre pessoa e task. Veja… aqui um ponto importante a se destacar: esse já é o propósito das perguntas originais, mas foi mais uma coisa que se perdeu no tempo. Enfim. Eis que ela nos apresentou o Ask Kanban.

O Ask Kanban foi um modelo pensado pelo pessoal da huge.io. E no post original que eles apresentam o modelo deixam claro:

A maioria dos stand-ups são obsoletos. Em resposta, criamos Ask Kanban!, um jogo para curar stand-ups obsoletos. — Brendan Wovchko

Como ele diz é realmente um jogo e o objetivo é: ganhar.

Para esse modelo existe uma rotação onde primeiro se escolhe um observador silencioso. O time, então, começa a fazer perguntas observando o board; e, por fim, o observador ganha se ele encontrar alguma coisa que o resto do time não encontrou. A proposta é inteligentíssima, pois premia a atenção plena dos participantes e ainda fortalece o team building da equipe.

O jogo sugere 10 perguntas. São elas:

1. O que podemos finalizar hoje? Consolida a cultura de que terminar é melhor do que começar
2. Alguém está trabalhando em algo que não está no board? Solicitações pontuais que estão ignorando o processo. Descubra agora e os torne visíveis antes que afete o fluxo
3. Temos tarefas que podem ser puxadas? Reduz os tempos ociosos é a maneira mais fácil de reduzir o desperdício e melhorar o fluxo
4. Tem algo que precisamos agir em conjunto? Melhora fluxos de WIP excessivo. Tenta identificar filas com gargalos. Tarefas com owner ausente. Tarefas bloqueadas. Tarefas de alto risco.
5. Existe uma tarefa urgente? Certifica que o time está agindo corretamente com tarefas que foram identificados como emergenciais
6. Uma tarefa bloqueia a outra? Se uma tarefa do topo do backlog está impedindo outra, não a puxe até que ela esteja desbloqueada
7. Existem tarefas para reposição? Um backlog sem uma tarefa “puxável” é um sinal de falta de balanço entre demanda e capacidade de produção
8. Estamos alinhados sobre o que vem a seguir? As reuniões da equipe devem terminar com a prioridade clara. Não confunda conversa com comprometimento.
9. Todas as tarefas em andamento possuem um dono? Para que um sistema de pull funcione corretamente, todas as tarefas em andamento precisam ter um dono
10. Alguém está atribuído como owner de várias tarefas? A troca de contexto faz com que as tarefas fiquem ociosas, o que afeta negativamente o fluxo

O modelo não gameficado

Não gameficado talvez nem seja o melhor termo para o que vou apresentar agora nesse tópico. Mas como o que vou apresentar aqui parte da premissa que vamos tirar o caráter jogo/existe um ganhador da roda, funcionou bem na minha cabeça.

E é por essa questão que vamos começar. Uma coisa que acabamos adotando no primeiro time que rodamos esse modelo é que não rodaríamos como um jogo. Não houve uma grande discussão sobre isso, pelo que eu me lembro. Apenas decidimos tentar. Lembra que falei sobre organismo vivo? Por que acharíamos que seria diferente só porque estamos usando um modelo diferente, não é mesmo?

Também reduzimos o número de perguntas, pois entendíamos que aglutinar algumas delas faria o modelo ficar mais dinâmico. Mas o que não abrimos mão foi do modelo foi o fato de focar no andamento do trabalho e não nas pessoas em si. Chegamos a 5 perguntas. Metade do proposto original.

1. Alguma task precisa ser adicionada ao board?
2. Algum item de alta prioridade ou que furou a fila? Evidenciar tarefas urgentes que impactaram o fluxo de desenvolvimento previsto no início da sprint
3. Algum block que precisamos discutir? Discutir blocks que estão impactando o fluxo de trabalho
4. Algum comentário sobre uma task que esteja em andamento? Espaço aberto para as pessoas comentarem, se quiserem, sobre as tasks que estão em desenvolvimento.
5. Nosso board está saudável? Muitas tasks em in-progress ao mesmo tempo. Poucas tasks no backlog no início da sprint. Tasks com bloqueio

Aqui teve um outro motivo particular para nos dedicarmos em reduzir o número de perguntas: nós usávamos um modelo onde tínhamos dois boards: um de upstream e outro de downstream. E nós fazíamos perguntas parecidas nos dois boards para acompanhar a evolução do projeto. Posso falar sobre esse modelo de dois boards em outro texto se tiverem curiosidade (deixe nos comentários se sim).

Também mudamos um pouco o formato da rotação: nós tinhamos uma rotação semanal onde havia uma pessoa que fazia as perguntas. Alguém que ficava acompanhando para dizer algo que o time não havia notado e o time que intervinha a cada pergunta para falar sobre a saúde do board e das tarefas.

E para ser repetitivo e comprovar (pelo menos pra mim mesmo) que os times são organismos vivos, em cada time que passei, as perguntas foram alteradas (uns de forma mais sutil… outras de forma mais abrupta), mas o que importava no final, mais uma vez, era focar no andamento das tarefas.

Um outro modelo que rodei em outro time foi esse, onde, no fim, chegamos a 7 perguntas:

1. Finalizamos algo (desde a última daily) ou vamos finalizar hoje? Visibilidade das entregas do time. Consolida a cultura de que terminar é melhor do que começar.
2. Alguém com alguma dificuldade ou sobrecarregado e precisa de ajuda? Melhora fluxos de WIP excessivo. Tenta identificar filas com gargalos. Tarefas com owner ausente. Tarefas bloqueadas. Tarefas de alto risco. A troca de contexto faz com que as tarefas fiquem ociosas, o que afeta negativamente o fluxo.
3. Todas as tarefas possuem um dono e estão em ordem de prioridade?
4. Alguém está trabalhando em algo que não está no board? Solicitações pontuais que estão ignorando o processo. Descubra agora e os torne visíveis antes que afete o fluxo
5. Alguém está precisando ou vai precisar de uma nova tarefa? Reduz os tempos ociosos é a maneira mais fácil de reduzir o desperdício e melhorar o fluxo
6. Existe algum impedimento ou tarefa que bloqueia outra? Se uma tarefa do topo do backlog está impedindo outra, não a puxe até que ela esteja desbloqueada
7. Existe uma tarefa urgente? Certifica que o time está agindo corretamente com tarefas que foram identificados como emergenciais

Pontos negativos

É interessante porque se eu falar por mim, eu não vi pontos negativos que não pudessem ser ajustados de forma pontual com certa facilidade. Normalmente a maior dificuldade era convencer pessoas mais, digamos, tradicionais, que tentar um modelo diferente é bom.

Mas uma coisa que me chamou muito a atenção é que, com esse modelo, as pessoas ficavam quietas em algum momento. Não por falta de atenção, mas porque as coisas estavam funcionando bem e não tinha realmente o que falar. E, no meu entendimento, isso não é um problema.

Mas isso não funciona pra todo mundo. Algumas lideranças simplesmente ficam inquietas com silêncio. Ok… as vezes irrita mesmo. Mas existem silêncios e silêncios. Nesse caso eu acho que não é o fim do mundo.

Pontos positivos

Aqui eu já consigo ver alguns:

• as dailies passaram a ter uma maior adesão e um maior comprometimento de algumas pessoas. Principalmente das que se sentiam constrangidas com o modelo antigo.
• também se tornaram reuniões menos prolixas e prolíficas de modo que as reuniões passaram a durar o tempo esperado de 15min ou menos.
• E o mais importante: o centro da discussão era o board. E não as carinhas no board.
• Passou a ser mais fácil encontrar problemas de WIP como pessoas com mais de uma tarefa ou tarefas em andamento sem pessoa associada
• Esse último fez com que a qualidade da quebra das tarefas se fizesse mais real e factível e com menos blocks.
• Trouxe pro time uma maior condição de identificar o nível de impacto de expedites e tarefas não planejadas.
• Enfim… a saúde do board como um todo melhorou consideravelmente

Conclusões

Depois dos pontos positivos, conclusões aqui seriam apenas repetitivas. Mas acho que vale reforçar que acredito no modelo e nos benefícios que ele pode trazer para seu time e para seu produto.

Veja com mais detalhes o modelo original nesse post aqui mesmo no Medium.

E não deixe de me seguir nas minhas redes sociais para mais conteúdos como esse :)