Você já sabe que a daily não funciona. O difícil é falar isso.

Alguém do seu time já digitou essa mensagem. Algo perto de “acho que a daily não está funcionando pra gente”. Aí olhou pro que tinha escrito, pensou em como aquilo cairia, apagou tudo e entrou na call.

Esse apagar é o verdadeiro assunto deste texto. A pesquisa sobre daily não é difícil de achar, e quase toda ela aponta na mesma direção. Difícil é a frase. Você está tentando dizer uma coisa que carrega três riscos sociais de uma vez só, e os três grudam em você.

Risco um: você parece preguiçoso. Qualquer pedido para tirar uma reunião da agenda soa, por padrão, como um pedido para ser menos observado.

Risco dois: você parece não jogar pelo time. A daily é vendida como a coisa que mantém todo mundo alinhado. Questionar ela soa como questionar o alinhamento.

Risco três: você está atacando uma pessoa, não um processo. Alguém é dono daquela reunião. Um scrum master, um gestor, ou a pessoa que montou aquilo dois anos atrás. Essa pessoa vai ouvir uma crítica ao ritual como crítica ao próprio julgamento, porque na maioria das salas é isso mesmo.

Então ninguém diz nada, e a reunião continua de pé só porque ninguém achou as palavras.

A boa notícia é que as palavras existem e não são complicadas. Elas só precisam ser montadas numa ordem específica, e a ordem importa mais do que as evidências.

---

O enquadramento que ganha a discussão

Não defenda que a daily é perda de tempo. Esse argumento perde, sempre, pelos três motivos acima.

Defenda outra coisa: que a versão que o seu time roda não é a reunião que ela deveria ser, e ofereça um experimento reversível para consertar isso.

O Scrum Guide está do seu lado aqui, e essa é a parte que quase ninguém vai conferir. O Guia de 2020¹ define a Daily Scrum como um evento de 15 minutos para os Desenvolvedores do Time Scrum, para inspecionar o progresso em direção à Meta da Sprint e adaptar o plano. Não está definido como um relatório para o gestor. A revisão de 2020 também tirou as três perguntas prescritas que a maioria dos times ainda recita toda manhã.¹

Se a sua daily é uma roda de gente relatando ontem e hoje para quem tem o cargo mais alto na sala, manter ela não é defender o Scrum. É rodar uma coisa que o próprio manual já abandonou, e dá pra falar isso em voz alta sem acusar ninguém de nada.

É essa a jogada inteira. Você não está pedindo menos responsabilidade. Está pedindo para rodar a reunião do jeito que o framework descreve, e para testar se um formato mais barato se sustenta.

---

Parte 1: Os motivos que aguentam questionamento

Cortei muito número que circula sobre esse assunto. Tem uma nota no fim explicando quais e por quê. O que vem a seguir é o que eu colocaria na frente de um gestor cético.

1. Virou um relatório de status para cima, que é justamente o que o framework diz que ela não deveria ser. O modo de falha mais documentado. O estudo de teoria fundamentada de Stray, Sjøberg e Dingsøyr sobre daily stand-ups mostrou que os participantes valorizavam a reunião pela troca de informação e pela resolução conjunta de problemas, e reagiam mal quando ela virava relatório de status para um gestor ou acontecia com frequência e duração demais.² O mesmo achado aparece na literatura para praticantes do mesmo grupo de pesquisa.⁴

2. As três perguntas produzem narração, não coordenação. “Ontem eu mexi na task, hoje eu continuo na task.” Ninguém faz uma pergunta de volta. Nada muda por causa disso. O formato incentiva uma encenação de atividade em vez de uma inspeção do progresso rumo a uma meta, e é por isso que o Guia de 2020 tirou as perguntas.¹

3. Quem é sênior e quem está em time grande é quem menos aproveita. Stray e colegas pesquisaram desenvolvedores profissionais e encontraram notas concentradas em torno do neutro, com pessoas júnior mais positivas e pessoas sênior e de times maiores mais propensas a ver pouco valor.³ Se as pessoas mais experientes são as menos engajadas na sala, isso é um sinal sobre o formato, não sobre elas.

4. Ela parte a manhã no meio. O argumento do Paul Graham em 2009¹³ continua de pé. Quem constrói coisas precisa de blocos longos e sem interrupção, e uma única reunião no meio da manhã consegue estragar a manhã inteira ao cortar ela em dois pedaços pequenos demais para trabalho difícil. A daily das 10:30 é o exemplo clássico. E ainda tem o custo da antecipação: nos 45 minutos antes dela, ninguém começa nada profundo.

