Alternativas à daily standup: as provas e os guiões

Já houve alguém na tua equipa que escreveu a mensagem. Qualquer coisa como “acho que a daily não está a resultar connosco”. Depois olhou para aquilo, pensou em como ia cair, apagou tudo e entrou na chamada.

É desse apagar que este texto trata. A investigação sobre dailies não é difícil de encontrar e quase toda aponta no mesmo sentido. Difícil é a frase. Estás a tentar dizer uma coisa que carrega três riscos sociais ao mesmo tempo, e os três colam-se a ti.

Risco um: soas a preguiçoso. Qualquer pedido para acabar com uma reunião lê-se, por defeito, como um pedido para seres menos observado.

Risco dois: soas a quem não veste a camisola. A daily é apresentada como aquilo que mantém toda a gente alinhada. Pôr-lhe objeções soa a pôr objeções ao alinhamento.

Risco três: estás a atacar uma pessoa, não um processo. Aquela reunião tem dono. Um scrum master, um chefe, ou a pessoa que a marcou há dois anos. Vão ouvir uma crítica ao ritual como uma crítica ao discernimento deles, porque na maioria das salas é mesmo isso.

Por isso ninguém diz nada, e a reunião continua a acontecer só porque ninguém encontrou as palavras.

A boa notícia é que as palavras existem e não são complicadas. Só têm de ser montadas por uma ordem específica, e a ordem conta mais do que as provas.

A reformulação que ganha a discussão

Não defendas que a daily é uma perda de tempo. Esse argumento perde sempre, pelas três razões acima.

Defende antes que a versão que a tua equipa faz não é a reunião que devia ser, e propõe uma experiência reversível para a corrigir.

O Scrum Guide está do teu lado, e essa é a parte que quase ninguém vai confirmar. O Guia de 2020¹ define a Daily Scrum como um evento de 15 minutos para os Developers da Scrum Team, para inspecionar o progresso rumo ao Sprint Goal e adaptar o plano. Não está definido como um relatório para um chefe. A revisão de 2020 eliminou também as três perguntas prescritas que a maior parte das equipas ainda recita todas as manhãs.¹

Se a tua daily é uma roda de pessoas a reportar o ontem e o hoje a quem for mais sénior na sala, não estás a defender o Scrum ao mantê-la. Estás a fazer uma coisa que o próprio livro de regras já deitou fora, e podes dizer isso em voz alta sem acusar ninguém de nada.

É essa a jogada toda. Não estás a pedir menos responsabilização. Estás a pedir para fazer a reunião como a framework a descreve, e para testar se um formato mais barato se aguenta.

Parte 1: As razões que resistem ao escrutínio

Cortei muitos dos números que circulam sobre este tema. No fim há uma nota a explicar quais e porquê. O que se segue é o que eu poria à frente de um chefe cético.

1. Transformou-se num relatório de estado para cima, que é precisamente o que a framework diz que não devia ser. O modo de falha mais documentado. O estudo de teoria fundamentada de Stray, Sjøberg e Dingsøyr sobre daily stand-ups concluiu que os participantes as valorizavam pela partilha de informação e pela resolução conjunta de problemas, e reagiam mal quando a reunião se transformava em reporte de estado a um chefe ou acontecia com demasiada frequência e durante demasiado tempo.² A mesma conclusão aparece na literatura para profissionais do mesmo grupo de investigação.⁴

2. As três perguntas produzem narração em vez de coordenação. “Ontem trabalhei no ticket, hoje continuo no ticket.” Ninguém faz uma pergunta a seguir. Nada muda por causa disso. O formato incentiva uma encenação de atividade em vez de uma inspeção do progresso rumo a um objetivo, e foi por isso que o Guia de 2020 deitou as perguntas fora.¹

3. Os engenheiros séniores e as equipas grandes são os que menos ganham com ela. Stray e colegas inquiriram programadores profissionais e encontraram avaliações concentradas à volta do neutro, com os juniores mais positivos e os séniores e os membros de equipas maiores mais inclinados a ver pouco valor.³ Se as pessoas com mais experiência são as menos envolvidas na sala, isso diz alguma coisa sobre o formato, não sobre elas.

