O standup são quarenta anos perguntando à fonte errada

Um card ficou “Em Progresso” desde segunda. Nenhum commit jamais o tocou. Seu dono ficou quieto no canal dois dias atrás. Ninguém notou, porque notar não era trabalho de ninguém, era de todos, o que é o mesmo que de ninguém. Na sexta, na demo, alguém finalmente pergunta cadê a feature, e a resposta é a pior disponível: ela esteve travada a semana inteira, e esta é a primeira vez que alguém está ouvindo falar disso.

Essa lacuna de quatro dias, entre o momento em que o trabalho empacou e o momento em que um humano descobriu, é o problema de verdade. Não o empaque. O empaque é normal; trabalho trava. O dano é o atraso. Por quatro dias úteis um time construiu em cima de, ou esperou por, algo que não estava se movendo, e o conserto que finalmente pousa leva uma hora. O conserto custou uma hora. O atraso custou uma semana. E nada no mercado é construído para fechar esse atraso, porque tudo no mercado é construído para renderizar o atraso numa cor mais bonita.

Esta é a dor que entregaríamos a um sistema antes de qualquer outra, e ela não tem nada a ver com software ser esperto. É que status que já está escrito deveria ser lido, não recitado de memória, e por quarenta anos a cerimônia que inventamos para trazê-lo à tona fez exatamente o oposto.

A reunião pergunta à única fonte que é ao mesmo tempo enviesada e esquecida

Imagine o ritual que quase todo time roda. Quinze minutos, em pé, todo mundo dá a volta. “Ontem trabalhei na coisa de auth, hoje vou continuar, sem bloqueios.” Próxima pessoa. O formato parece um relatório de status. O conteúdo de informação é perto de zero.

Duas coisas o esvaziam, e elas se compõem. A primeira é incentivo: a sala recompensa parecer desbloqueado, não estar desbloqueado. Dizer “estou travado desde segunda e não contei a ninguém” é uma pequena confissão pública na frente de cinco colegas, e as pessoas desviam de pequenas confissões públicas. Então o card travado continua um segredo à plena vista, e “algum bloqueio?” vira a única pergunta que as pessoas são menos motivadas a responder honestamente.

A segunda é mais profunda, e é a que importa para o que escolhemos construir. A reunião pede que as pessoas relembrem o estado do trabalho de memória, em voz alta, em tempo real. Mas o estado do trabalho não está na memória de ninguém. Está no registro. O board já sabe quais cards se moveram e quais não. O histórico do git já sabe quais branches não têm commits por trás. O canal já sabe quem ficou quieto e quando. Tudo isso está escrito, com precisão, com timestamp, ali parado, e o standup ignora cada byte disso para sondar a única fonte que é ao mesmo tempo enviesada e esquecida: um humano cansado, performando para uma plateia.

A verdade sobre o que está travado já está escrita. O standup só nunca a lê.

Então a falha nunca foi que standups demoram, embora demorem. É que eles estão mirados na fonte completamente errada. Acelere-o, mova-o para uma caixa de texto, adicione um bot de lembrete, você mudou a embalagem da pergunta errada. O card que está quietamente sangrando sua semana ainda é um segredo, porque o segredo nunca esteve na sala. Estava nos boards, e ninguém os leu.

O que dissolve o atraso não é uma feature, é o que a coisa já é

Aqui está a parte que queremos ser precisos, porque é a razão inteira de isto não ser uma ferramenta de standup. Não sentamos para projetar um detector de bloqueios. A caça a bloqueios cai, quase de graça, de propriedades que o OS tem por razões inteiramente diferentes. Quatro delas, e nenhuma foi construída para scrum.

Ele está já ligado. Roda no próprio relógio, não num prompt. Pegar um card na manhã em que ele empaca requer alguém acordado e olhando antes de qualquer um perguntar, e “acordado e olhando antes de qualquer um perguntar” não é um traço de vendas nem um traço de engenharia, é o comportamento basal de um sistema proativo. Apontado para os boards da manhã, esse comportamento basal é o scrum master. Não adicionamos um agendamento. O agendamento já era o substrato.

Ele lê através de registros que não conversam entre si. O board, os commits e o chat são três visões de uma verdade, possuídas por três ferramentas diferentes que nunca iam se integrar sozinhas. Um sistema que vive onde o trabalho acontece segura os três de uma vez e os compara: este card se moveu no board mas não tem branch; o nome deste dono está em dois cards travados e ele não posta desde terça. Esse cruzamento também não é uma capacidade de scrum, é o que integração mais memória faz a qualquer domínio que você aponte para ele.

Ele lembra de ontem, então consegue te dizer o que mudou. “Travado” não é uma propriedade de um card; é uma propriedade de um card ao longo do tempo, mesma coluna, sem commits, três dias seguidos. Você só consegue ver isso se segurou o estado de ontem para comparar com o desta manhã. A memória que torna isso possível é o mesmo company brain que lembra a última data de contrato de um cliente e a promessa aberta de um colega. Ele não está fazendo nada especial para standups. Standups são só mais uma coisa que ele calha de lembrar.

E ele tem permissão de agir, que é onde o problema de honestidade quietamente se dissolve. Ler o registro é a metade fácil; um dashboard lê o registro e não muda nada, porque um dashboard é uma caixa que você tem que lembrar de abrir, e os cards que você mais precisa ver são os que você menos provavelmente vai procurar. O sistema não espera ser aberto. Quando vê um card travado três dias com um dono quieto, ele se dirige a esse dono diretamente, “o card #214 não se move desde segunda e ainda não há PR, o que está bloqueando?”, no canal onde ele já trabalha. Uma pergunta um-a-um na manhã em que um card empaca é uma pergunta completamente diferente de “algum bloqueio?” gritado num standup. Não há plateia para performar. Ele nomeia o card e cita a evidência, então “estou bem” não é uma resposta disponível. O sistema não é mais corajoso que o humano. Ele só está disposto a fazer a pergunta pequena e levemente desconfortável toda manhã sem vacilar, a parte precisa em que humanos são piores.