5. Trocar de tarefa piora o trabalho dos dois lados da reunião. A pesquisa de Sophie Leroy trouxe o conceito de resíduo de atenção: quando você troca de uma tarefa para outra, parte da sua atenção fica presa na primeira e o seu desempenho na segunda cai.⁵ Uma daily força essa troca duas vezes por pessoa, uma na entrada e outra na saída.

6. Voltar para o trabalho custa tempo de verdade. A pesquisa de Gloria Mark sobre interrupções é a origem do número muito citado de cerca de 23 minutos para retomar uma tarefa interrompida, e o trabalho dela com Gudith e Klocke também mostrou que as pessoas compensam a interrupção trabalhando mais rápido, ao custo de mais estresse, mais frustração e uma sensação maior de sobrecarga.⁶ Cite esse com cuidado. É o número mais maltratado da conversa sobre produtividade, e um gestor que já viu ele ser desmentido vai usar isso contra você.

7. Os impedimentos são nomeados, mas não resolvidos. Repare nisso no seu próprio time. Alguém diz que está travado, todo mundo balança a cabeça, e a solução de verdade acontece quarenta minutos depois numa DM entre duas pessoas. Se esse é o padrão, a reunião não resolveu o impedimento. Ela só marcou a conversa que resolveu.

8. A carga de reuniões se acumula no corpo. O Human Factors Lab da Microsoft fez exames de EEG em pessoas encaixadas em reuniões emendadas e viu marcadores de estresse subindo ao longo da sequência, com pausas curtas reduzindo esse acúmulo.⁸ O trabalho de Steven Rogelberg sobre a ciência das reuniões documenta a mesma coisa pelo lado das pesquisas de opinião, junto com o tempo de recuperação que as pessoas gastam se descomprimindo depois de uma reunião ruim, que se soma à duração da própria reunião.⁷

9. Não serve para times distribuídos. Sempre tem alguém entrando numa hora ruim. O manual all remote do GitLab¹⁴ é o argumento público mais completo a favor de tratar status de forma assíncrona, e é uma referência útil justamente porque vem de uma empresa que opera assim em escala, e não de um blog.

10. Uma cadência diária cobra um preço diário, tendo ou não algo para coordenar. Em times cujo trabalho é pouco acoplado, a necessidade real de coordenação é intermitente. A reunião fixa paga caro demais em todo dia tranquilo.

---

Parte 2: A contraprova, que você mesmo deve trazer

Chegue com o argumento contra você já pronto. É o caminho mais rápido para ser levado a sério, e evita que o seu gestor sinta que precisa defender a reunião sozinho.

Uma daily bem conduzida faz três coisas difíceis de substituir.

Ela traz impedimentos à tona cedo. Um problema levantado às 09:30 que, sem isso, teria consumido um dia inteiro já paga os quinze minutos sozinho. Essa é a função que a sua alternativa tem obrigação de cobrir.

Ela constrói um retrato compartilhado de quem está fazendo o quê, o que reduz trabalho duplicado e conflitante. Stray e Dingsøyr documentam isso como um dos benefícios reais que as pessoas relatam.²

Ela sustenta a segurança psicológica. Rietze e Zacher encontraram relação positiva entre daily stand-ups e segurança psicológica, que por sua vez se relacionava com satisfação no trabalho e percepção de desempenho do time.¹⁰ Isso se apoia no trabalho fundador de Edmondson, que conecta segurança psicológica ao comportamento de aprendizado do time.⁹ Um ponto de contato regular e de baixo risco faz algo pela confiança, principalmente em times novos ou distribuídos.

Então reconheça o ponto onde ele é verdadeiro. Se o seu time é pequeno, muito acoplado, júnior ou tem três semanas de vida, a daily provavelmente está pagando o próprio custo, e é bom você dizer isso.

---

Parte 3: Junte os seus próprios dados antes de abrir a boca

Duas semanas. Três coisas. Faça isso antes da conversa, porque opinião contra ritual perde, e aritmética contra ritual não.

Meça a duração real, não a agendada. Cronometre todo dia. A maioria dos times descobre que a reunião de 15 minutos é uma reunião de 22 minutos.