4. Parte a manhã ao meio. O argumento de Paul Graham de 2009¹³ continua a aguentar-se. Quem faz coisas precisa de blocos longos e sem interrupções, e uma única reunião a meio da manhã consegue estragar a manhã inteira ao cortá-la em dois bocados pequenos de mais para trabalho difícil. Uma daily às 10:30 é o exemplo canónico. E há ainda um custo de antecipação: nos 45 minutos antes, ninguém começa nada de fundo.

5. Trocar de tarefa estraga o trabalho dos dois lados da reunião. A investigação de Sophie Leroy introduziu o resíduo de atenção: quando passas de uma tarefa para outra, parte da tua atenção fica presa à primeira e o teu desempenho na segunda sofre com isso.⁵ Uma daily obriga a essa troca duas vezes por cada pessoa presente, uma à entrada e outra à saída.

6. Voltar ao trabalho custa tempo a sério. A investigação de Gloria Mark sobre interrupções é a origem do número muito citado dos cerca de 23 minutos para regressar a uma tarefa interrompida, e o trabalho dela com Gudith e Klocke concluiu também que as pessoas compensam as interrupções trabalhando mais depressa, à custa de mais stress, mais frustração e maior carga percebida.⁶ Cita este com cuidado. É o número mais maltratado da conversa sobre produtividade, e um chefe que já o viu desmontado vai usar isso contra ti.

7. Os bloqueios são nomeados, mas não resolvidos. Repara nisto na tua própria equipa. Alguém diz que está bloqueado, toda a gente acena com a cabeça, e a resolução acontece quarenta minutos depois numa DM entre duas pessoas. Se é esse o padrão, a reunião não resolveu o bloqueio. Só marcou a conversa que o resolveu.

8. A carga de reuniões acumula-se no corpo. O Human Factors Lab da Microsoft fez EEG a participantes em reuniões seguidas e viu marcadores de stress a subir ao longo da sequência, com pausas curtas a travar essa subida.⁸ O trabalho de Steven Rogelberg sobre ciência das reuniões documenta o mesmo pelo lado dos inquéritos, e ainda o tempo de recuperação que as pessoas gastam a descomprimir depois de uma má reunião, que se soma à duração da própria reunião.⁷

9. Não serve para equipas distribuídas. Há sempre alguém a apanhá-la a uma hora má. O manual all remote da GitLab¹⁴ é o argumento público mais completo a favor de tratar o estado de forma assíncrona, e é uma referência útil precisamente por vir de uma empresa que trabalha assim à escala, e não de um blog.

10. Uma cadência diária cobra um preço diário, haja ou não alguma coisa para coordenar. Em equipas cujo trabalho é pouco acoplado, a necessidade real de coordenação é intermitente. A reunião fixa paga a mais em todos os dias calmos.

Parte 2: As provas contra ti, que deves ser tu a trazer

Entra com o caso contra ti já montado. É o caminho mais rápido para te levarem a sério, e evita que o teu chefe sinta que tem de defender a reunião sozinho.

Bem feitas, as dailies fazem três coisas difíceis de substituir.

Trazem os bloqueios à superfície cedo. Um problema levantado às 09:30 que de outra forma teria comido um dia inteiro justifica sozinho os quinze minutos. É esta a função que a tua alternativa tem obrigatoriamente de cobrir.

Constroem uma imagem partilhada de quem está a fazer o quê, o que reduz trabalho duplicado e trabalho em conflito. Stray e Dingsøyr documentam isto como um dos benefícios genuínos que as pessoas relatam.²

Ajudam a segurança psicológica. Rietze e Zacher encontraram uma relação positiva entre as reuniões diárias e a segurança psicológica, que por sua vez se relacionava com a satisfação no trabalho e com a perceção do desempenho da equipa.¹⁰ Isto assenta no trabalho fundador de Edmondson, que liga a segurança psicológica ao comportamento de aprendizagem das equipas.⁹ Um ponto de contacto regular e de baixo risco faz alguma coisa pela confiança, sobretudo em equipas novas ou distribuídas.

Por isso concede o ponto onde ele é verdadeiro. Se a tua equipa é pequena, muito acoplada, júnior ou tem três semanas de vida, a daily está provavelmente a justificar o custo e deves dizê-lo.

Parte 3: Arranja os teus próprios dados antes de abrires a boca