Ligado / lê-através / lembra / age. Note que nenhum desses foi uma feature de scrum. Eles são o substrato. A caça a bloqueios é o que o substrato faz quando você o aponta para um board, que é uma afirmação muito diferente de “construímos um bot de standup.”

A disciplina que ganha o direito de ser lido

Há um jeito de fazer isso mal, e a maioria das tentativas pousa lá, então vale nomear o padrão. A versão preguiçosa posta um resumo toda manhã: uma parede de checkmarks verdes, tudo renderizado, nada julgado. Isso treina o time a passar batido por ele, e na única manhã em que algo está de fato errado, o alerta está enterrado no mesmo formato das noventa manhãs em que não estava. Um resumo que diz tudo todo dia não diz nada.

O padrão que um bom scrum master humano já segura é o oposto: traga à tona apenas a exceção. Os cards andando bem não ganham uma linha. Os dois que estão travados ganham, com a evidência, não um vibe. “Sem commits desde segunda, dono ativo pela última vez na terça.” Um sistema ganha o direito de ser lido toda manhã sendo majoritariamente silencioso, gastando sua credibilidade apenas nos cards que precisam de um humano. Isso não é uma feature que você lança. É um padrão que você segura, e segurá-lo consistentemente, toda manhã, sem a fadiga que faz uma pessoa deixar passar, é o trabalho inteiro.

É também por isso que daríamos a um sistema esse trabalho primeiro, antes de qualquer coisa mais chamativa. Não porque seja impressionante, mas porque é o lugar mais barato de deixar o loop honesto. Uma captura perdida num card custa um dia. O trabalho é puro padrão-sobre-um-registro: notar antes de ser perguntado, cruzar o que está escrito, fazer follow-up com uma pessoa específica sobre uma coisa específica. Deixe esse loop confiável onde a aposta é um dia, e você provou exatamente a espinha que você ia querer apontada onde a aposta é um trimestre.

A amplitude nunca foi o ponto, e é por isso que ela está lá

Porque, e esta é a parte que o enquadramento de scrum esconde, essa espinha não tem nada a ver com scrum.

Note o formato do trabalho que o sistema acabou de fazer: ele vigiou um registro sem ser pedido, cruzou fontes que não conversam entre si, lembrou o que mudou desde ontem, e fez follow-up com uma pessoa nomeada sobre uma coisa específica. Agora descreva uma renovação prestes a vencer. Um thread de suporte que ficou em silêncio no meio da resolução. Uma data de contrato que ninguém sinalizou. Um passo de onboarding em que um novo cliente empacou três dias atrás. Cada um deles é o formato idêntico: um empaque, escrito em algum registro, que um humano cansado deveria pegar e não pegou.

Então o mesmo sistema carrega todos eles, não porque lançamos uma feature por trabalho para casar com uma ferramenta de ponto por trabalho, mas porque cada um desses trabalhos se reduz ao loop que acabamos de construir para cards e commits. A amplitude não é uma checklist da qual nos orgulhamos, e certamente não é nós alcançando uma categoria que outra pessoa definiu. É o sinal de que encontramos o substrato certo. Quando uma espinha, ligado, lê-através, lembra, age, faz uma dúzia de trabalhos não relacionados caírem de graça, isso não é uma contagem de features. É evidência de que você construiu a camada sob as features, a camada que ninguém está vendendo ainda.

Quem você para de pedir para ser a memória da org

Pense em quem de fato roda o standup hoje.

Normalmente é a pessoa que você menos pode bancar gastar nisso, um fundador, um lead, o um operador que segura o mapa inteiro na cabeça. Ele roda a reunião, carrega os rankings, lembra na quinta que um card não se move desde segunda. Uma fatia de cada uma das manhãs dele vai para ser a memória da org e o cobrador da org. Ele é bom nisso precisamente porque se importa, e se importar é exatamente o recurso que você não quer queimado lendo boards e perseguindo follow-ups.

Esse trabalho parece liderança. A maior parte é presença. A parte que é de fato liderança, decidir o que o time deveria construir em seguida, quanto “travado” deveria poder custar, quando matar um card em vez de desbloqueá-lo, como dizer a alguém que o trabalho dele não está emplacando, nada disso é a leitura e a perseguição. A leitura e a perseguição são o imposto que você paga para alcançar o julgamento, e você vem pagando-o com as melhores horas da sua melhor pessoa.

Entregue a metade fiel a um sistema e a troca sai limpa. O sistema lê cada board toda manhã e faz a pergunta desconfortável sem pavor. O humano para de ser a memória e o cobrador, e passa a ser quem decide o que a resposta significa. O card está travado, um sistema pode te dizer isso, cedo o suficiente para importar. Se empurra a data, troca o dono, ou corta a feature sempre foi seu para decidir, e é a única parte que vale a pena manter.

Este é o mundo rumo ao qual estamos construindo na Apollo Space, e ele não está no mercado ainda, porque o mercado ainda está vendendo dashboards mais bonitos e cerimônias mais rápidas, embalagem para a pergunta errada. Achamos que o atraso entre travado e sabido não deveria existir, e você não o fecha com uma reunião melhor. Você o fecha com um sistema que vive no trabalho, segura ontem na memória, e está disposto a perguntar. O standup nunca foi o ponto. Status que já está escrito deveria ser lido, não recitado de memória, e saber o que está travado, cedo o suficiente para agir, é a primeira prova silenciosa de uma empresa onde as melhores horas de ninguém são gastas sendo sua memória.