Faça a conta do salário. Número de participantes, vezes a duração real em horas, vezes os dias úteis do ano. Um time de oito pessoas em 15 minutos honestos dá 2 horas-pessoa por dia, cerca de 10 por semana, algo em torno de 460 horas-pessoa por ano. A um custo cheio de 60 euros por hora, isso é mais ou menos 27.000 euros, e esse número ignora o custo de recuperação dos dois lados. Use os números do seu próprio time, assim ninguém discute as entradas.

Conte os impedimentos. Por dez dias úteis, anote todo impedimento levantado na daily e marque se ele foi resolvido dentro da reunião ou em outro lugar depois. Costuma ser esse o número que encerra o debate.

Pergunte ao time de forma anônima. Uma pergunta. A daily te ajuda a fazer o seu trabalho, sim ou não, e por quê. O anonimato é o que traz a resposta de verdade, e também significa que você passa a falar pelo time e não por você, o que elimina o risco dois lá do começo.

---

Parte 4: As palavras

Quatro situações, quatro roteiros. Adapte os detalhes, mantenha a estrutura, porque é a estrutura que faz o trabalho.

Todos eles seguem os mesmos quatro tempos. Valide o que a outra pessoa realmente precisa. Nomeie o custo nos termos dela. Proponha algo reversível e com prazo definido. Assuma para si o ônus da prova e o trabalho de montar tudo.

Para o seu gestor, num 1:1

“Quero proteger o tempo de foco do time sem que você perca visibilidade, e tenho duas semanas de dados sobre como a nossa daily está sendo usada de fato. Ela dura 22 minutos, não 15. Isso dá cerca de 675 horas-pessoa por ano somando nós oito. Em dez dias, seis impedimentos foram levantados e um foi realmente resolvido na reunião. O resto foi resolvido depois, no privado.

Queria testar uma coisa por quatro semanas. Updates escritos num canal compartilhado até as 09:30, que você lê na hora que quiser, um canal só de impedimentos onde as pessoas te marcam direto no momento em que algo trava, e um sync ao vivo por semana. Vou acompanhar o tempo de resolução de impedimentos comparado com o de hoje. Se piorar, a gente volta atrás e eu falo isso na retro. Eu monto tudo.“

Para o seu scrum master

“Andei relendo o Guia de 2020. Ele define a Daily Scrum como um evento para os desenvolvedores, e tirou as três perguntas. A nossa foi virando uma rodada de updates dirigida a quem tem o cargo mais alto na sala, que é exatamente o que o Guia tenta evitar.

A gente pode tentar rodar pelo board em vez de dar a volta na roda, por uma sprint, e no fim perguntar para os desenvolvedores se ficou mais útil pra eles?“

Repare no que isso faz. Coloca o framework como autoridade no lugar de você, e transforma essa pessoa em quem está restaurando a prática, e não em quem está defendendo uma versão quebrada dela.

Para os seus colegas, antes de qualquer outra coisa

“Fala sério comigo: a daily te ajuda de verdade, ou é só uma coisa que você atravessa? Quero levantar esse assunto, mas só quero fazer isso se eu estiver falando pelo time e não por mim.”

Faça isso primeiro. Sempre. Se duas pessoas disserem que a daily é o único momento em que conseguem pedir ajuda, a sua proposta precisa preservar isso, e agora você sabe disso antes de se comprometer com uma posição em público.

Numa retrospectiva

“Queria inspecionar uma coisa hoje. Acompanhei a nossa daily por duas semanas. Aqui está quanto ela custa e quantos impedimentos ela resolveu de fato. Não estou pedindo para cancelar. Estou perguntando se a gente muda o formato por uma sprint e olha os números antes de decidir qualquer coisa permanente.”

Como proposta escrita

Assunto: experimento de quatro semanas, daily assíncrona

Hoje a nossa daily dura 22 minutos com oito pessoas, o que dá cerca de 675 horas-pessoa por ano. Nos últimos dez dias úteis, seis impedimentos foram levantados nela e um foi resolvido dentro da reunião.

Proposta, quatro semanas, totalmente reversível:

Check-ins escritos no #team-standup até as 09:30, três linhas cada. Progresso rumo à meta da sprint, foco de hoje, o que estiver travado. Impedimentos marcados direto na pessoa certa no momento em que aparecem, em vez de guardados até a manhã seguinte. Um sync ao vivo de 30 minutos na segunda, para planejamento e para tudo que precisa de conversa.