Duas semanas. Três coisas. Faz isto antes da conversa, porque opinião contra ritual perde e aritmética contra ritual não.

Mede a duração real, não a duração agendada. Cronometra todos os dias. A maioria das equipas descobre que a reunião de 15 minutos é uma reunião de 22 minutos.

Faz as contas aos salários. Número de presentes, vezes a duração real em horas, vezes os dias úteis do ano. Uma equipa de oito pessoas em 15 minutos reais dá 2 horas-pessoa por dia, cerca de 10 por semana, à volta de 460 horas-pessoa por ano. A um custo carregado de 60 euros à hora, são cerca de 27.000 euros, e esse valor ignora o custo de recuperação de um lado e do outro. Usa os números da tua própria equipa, para ninguém poder discutir os dados de entrada.

Conta os bloqueios. Durante dez dias úteis, aponta todos os bloqueios levantados na daily e marca se foram resolvidos dentro da reunião ou noutro sítio a seguir. Normalmente é este o número que fecha o debate.

Pergunta à equipa em anónimo. Uma pergunta. A daily ajuda-te a fazer o teu trabalho, sim ou não, e porquê. É o anonimato que te dá a resposta verdadeira, e também faz com que passes a falar pela equipa e não por ti, o que elimina o risco dois da lista lá de cima.

Parte 4: As palavras

Quatro situações, quatro guiões. Adapta os detalhes, mantém a estrutura, porque é a estrutura que está a fazer o trabalho.

Todos seguem os mesmos quatro tempos. Valida aquilo de que a outra pessoa precisa mesmo. Nomeia o custo nos termos dela. Propõe uma coisa reversível e com prazo. Fica tu com o ónus da prova e com o trabalho de montar aquilo.

Ao teu chefe, numa conversa a dois

“Quero proteger o tempo de foco da equipa sem que percas visibilidade, e tenho duas semanas de dados sobre a forma como a nossa daily está mesmo a ser usada. Demora 22 minutos, não 15. Isso dá cerca de 675 horas-pessoa por ano entre os oito. Em dez dias foram levantados seis bloqueios e um foi mesmo resolvido na reunião. Os outros ficaram resolvidos a seguir, em DMs.

Queria fazer isto durante quatro semanas. Atualizações escritas num canal partilhado até às 09:30, que podes ler quando te der jeito, um canal só para bloqueios onde as pessoas te marcam diretamente assim que ficam presas, e um sync ao vivo por semana. Vou medir o tempo de resolução dos bloqueios contra o que temos agora. Se piorar, voltamos atrás e sou eu a dizê-lo na retro. Monto tudo eu.”

Ao teu scrum master

“Andei a reler o Guia de 2020. Define a Daily Scrum como um evento para os developers, e eliminou as três perguntas. A nossa foi derivando para uma ronda de atualizações dirigidas a quem for mais sénior na sala, que é precisamente aquilo que o Guia está a tentar evitar.

Podíamos experimentar fazê-la a partir do board em vez de à volta da roda, durante um sprint, e perguntar depois aos developers se lhes ficou mais útil?”

Repara no que isto faz. Entrega-lhes a framework como autoridade, em vez de ti, e transforma-os na pessoa que está a repor a prática, em vez da pessoa que está a defender uma versão avariada dela.

Aos teus colegas, antes de fazeres seja o que for

“Sê franco comigo. A daily ajuda-te mesmo, ou é só uma coisa que despachas? Quero levantar o assunto, e só o quero fazer se estiver a falar pela equipa e não por mim.”

Faz isto primeiro. Sempre. Se duas pessoas disserem que a daily é o único momento em que conseguem pedir ajuda, a tua proposta tem de manter isso, e agora já sabes antes de te teres comprometido com uma posição em público.

Numa retrospetiva

“Hoje quero inspecionar uma coisa. Segui a nossa daily durante duas semanas. Isto é o que ela custa e isto é quantos bloqueios resolveu de facto. Não estou a pedir para acabarmos com ela. Estou a perguntar se mudamos o formato durante um sprint e olhamos para os números antes de decidirmos alguma coisa definitiva.”

Como proposta escrita

Assunto: Experiência de quatro semanas, daily assíncrona

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

Proposta, quatro semanas, totalmente reversível:

Check-ins escritos no #team-standup até às 09:30, três linhas cada um. Progresso rumo ao objetivo do sprint, foco de hoje, o que estiver bloqueado. Bloqueios marcados diretamente à pessoa certa assim que aparecem, em vez de ficarem à espera da manhã seguinte. Um sync ao vivo de 30 minutos à segunda-feira, para planeamento e para tudo o que precise de conversa.

Vou medir o tempo de resolução de bloqueios, o cycle time e um pulso rápido da equipa, e levo os três à retro de [data]. Se o tempo de resolução de bloqueios piorar, voltamos atrás. Sou eu a configurar as ferramentas e a conduzir o teste.

A condição explícita de recuo é a linha mais importante daquela mensagem. É ela que converte a tua proposta de mudança em teste, e normalmente é ela que arranca o sim.

Parte 5: O que te vão responder

“Preciso de visibilidade sobre o que cada um está a fazer.” As atualizações escritas dão-te mais do que uma reunião. São pesquisáveis, ficam registadas, e podes lê-las às 07:00 ou às 19:00 em vez de estares numa sala às 09:30.

“Os bloqueios vão ficar ali parados.” É ao contrário. Um bloqueio publicado no momento em que aparece recebe atenção mais depressa do que um que fica guardado para a manhã seguinte. É essa a métrica exata que estou a propor que sigamos, e é a que me faria cancelar o teste.

“São só quinze minutos.” São quinze minutos vezes oito pessoas, todos os dias úteis, mais o tempo de que cada um precisa para voltar ao que estava a fazer. Aqui está o número anual.

“O Scrum exige uma Daily Scrum.” O Scrum exige uma Daily Scrum para os developers, e o Guia de 2020 removeu as três perguntas que continuamos a usar. Aquilo que fazemos não é a coisa que o Guia descreve.¹

“A equipa vai perder coesão.” É um risco real, e é por isso que o sync semanal fica. Também vou medir um pulso da equipa durante o teste, por isso se a coesão cair vamos vê-lo em vez de andarmos a adivinhar.

Parte 6: Cinco formas de perder esta discussão

Apresentar aquilo como querer fazer menos. Confirma exatamente a suspeita com que a outra pessoa entrou na sala.

Matar a reunião sem indicar o que a substitui. A confusão que se segue vai ser atribuída a ti, e ainda bem.

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

Saltar o teste e as métricas, o que transforma uma proposta testável num concurso de opiniões contra o status quo, e esses o status quo ganha.

Ignorar as pessoas para quem aquilo funciona. Se o júnior da equipa depende dela, desenha a solução à volta dele e di-lo na sala. Não te custa nada e elimina a objeção mais forte antes de alguém a levantar.

Parte 7: O que a substitui

	Daily ao vivo	Atualizações escritas assíncronas	Sync semanal mais canal de bloqueios
Custo de tempo	Alto, cresce com o número de pessoas	Custo síncrono quase nulo	Baixo
Custo de interrupção	Alto, diário, a meio da manhã	Mínimo, cada um escolhe quando	Baixo, um ponto fixo
Rapidez nos bloqueios	Até 24 horas de espera	Imediata se marcares alguém	Imediata se marcares alguém
Registo	Nenhum, a não ser que alguém escreva	Pesquisável por defeito	Parcial
Funciona entre fusos horários	Mal	Bem	Razoavelmente
Coesão	Boa quando é bem feita	Fraca por si só	Boa

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

Check-ins escritos assíncronos com um bot. O Geekbot, o Standuply ou o Range perguntam a cada pessoa e publicam num canal partilhado.¹⁷ Funciona entre fusos horários e deixa um registo pesquisável. Pode degenerar em teatro de estado que ninguém lê, se ninguém responder ao que é publicado.

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

Percorrer o board em vez da roda. Passa pelos itens de trabalho da direita para a esquerda e fala dos tickets em vez das pessoas. Mata na hora a dinâmica de reporte pessoal. Só funciona se o board estiver mesmo atualizado.

Um canal só para bloqueios. A peça de maior valor e a mais barata de acrescentar. Exige disciplina para publicar, e alguém a vigiá-lo.

Pairing a pedido. A resolução mais rápida possível, sem plateia. Reduz a visibilidade para a equipa toda, por isso precisa de um rasto escrito.