Vou acompanhar o tempo de resolução de impedimentos, o cycle time e um termômetro rápido do time, e levo os três para a retro do dia [data]. Se o tempo de resolução de impedimentos piorar, a gente volta atrás. Eu configuro as ferramentas e conduzo o teste.

A condição explícita de voltar atrás é a linha mais importante dessa mensagem. É ela que converte a sua proposta de mudança em teste, e normalmente é ela que conquista o sim.

---

Parte 5: O que vão te responder

“Preciso de visibilidade do que cada um está fazendo.” Updates escritos te dão mais do que uma reunião. Dá para buscar neles, eles ficam registrados, e você lê às 07:00 ou às 19:00 em vez de precisar estar numa sala às 09:30.

“Os impedimentos vão ficar parados.” É o contrário. Um impedimento postado no momento em que aparece recebe atenção mais rápido do que um guardado para a manhã seguinte. É exatamente essa a métrica que eu estou propondo acompanhar, e é ela que me faria encerrar o teste.

“São só quinze minutos.” São quinze minutos vezes oito pessoas, todo dia útil, mais o tempo que cada uma leva para voltar ao que estava fazendo. Aqui está o número anual.

“O Scrum exige a Daily Scrum.” O Scrum exige a Daily Scrum para os desenvolvedores, e o Guia de 2020 removeu as três perguntas que a gente ainda usa. O que a gente roda não é a coisa que o Guia descreve.¹

“O time vai perder coesão.” Esse risco é real, e é por isso que o sync semanal fica. Também vou acompanhar um termômetro do time durante o teste, então, se a coesão cair, a gente vai ver e não vai ficar adivinhando.

---

Parte 6: Cinco jeitos de perder essa discussão

Enquadrar como vontade de fazer menos. Isso confirma exatamente a suspeita com que a outra pessoa entrou na sala.

Matar a reunião sem nomear o que entra no lugar. A bagunça que vem depois vai ser atribuída a você, e com razão.

Decidir sozinho. Um ritual do time muda como decisão do time, ou volta dentro de um mês.

Pular o teste e as métricas, o que transforma uma proposta testável numa disputa de opinião contra o status quo, e o status quo ganha essas.

Ignorar as pessoas para quem aquilo funciona. Se a pessoa júnior do time depende da daily, desenhe a solução em torno dela e diga isso na sala. Não te custa nada e derruba a objeção mais forte antes de alguém levantar ela.

---

Parte 7: O que entra no lugar

Sete opções, cada uma com a desvantagem honesta anexada.

Check-ins escritos assíncronos por bot. Geekbot, Standuply ou Range perguntam para cada pessoa e postam num canal compartilhado.¹⁷ Funciona entre fusos e deixa um registro pesquisável. Pode degenerar em teatro de status que ninguém lê, se ninguém responder ao que é postado.

Daily duas vezes por semana. Mantém o encontro ao vivo e corta a frequência. Fácil de vender porque é uma mudança pequena. Precisa de um canal de apoio para o que for urgente.

Percorrer o board em vez de dar a volta na roda. Passe pelos itens de trabalho da direita para a esquerda e fale sobre as tarefas, não sobre as pessoas. Mata na hora a dinâmica de relatório pessoal. Só funciona se o board estiver realmente atualizado.

Um canal só para impedimentos. A peça de maior valor e a mais barata de acrescentar. Exige disciplina para postar e alguém de olho nele.

Pareamento sob demanda. A resolução mais rápida possível, sem plateia. Reduz a visibilidade para o time inteiro, então precisa de um rastro escrito.

Um sync semanal e profundo. Espaço para as conversas que uma reunião de 15 minutos não comporta. Raro demais para funcionar sozinho.

Dias sem reunião. A limpeza de agenda que a Shopify fez em 2023 é o exemplo corporativo mais citado, noticiada como tendo apagado milhares de reuniões recorrentes do calendário da empresa.¹⁵ Isso é uma política de foco, não um mecanismo de coordenação, então precisa ser combinado com um dos itens acima.

A combinação que funciona com mais frequência: updates escritos para a consciência do dia a dia, um canal de impedimentos para o que for urgente, um sync ao vivo por semana para o resto.

---

Parte 8: Desenhar o teste para ele sobreviver ao encontro com a retro