Um sync semanal a fundo. Espaço para as conversas que uma reunião de 15 minutos não aguenta. Demasiado espaçado para funcionar sozinho.

Dias sem reuniões. A limpeza de calendário da Shopify em 2023 é o exemplo empresarial mais citado, noticiado como tendo apagado milhares de reuniões recorrentes do calendário da empresa.¹⁵ Isto é uma política de foco e não um mecanismo de coordenação, por isso tem de ser combinado com um dos anteriores.

A combinação que resulta mais vezes: atualizações escritas para a consciência do dia a dia, um canal de bloqueios para o que for urgente, e um sync ao vivo por semana para o resto.

Parte 8: Desenhar o teste para sobreviver ao contacto com uma retro

Escolhe as métricas de sucesso antes de começares, e escolhe as que o teu chefe já valoriza.

Entrega. Uma medida ao estilo DORA, normalmente lead time for changes ou frequência de deploys.¹² O cycle time serve se não fizerem deploys com frequência.

Tempo de resolução de bloqueios. A tua salvaguarda no risco principal. É esta a métrica que deve poder matar a experiência, e é dizê-lo em voz alta que torna a experiência credível.

Pulso da equipa. Uma pergunta, semanal, anónima. Corresponde à dimensão de satisfação da framework SPACE, que existe precisamente porque medir produtividade com uma métrica única corre mal.¹¹ Sem isso, podes melhorar o débito enquanto queimas as pessoas em silêncio e nunca dás por nada.

Quatro semanas é a duração certa. Duas são curtas de mais para ver o que quer que seja para lá da novidade. Oito são longas o suficiente para que recuar comece a saber a fracasso público, o que leva as pessoas a defender o teste em vez de o lerem com honestidade.

A parte que é mesmo difícil

Tudo o que está acima está ao alcance de quem passe uma tarde a ler. E a maior parte das pessoas que precisa disto continua a não enviar a mensagem.

Não são as provas que faltam. O que falta é uma versão da frase que diga que a reunião não está a funcionar sem dar a entender que a pessoa que a conduz não está a funcionar, e isso é muito mais difícil de escrever do que uma lista de citações. É reescrita seis vezes na caixa de rascunho do Slack e depois abandonada.

É por causa dessa distância que fazemos 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 chega, e em que as palavras carregam o risco todo. Uma proposta sobre a daily é das pequenas. A mesma forma aparece em pedir um aumento, recusar mais âmbito, dizer a um fundador que o roadmap está errado, e dizer não a um amigo.

Se levares uma coisa daqui, leva esta: envia a mensagem com a condição de recuo lá dentro. “Se o tempo de resolução de bloqueios piorar, voltamos atrás e sou eu a dizê-lo.” É essa única frase que tira a qualquer pessoa a razão para dizer não.

Uma nota sobre os números que deixei de fora

Há vários números que circulam muito sobre este tema e que eu não consigo defender, por isso não estão no texto acima.

A afirmação de que 80% dos programadores apontam as atualizações irrelevantes como a maior frustração da daily não aparece no inquérito de Stray a que costuma ser atribuída. A afirmação de que 80% das ações decididas em reuniões nunca chegam a ser concluídas circula sem fonte. A estatística muito citada dos “40% mais tempo e 50% mais erros”, atribuída a um artigo recente do Journal of Experimental Psychology, parece ser uma versão baralhada 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 de manhã.¹⁸ Os vários valores anuais em dólares por equipa para tempo de reunião desperdiçado dependem inteiramente dos pressupostos que estão por trás deles, e é por isso que a aritmética da Parte 3 usa antes os números da tua própria equipa.

Mais uma lacuna honesta. Não consegui encontrar um estudo controlado e rigoroso que compare diretamente atualizações de estado escritas e assíncronas com reuniões de estado síncronas, medindo resultados de entrega. A GitLab, a Doist e a Basecamp defendem todas a versão escrita, e todas as três têm uma posição a proteger. Se o teu chefe pedir essa comparação, a resposta correta é que ela parece ainda não existir, e que o teu teste de quatro semanas é a forma de a gerares para a tua própria equipa.

Achas que a tua daily justifica o custo, ou que eu li mal as provas? Diz-me no LinkedIn.

Samet Durgun é cofundador do Subtext, uma app que apanha o tom emocional das tuas mensagens e as reescreve na tua própria voz. Vive em Berlim.

Fontes

Todos os links acima vão para a fonte primária, sempre que existe uma.

The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. O documento mais útil para este argumento. Lê diretamente a secção da Daily Scrum e cita-a à letra. Estabelece que o evento é para os developers, que dura 15 minutos, e que as três perguntas foram removidas na revisão de 2020.
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. Revisto por pares. Documenta tanto o valor (partilha de informação, resolução conjunta de problemas) como os modos de falha (reporte de estado a um chefe, frequência e duração excessivas). Envia este ao teu scrum master.
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. Inquérito a programadores profissionais. Entre os valores reportados estão 87% de equipas ágeis a fazer dailies, com avaliações médias à volta do neutro, os juniores mais positivos, os séniores e as equipas maiores menos. Usei a conclusão direcional e não a percentagem.
Stray, V. e Moe, N. B., texto para profissionais na IEEE Software sobre adaptar a prática do daily stand-up. Defende que os rituais rígidos de daily devem ser adaptados à equipa em vez de seguidos por defeito. O título e o ano exatos estão por confirmar, e a versão que circula online inclui números de participantes que não consegui verificar.
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, número 2. A origem do resíduo de atenção. Prova forte, e vinda de fora do mundo ágil, de que trocar de tarefa degrada a qualidade do que vem a seguir.
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. A fonte das conclusões sobre trabalho interrompido e do número de cerca de 23 minutos de retoma que circula por todo o lado. O número é real, mas é citado muitas vezes com mais precisão do que a investigação suporta, por isso cita o trabalho original e diz “mais de 20 minutos”.
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. A referência padrão sobre desperdício em reuniões e sobre a recuperação a seguir a uma reunião. Usei a conclusão qualitativa em vez de uma percentagem específica, porque os números variam de inquérito para inquérito.
Microsoft Human Factors Lab, estudo de EEG sobre pausas entre reuniões, publicado através do Microsoft WorkLab e do Work Trend Index de 2021. Prova fisiológica de que o stress se acumula ao longo de reuniões consecutivas e de que as pausas o reduzem. Útil porque é medição e não inquérito.
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. A citação fundadora sobre segurança psicológica. É sobre equipas em geral e não sobre dailies em particular, por isso não exageres na ligação causal.
Rietze, S. e Zacher, H., investigação sobre reuniões diárias, segurança psicológica, satisfação no trabalho e perceções de desempenho da equipa, European Journal of Work and Organizational Psychology. O argumento publicado mais forte a favor das dailies, que é exatamente a razão para seres tu a trazê-lo. O ano de publicação está por confirmar; a versão que circula indica uma data de 2025 que não consegui verificar de forma independente.
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. Usa a dimensão de satisfação e bem-estar para justificar medir um pulso de equipa a par das métricas de entrega.
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. A fonte das quatro métricas de entrega DORA. Usa uma delas como medida de débito, para a métrica ser defensável em vez de inventada para a ocasião.
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Curto, gratuito, e a coisa mais persuasiva para reencaminhar a um colega indeciso.
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. Uma organização grande a operar publicamente com atualizações de estado assíncronas. Prova de que o modelo funciona à escala, ainda que a GitLab tenha interesse no argumento.
Limpeza de calendário da Shopify, janeiro de 2023, noticiada pela Bloomberg, pela Fortune e por outros. Noticiada como tendo removido milhares de reuniões recorrentes do calendário da empresa e proibido reuniões recorrentes com mais de duas pessoas às quartas-feiras. O número específico de horas recuperadas vem da própria empresa, por isso atribui-o à Shopify em vez de o apresentares como facto medido.
Atlassian Agile Coach, orientações sobre standups. Orientação da indústria que recomenda manter as dailies curtas e adaptá-las às necessidades da equipa, incluindo formatos assíncronos. Útil porque vem de uma fonte em que o teu chefe já confia em matéria de práticas ágeis.
Ferramentas: Geekbot e Standuply para dailies assíncronas no Slack e no Teams, Range para check-ins de equipa. Confirma os preços atuais e o estado dos produtos antes de recomendares algum internamente.
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 verdadeira origem da afirmação dos “até 40% do tempo produtivo” perdidos em troca de tarefas. Fica aqui para poderes verificar tu em vez de repetires a versão baralhada.