Escolha as métricas de sucesso antes de começar, e escolha as que o seu gestor já acredita.

Entrega. Uma medida no estilo DORA, normalmente lead time para mudanças ou frequência de deploy.¹² Cycle time serve se vocês não fazem deploy com frequência.

Tempo de resolução de impedimentos. A sua proteção contra o risco principal. É a métrica que precisa ter poder de matar o experimento, e dizer isso em voz alta é o que torna o experimento crível.

Termômetro do time. Uma pergunta, toda semana, anônima. Isso corresponde à dimensão de satisfação do framework SPACE, que existe justamente porque medir produtividade por uma métrica só dá errado.¹¹ Sem isso, dá para aumentar a vazão enquanto se queima gente em silêncio, e nunca perceber.

Quatro semanas é a duração certa. Duas são curtas demais para enxergar qualquer coisa além da novidade. Oito são longas o bastante para que voltar atrás comece a parecer um fracasso público, o que faz as pessoas defenderem o teste em vez de lerem ele com honestidade.

---

A parte que é realmente difícil

Tudo que está acima está disponível para qualquer pessoa que passe uma tarde lendo. E a maioria de quem precisa disso ainda assim não vai mandar a mensagem.

O que falta não é evidência. O que falta é uma versão da frase que diga que a reunião não está funcionando sem dar a entender que quem conduz ela não está funcionando, e isso é muito mais difícil de escrever do que uma lista de citações. Essa frase é reescrita seis vezes na caixa de rascunho do Slack e depois abandonada.

É essa distância que faz a gente construir o Subtext. A maior parte das mensagens que as pessoas não conseguem enviar não é complicada no conteúdo. São mensagens em que ter razão não basta, e a escolha das palavras carrega o risco inteiro. Uma proposta sobre a daily é uma das pequenas. O mesmo formato aparece em pedir aumento, recusar escopo, dizer para um fundador que o roadmap está errado e dizer não para um amigo.

Se você levar uma coisa daqui, leve esta: mande a mensagem com a condição de voltar atrás dentro dela. “Se o tempo de resolução de impedimentos piorar, a gente volta e eu falo isso.” Essa única frase tira o motivo que qualquer pessoa teria para dizer não.

---

Uma nota sobre os números que ficaram de fora

Vários números circulam bastante sobre esse assunto e eu não consegui sustentar nenhum deles, então eles não estão no texto acima.

A afirmação de que 80% dos desenvolvedores apontam updates irrelevantes como a maior frustração da daily não aparece na pesquisa de Stray a que costumam atribuir isso. A afirmação de que 80% dos itens de ação de reuniões nunca são concluídos circula sem fonte. A estatística muito citada de “40% mais tempo e 50% mais erros”, atribuída a um artigo recente do Journal of Experimental Psychology, parece ser uma versão distorcida de Rubinstein, Meyer e Evans em 2001, que mediu troca de tarefas em laboratório e não se estende de forma direta a uma reunião matinal.¹⁸ Os vários valores anuais em dinheiro por time para tempo de reunião desperdiçado dependem inteiramente das premissas por trás deles, e é por isso que a aritmética da Parte 3 usa as entradas do seu próprio time.

Mais uma lacuna honesta. Não achei nenhum estudo controlado rigoroso comparando diretamente updates de status escritos e assíncronos com reuniões de status síncronas em termos de resultado de entrega. GitLab, Doist e Basecamp defendem a versão escrita, e os três têm uma posição a defender. Se o seu gestor pedir essa comparação, a resposta correta é que ela parece não existir ainda, e que o seu teste de quatro semanas é o jeito de gerar ela para o seu próprio time.

---

Acha que a sua daily paga o próprio custo, ou que eu li as evidências errado? Me conta no LinkedIn.

Samet Durgun é cofundador do Subtext, um aplicativo que percebe o tom emocional das suas mensagens e reescreve elas na sua própria voz. Ele mora em Berlim.

---

Fontes

Todo link acima leva à fonte primária, quando existe uma.

1. The Scrum Guide (2020), Ken Schwaber e Jeff Sutherland, scrumguides.org. O documento mais útil para esse argumento. Leia a seção da Daily Scrum direto na fonte e cite ela literalmente. Estabelece que o evento é para os desenvolvedores, que dura 15 minutos e que as três perguntas foram removidas na revisão de 2020.

2. Stray, V., Sjøberg, D. I. K., and Dingsøyr, T. (2016). “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, volume 114. Revisado por pares. Documenta tanto o valor (troca de informação, resolução conjunta de problemas) quanto os modos de falha (relatório de status para um gestor, frequência e duração excessivas). Mande esse para o scrum master.

3. Stray, V., Moe, N. B., and Bergersen, G. R. (2017). “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams.” XP 2017, Lecture Notes in Business Information Processing. Pesquisa com desenvolvedores profissionais. Entre os números relatados estão 87% dos times ágeis fazendo daily, com notas médias em torno do neutro, pessoas júnior mais positivas, pessoas sênior e times maiores menos. Usei o achado direcional em vez do percentual.

4. Stray, V. and Moe, N. B., texto para praticantes na IEEE Software sobre adaptar a prática da daily stand-up. Defende que rituais rígidos de daily sejam adaptados ao time em vez de seguidos por inércia. O título e o ano exatos não são confirmados, e a versão que circula online traz números de participantes que eu não consegui confirmar.

5. Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, volume 109, issue 2. A origem do conceito de resíduo de atenção. Evidência forte, de fora do mundo ágil, de que trocar de tarefa piora a qualidade do que vem em seguida.

6. Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. E Mark, G. (2023). Attention Span. Hanover Square Press. Fonte dos achados sobre trabalho interrompido e do número de cerca de 23 minutos para retomar, que circula em todo lugar. O número é real, mas costuma ser citado com mais precisão do que a pesquisa por trás dele sustenta, então cite o trabalho original e diga “mais de 20 minutos”.

7. Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. A referência padrão sobre desperdício em reuniões e recuperação pós-reunião. Usei o achado qualitativo em vez de um percentual específico, porque os números variam de pesquisa para pesquisa.

8. Microsoft Human Factors Lab, estudo de EEG sobre pausas entre reuniões, publicado pelo Microsoft WorkLab e pelo Work Trend Index de 2021. Evidência fisiológica de que o estresse se acumula ao longo de reuniões consecutivas e de que as pausas reduzem isso. Útil porque é medição, e não pesquisa de opinião.

9. Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. A citação fundadora sobre segurança psicológica. É sobre times em geral, não sobre daily especificamente, então não force uma relação causal.

10. Rietze, S. and Zacher, H., pesquisa sobre daily stand-up meetings, segurança psicológica, satisfação no trabalho e percepção de desempenho do time, European Journal of Work and Organizational Psychology. O argumento publicado mais forte a favor da daily, que é exatamente por isso que você deve trazer ele. O ano de publicação não é confirmado, e a versão que circula traz uma data de 2025 que eu não consegui confirmar.

11. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. De leitura livre. Use a dimensão de satisfação e bem-estar para justificar acompanhar um termômetro do time junto com as métricas de entrega.

12. Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. A origem das quatro métricas de entrega do DORA. Use uma delas como a sua medida de vazão, assim a métrica é defensável e não parece inventada para a ocasião.

13. Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Curto, gratuito, e a coisa mais persuasiva para encaminhar a um colega que está em cima do muro.

14. GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. Uma organização grande operando publicamente com updates de status assíncronos. Prova de que o modelo funciona em escala, ainda que o GitLab tenha interesse no argumento.

15. Limpeza de agenda da Shopify, janeiro de 2023, segundo Bloomberg, Fortune e outros. Noticiada como remoção de milhares de reuniões recorrentes do calendário da empresa e proibição de reuniões recorrentes com mais de duas pessoas às quartas. O número específico de horas recuperadas vem da própria empresa, então atribua ele à Shopify em vez de apresentar como fato medido.

16. Atlassian Agile Coach, orientações sobre daily. Orientação de mercado recomendando manter a daily concisa e adaptada às necessidades do time, incluindo formatos assíncronos. Útil porque vem de uma fonte em que o seu gestor já confia quando o assunto é prática ágil.

17. Ferramentas: Geekbot e Standuply para daily assíncrona no Slack e no Teams, Range para check-ins de time. Confira o preço atual e o status do produto antes de recomendar algum internamente.

18. Rubinstein, J. S., Meyer, D. E., and Evans, J. E. (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance. A origem real da afirmação de que a troca de tarefas come “até 40% do tempo produtivo”. Está listado aqui para você conferir por conta própria em vez de repetir a versão distorcida.