Alternativas al daily standup: datos y qué decir

Alguien de tu equipo ya ha escrito el mensaje. Algo parecido a “creo que el daily standup no nos está funcionando”. Luego lo ha releído, ha pensado en cómo iba a caer, lo ha borrado y se ha metido en la llamada.

Ese borrado es el verdadero tema de este artículo. La investigación sobre los standups no es difícil de encontrar y casi toda apunta en la misma dirección. Lo difícil es la frase. Estás intentando decir algo que carga con tres riesgos sociales a la vez, y los tres te señalan a ti personalmente.

Riesgo uno: suenas a vago. Cualquier petición de eliminar una reunión se lee, por defecto, como una petición de que te vigilen menos.

Riesgo dos: suenas a que no eres de equipo. El standup se presenta como lo que mantiene a todo el mundo alineado. Cuestionarlo suena a cuestionar la alineación.

Riesgo tres: estás atacando a una persona, no a un proceso. Esa reunión tiene dueño. Un scrum master, un manager o quien la montó hace dos años. Van a oír una crítica al ritual como una crítica a su criterio, porque en la mayoría de las salas es exactamente eso.

Así que la gente no dice nada, y la reunión sigue en pie por el simple hecho de que nadie ha encontrado las palabras.

La buena noticia es que las palabras existen y no son complicadas. Solo hay que montarlas en un orden concreto, y el orden importa más que los datos.

El giro que gana la discusión

No discutas que el standup es una pérdida de tiempo. Ese argumento pierde siempre, por las tres razones de arriba.

Discute que la versión que hace tu equipo no es la reunión que se supone que tendría que ser, y ofrece un experimento reversible para arreglarlo.

La Guía de Scrum está de tu lado aquí, que es la parte que casi nadie comprueba. La Guía de 2020¹ define el Daily Scrum como un evento de 15 minutos para los Developers del Scrum Team, para inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el plan. No lo define como un informe para un manager. La revisión de 2020 también eliminó las tres preguntas prescritas que la mayoría de los equipos siguen recitando cada mañana.¹

Si vuestro standup funciona como un corro de gente contando lo de ayer y lo de hoy a quien tenga más galones en la sala, no estás defendiendo Scrum al mantenerlo. Estás haciendo algo que el reglamento ya descartó, y eso puedes decirlo en voz alta sin acusar a nadie de nada.

Ese es todo el movimiento. No estás pidiendo menos responsabilidad. Estás pidiendo hacer la reunión como la describe el framework, y probar si un formato más barato aguanta.

Parte 1: Las razones que aguantan un examen

He descartado muchos de los números que circulan sobre este tema. Al final hay una nota que explica cuáles y por qué. Lo que viene es lo que yo pondría delante de un manager escéptico.

1. Se ha convertido en un informe de estado hacia arriba, que es justo lo que el framework dice que no debería ser. El modo de fallo mejor documentado. El estudio de teoría fundamentada de Stray, Sjøberg y Dingsøyr sobre los daily stand-ups encontró que los participantes los valoraban por compartir información y resolver problemas en común, y que reaccionaban mal cuando la reunión se convertía en un informe de estado para un manager o cuando era demasiado frecuente y demasiado larga.² El mismo hallazgo aparece en la literatura para profesionales del mismo grupo de investigación.⁴

2. Las tres preguntas producen narración en vez de coordinación. “Ayer estuve con el ticket, hoy sigo con el ticket.” Nadie repregunta. Nada cambia por eso. El formato premia una representación de actividad en lugar de una inspección del progreso hacia un objetivo, que es justo por lo que la Guía de 2020 eliminó las preguntas.¹

3. Los ingenieros senior y los equipos grandes son los que menos sacan de él. Stray y sus colegas encuestaron a desarrolladores profesionales y encontraron valoraciones agrupadas en torno a lo neutro, con los junior más positivos y los senior y los miembros de equipos grandes más propensos a verle poco valor.³ Si la gente con más experiencia es la menos enganchada en la sala, eso dice algo del formato, no de ellos.

4. Parte la mañana en dos. El argumento de Paul Graham de 2009¹³ sigue en pie. Quien fabrica cosas necesita bloques largos y sin interrupciones, y una sola reunión en mitad de la mañana puede arruinar la mañana entera al partirla en dos trozos demasiado pequeños para hacer nada difícil. Un standup a las 10:30 es el ejemplo canónico. Y hay un coste anticipado: la gente evita empezar nada profundo en los 45 minutos previos.

5. Cambiar de tarea degrada el trabajo a los dos lados de la reunión. La investigación de Sophie Leroy introdujo el residuo atencional: cuando pasas de una tarea a otra, parte de tu atención se queda enganchada en la primera y tu rendimiento en la segunda se resiente.⁵ Un standup fuerza ese cambio dos veces por asistente, una al entrar y otra al salir.

6. Volver al trabajo cuesta tiempo de verdad. La investigación de Gloria Mark sobre interrupciones es el origen de la cifra tan citada de unos 23 minutos para retomar una tarea interrumpida, y su trabajo con Gudith y Klocke también encontró que la gente compensa las interrupciones trabajando más rápido, a costa de más estrés, más frustración y más carga percibida.⁶ Cita esta con cuidado. Es el número más maltratado de toda la conversación sobre productividad, y un manager que lo haya visto desmontado lo usará contra ti.

7. Los bloqueos se nombran, pero no se resuelven. Fíjate en esto en tu propio equipo. Alguien dice que está bloqueado, todo el mundo asiente, y la resolución de verdad llega cuarenta minutos después en un privado entre dos personas. Si ese es el patrón, la reunión no resolvió el bloqueo. Solo agendó la conversación que sí lo resolvió.

8. La carga de reuniones se acumula en el cuerpo. El Human Factors Lab de Microsoft midió con EEG a participantes en reuniones encadenadas y encontró marcadores de estrés que subían a lo largo de la secuencia, y pausas cortas que reducían esa acumulación.⁸ El trabajo de Steven Rogelberg sobre la ciencia de las reuniones documenta lo mismo desde el lado de las encuestas, junto con el tiempo que la gente pasa descomprimiendo después de una mala reunión, que se suma a la duración de la reunión en sí.⁷

9. No encaja con equipos distribuidos. Siempre hay alguien que lo pilla a mala hora. El manual de trabajo totalmente remoto de GitLab¹⁴ es el argumento público más completo a favor de llevar el estado en asíncrono, y es una referencia útil precisamente porque viene de una empresa que opera así a escala y no de un blog.

10. Una cadencia diaria cobra un precio diario, haya o no algo que coordinar. En equipos cuyo trabajo está poco acoplado, la necesidad real de coordinación es intermitente. La reunión fija paga de más todos los días tranquilos.

Parte 2: La contraevidencia, que deberías traer tú mismo

Entra con el caso en tu contra ya montado. Es la vía más rápida para que te tomen en serio, y evita que tu manager sienta que tiene que defender la reunión él solo.

Los standups, bien llevados, hacen tres cosas difíciles de sustituir.

Sacan los bloqueos pronto. Un problema que se plantea a las 09:30 y que de otro modo se habría comido un día entero ya justifica por sí solo los quince minutos. Esta es la función que tu recambio tiene que cubrir sí o sí.

Construyen una foto compartida de quién hace qué, y eso reduce el trabajo duplicado y el trabajo que se pisa. Stray y Dingsøyr lo documentan como uno de los beneficios reales que la gente reporta.²

Sostienen la seguridad psicológica. Rietze y Zacher encontraron una relación positiva entre los daily stand-ups y la seguridad psicológica, que a su vez se relacionaba con la satisfacción laboral y con la percepción de rendimiento del equipo.¹⁰ Eso se apoya en el trabajo fundacional de Edmondson, que conecta la seguridad psicológica con el comportamiento de aprendizaje del equipo.⁹ Un punto de contacto regular y de bajo riesgo hace algo por la confianza, sobre todo en equipos nuevos o distribuidos.

Así que concede el punto donde sea cierto. Si tu equipo es pequeño, está muy acoplado, es junior o tiene tres semanas de vida, el standup probablemente se está ganando lo que cuesta, y deberías decirlo.

Parte 3: Consigue tus propios datos antes de abrir la boca

Dos semanas. Tres cosas. Haz esto antes de la conversación, porque una opinión contra un ritual pierde y la aritmética contra un ritual no.

Mide la duración real, no la agendada. Cronométrala cada día. La mayoría de los equipos descubre que la reunión de 15 minutos es una reunión de 22.

Haz las cuentas de sueldo. Asistentes, por la duración real en horas, por los días laborables del año. Un equipo de ocho a 15 minutos de verdad son 2 horas-persona al día, unas 10 a la semana, unas 460 horas-persona al año. A un coste cargado de 60 euros la hora, eso son unos 27.000 euros, y esa cifra ni siquiera cuenta el tiempo de recuperación a cada lado. Usa los números de tu propio equipo para que nadie pueda discutir de dónde salen.

Cuenta los bloqueos. Durante diez días laborables, apunta cada bloqueo que se plantee en el standup y marca si se resolvió dentro de la reunión o en otro sitio después. Este suele ser el número que cierra el debate.

Pregunta al equipo de forma anónima. Una pregunta. ¿El standup te ayuda a hacer tu trabajo, sí o no, y por qué? El anonimato es lo que te da la respuesta de verdad, y además significa que hablas por el equipo y no por ti, lo que elimina el riesgo dos de la lista del principio.

Parte 4: Las palabras

Cuatro situaciones, cuatro guiones. Adapta los detalles, mantén la estructura, porque la estructura es la que hace el trabajo.

Todos siguen los mismos cuatro tiempos. Valida lo que la otra persona necesita de verdad. Nombra el coste en sus términos. Propón algo reversible y acotado en el tiempo. Ponte encima la carga de la prueba y el trabajo de montarlo.

A tu manager, en un uno a uno

“Quiero proteger el tiempo de foco del equipo sin que tú pierdas visibilidad, y tengo dos semanas de datos sobre cómo se está usando de verdad nuestro standup. Dura 22 minutos, no 15. Eso son unas 675 horas-persona al año entre los ocho. En diez días se plantearon seis bloqueos y solo uno se resolvió de verdad dentro de la reunión. El resto se solucionaron después por privado.

Me gustaría probar esto cuatro semanas. Actualizaciones escritas en un canal común antes de las 09:30 que puedas leer cuando quieras, un canal dedicado a bloqueos donde la gente te etiquete directamente en cuanto algo se atasque, y una sincronización en vivo a la semana. Yo hago el seguimiento del tiempo de resolución de bloqueos frente a lo que tenemos ahora. Si empeora, volvemos atrás y lo digo yo en la retro. Y lo monto todo yo.”

A tu scrum master

“He vuelto a leer la Guía de 2020. Define el Daily Scrum como un evento para los Developers, y eliminó las tres preguntas. El nuestro ha derivado hacia una ronda de actualizaciones dirigidas a quien tiene más galones en la sala, que es justo lo que la Guía intenta evitar.

¿Podríamos probar a hacerlo sobre el tablero en vez de en corro, durante un sprint, y preguntar después a los Developers si les ha resultado más útil?”

Fíjate en lo que hace esto. Le entrega la autoridad al framework en vez de a ti, y convierte a esa persona en quien restaura la práctica, no en quien defiende una versión rota.

A tus compañeros, antes de hacer nada más

“Sé sincero conmigo. ¿El standup te ayuda de verdad o es solo algo por lo que hay que pasar? Quiero plantearlo, y solo quiero hacerlo si hablo por el equipo y no por mí.”

Haz esto primero. Siempre. Si dos personas dicen que el standup es el único momento en que pueden pedir ayuda, tu propuesta tiene que conservar eso, y ahora lo sabes antes de haberte casado con una postura en público.

En una retrospectiva

“Hoy quiero inspeccionar una sola cosa. He medido nuestro standup durante dos semanas. Esto es lo que cuesta y estos son los bloqueos que resolvió de verdad. No estoy pidiendo que lo cancelemos. Estoy preguntando si cambiamos el formato durante un sprint y miramos los números antes de decidir nada permanente.”

Como propuesta escrita

Asunto: Experimento de cuatro semanas, standup asíncrono

Ahora mismo nuestro daily standup dura 22 minutos entre ocho personas, que son unas 675 horas-persona al año. En los últimos diez días laborables se plantearon seis bloqueos y uno se resolvió dentro de la reunión.

Propuesta, cuatro semanas, totalmente reversible:

Check-ins escritos en #team-standup antes de las 09:30, tres líneas cada uno. Progreso hacia el objetivo del sprint, foco de hoy, qué está bloqueado. Bloqueos etiquetados directamente a la persona que corresponda en cuanto aparecen, en vez de guardarlos hasta la mañana siguiente. Una sincronización en vivo de 30 minutos el lunes para la planificación y para todo lo que necesite conversación.

Yo hago el seguimiento del tiempo de resolución de bloqueos, del tiempo de ciclo y de un pulso de equipo corto, y llevo los tres a la retro del [fecha]. Si el tiempo de resolución de bloqueos empeora, revertimos. Yo configuro las herramientas y llevo la prueba.

La condición explícita de vuelta atrás es la línea más importante de ese mensaje. Es lo que convierte tu propuesta de un cambio en una prueba, y suele ser lo que se gana el sí.

Parte 5: Lo que te van a responder

“Necesito visibilidad sobre lo que hace cada uno.” Las actualizaciones escritas te dan más que una reunión. Se pueden buscar, se quedan ahí, y las puedes leer a las 07:00 o a las 19:00 en vez de tener que estar en una sala a las 09:30.

“Los bloqueos se van a quedar parados.” Al revés. Un bloqueo publicado en cuanto aparece recibe atención más rápido que uno guardado hasta la mañana siguiente. Esa es justo la métrica que propongo medir, y es la que me haría cancelar la prueba.

“Son solo quince minutos.” Son quince minutos por ocho personas, cada día laborable, más el tiempo que necesita cada uno para volver a lo que estaba haciendo. Aquí tienes la cifra anual.

“Scrum exige un Daily Scrum.” Scrum exige un Daily Scrum para los Developers, y la Guía de 2020 eliminó las tres preguntas que seguimos usando. Lo que hacemos no es lo que describe la Guía.¹

“El equipo va a perder cohesión.” Es un riesgo real, y por eso la sincronización semanal se queda. Además voy a medir un pulso de equipo durante la prueba, así que si la cohesión baja lo veremos en lugar de suponerlo.

Parte 6: Cinco maneras de perder esta discusión

Plantearlo como querer hacer menos. Eso confirma exactamente la sospecha con la que la otra persona ha entrado.

Cargarte la reunión sin nombrar un sustituto. El lío que viene después se te atribuye a ti personalmente, y con razón.

Decidirlo tú solo. Un ritual de equipo cambia por decisión de equipo o vuelve en menos de un mes.

Saltarte la prueba y las métricas, que es lo que convierte una propuesta comprobable en un concurso de opiniones contra el statu quo, y esos los gana el statu quo.

Ignorar a la gente para quien sí funciona. Si el junior del equipo depende de él, diseña pensando en esa persona y dilo en la sala. No te cuesta nada y elimina la objeción más fuerte antes de que alguien la plantee.

Parte 7: Qué lo sustituye

	Standup diario en vivo	Actualizaciones escritas en asíncrono	Sincronización semanal más canal de bloqueos
Coste en tiempo	Alto, escala con la plantilla	Coste síncrono casi nulo	Bajo
Coste de interrupción	Alto, diario, a media mañana	Mínimo, cada uno se lo agenda	Bajo, un solo punto fijo
Velocidad con los bloqueos	Hasta 24 horas de espera	Inmediata si se etiqueta	Inmediata si se etiqueta
Registro	Ninguno, salvo que alguien lo escriba	Buscable por defecto	Parcial
Funciona entre zonas horarias	Mal	Bien	Razonablemente
Cohesión	Buena si se hace bien	Débil por sí sola	Buena

Siete opciones, con su pega honesta al lado.

Check-ins escritos en asíncrono con un bot. Geekbot, Standuply o Range preguntan a cada persona y publican en un canal común.¹⁷ Funciona entre zonas horarias y deja un registro buscable. Puede degenerar en teatro de estado que nadie lee si nadie responde a lo que se publica.

Standups dos veces por semana. Mantiene la sincronización en vivo y recorta la frecuencia. Fácil de vender porque es un cambio pequeño. Necesita un canal de apoyo para lo urgente.

Recorrer el tablero en vez del corro. Repasa los elementos de trabajo de derecha a izquierda y habla de los tickets, no de las personas. Mata al instante la dinámica de informe personal. Solo funciona si el tablero está de verdad al día.

Un canal dedicado a bloqueos. La pieza de más valor y la más barata de añadir. Exige la disciplina de publicar, y a alguien que lo mire.

Pairing a demanda. La resolución más rápida posible, sin público. Reduce la visibilidad para todo el equipo, así que necesita dejar rastro escrito.

Una sincronización semanal profunda. Espacio para las conversaciones que una reunión de 15 minutos no puede sostener. Demasiado poco frecuente para funcionar sola.

Días sin reuniones. La purga de calendario de Shopify en 2023 es el ejemplo corporativo más citado, del que se informó que dejó fuera del calendario de la empresa miles de reuniones recurrentes.¹⁵ Esto es una política de foco, no un mecanismo de coordinación, así que hay que combinarla con alguna de las anteriores.

La combinación que más veces funciona: actualizaciones escritas para el día a día, un canal de bloqueos para lo urgente, y una sincronización en vivo a la semana para el resto.

Parte 8: Diseñar la prueba para que sobreviva al contacto con una retro

Elige tus métricas de éxito antes de empezar, y elige unas en las que tu manager ya crea.

Entrega. Una medida tipo DORA, normalmente lead time for changes o frecuencia de despliegue.¹² El tiempo de ciclo sirve si no desplegáis a menudo.

Tiempo de resolución de bloqueos. Tu salvaguarda sobre el riesgo principal. Esta es la métrica que debería poder matar el experimento, y decirlo en voz alta es lo que hace que el experimento sea creíble.

Pulso del equipo. Una pregunta, semanal, anónima. Esto encaja con la dimensión de satisfacción del framework SPACE, que existe precisamente porque medir la productividad con una sola métrica sale mal.¹¹ Sin eso puedes mejorar el ritmo de entrega mientras quemas a la gente en silencio y no enterarte nunca.

Cuatro semanas es la duración correcta. Dos son demasiado poco para ver nada más allá de la novedad. Ocho son suficientes para que volver atrás empiece a parecer un fracaso público, y eso hace que la gente defienda la prueba en vez de leerla con honestidad.

La parte que sí es difícil

Todo lo de arriba está al alcance de cualquiera que dedique una tarde a leer. La mayoría de la gente que lo necesita seguirá sin enviar el mensaje.

Lo que falta no son los datos. Lo que falta es una versión de la frase que diga que la reunión no funciona sin dar a entender que la persona que la lleva no funciona, y eso es mucho más difícil de escribir que una lista de citas. Se reescribe seis veces en la caja de borrador de Slack y luego se abandona.

Ese hueco es la razón por la que hacemos Subtext. La mayoría de los mensajes que la gente no consigue enviar no son complicados de contenido. Son mensajes en los que tener razón no basta, y las palabras cargan con todo el riesgo. Una propuesta sobre el standup es de las pequeñas. La misma forma aparece al pedir un aumento, al rechazar más alcance, al decirle a un fundador que la hoja de ruta está mal y al decirle que no a un amigo.

Si te llevas una sola cosa de aquí: envía el mensaje con la condición de vuelta atrás dentro. “Si el tiempo de resolución de bloqueos empeora, volvemos atrás y lo digo yo.” Esa única frase elimina el motivo que tenía cualquiera para decirte que no.

Una nota sobre los números que he dejado fuera

Varias cifras circulan mucho sobre este tema y no podía respaldarlas, así que no están en el texto de arriba.

La afirmación de que el 80% de los desarrolladores señala las actualizaciones irrelevantes como su mayor frustración con el standup no aparece en la encuesta de Stray a la que se le suele atribuir. La afirmación de que el 80% de las tareas acordadas en reuniones no se completan nunca viaja sin fuente. La estadística tan citada del “40% más de tiempo y 50% más de errores”, atribuida a un artículo reciente del Journal of Experimental Psychology, parece ser una versión deformada de Rubinstein, Meyer y Evans en 2001, que midió cambio de tarea en laboratorio y no se extiende sin más a una reunión de por la mañana.¹⁸ Las distintas cifras anuales en dólares por equipo por tiempo de reunión desperdiciado dependen por completo de los supuestos que hay detrás, y por eso la aritmética de la Parte 3 usa los datos de tu propio equipo.

Una laguna más, con honestidad. No he encontrado ningún estudio controlado riguroso que compare directamente las actualizaciones de estado escritas en asíncrono con las reuniones de estado síncronas en cuanto a resultados de entrega. GitLab, Doist y Basecamp defienden la versión escrita, y los tres tienen una posición que defender. Si tu manager pide esa comparación, la respuesta honesta es que parece que todavía no existe, y que tu prueba de cuatro semanas es la forma de generarla para tu propio equipo.

¿Crees que vuestro standup se gana lo que cuesta, o que he leído mal la evidencia? Cuéntamelo en LinkedIn.

Samet Durgun es cofundador de Subtext, una app que capta el tono emocional de tus mensajes y los reescribe con tu propia voz. Vive en Berlín.

Fuentes

Cada enlace de arriba lleva a la fuente primaria cuando existe.

The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. El documento más útil que hay para este argumento. Lee la sección del Daily Scrum directamente y cítala literalmente. Establece que el evento es para los Developers, que dura 15 minutos y que las tres preguntas se eliminaron en la revisión 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. Con revisión por pares. Documenta tanto el valor (compartir información, resolver problemas en común) como los modos de fallo (informe de estado a un manager, exceso de frecuencia y de duración). Este mándaselo a un 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. Encuesta a desarrolladores profesionales. Entre las cifras publicadas está que el 87% de los equipos ágiles hace standups diarios, con valoraciones medias cercanas a lo neutro, los junior más positivos y los senior y los equipos grandes menos. He usado el sentido del hallazgo y no el porcentaje.
Stray, V. and Moe, N. B., practitioner writing in IEEE Software on adapting daily stand-up practice. Defiende que los rituales rígidos de standup deberían adaptarse al equipo en vez de seguirse por defecto. El título y el año exactos no están confirmados, y la versión que circula por internet incluye números de participantes que no he podido confirmar.
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. El origen del residuo atencional. Evidencia sólida, fuera del mundo ágil, de que cambiar de tarea degrada la calidad de lo que viene después.
Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. Y Mark, G. (2023). Attention Span. Hanover Square Press. Origen de los hallazgos sobre trabajo interrumpido y de la cifra de unos 23 minutos para retomarlo que circula por todas partes. La cifra es real, pero se cita con más precisión de la que sostiene la investigación de base, así que cita el trabajo original y formúlalo como “más de 20 minutos”.
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. La referencia estándar sobre el desperdicio de las reuniones y la recuperación posterior. He usado el hallazgo cualitativo en vez de un porcentaje concreto, porque los números varían según la encuesta.
Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. Evidencia fisiológica de que el estrés se acumula a lo largo de reuniones consecutivas y de que las pausas lo reducen. Útil porque es medición y no encuesta.
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. La cita fundacional sobre seguridad psicológica. Habla de equipos en general y no de standups en concreto, así que no le atribuyas una relación causal que no tiene.
Rietze, S. and Zacher, H., research on daily stand-up meetings, psychological safety, work satisfaction and team performance perceptions, European Journal of Work and Organizational Psychology. El argumento publicado más fuerte a favor de los standups, que es exactamente por lo que deberías traerlo tú. El año de publicación no está confirmado; la versión que circula da una fecha de 2025 que no he podido confirmar.
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. De lectura libre. Usa la dimensión de satisfacción y bienestar para justificar que midas un pulso de equipo junto a las métricas de entrega.
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. Origen de las cuatro métricas de entrega de DORA. Usa una de ellas como medida de ritmo para que la métrica sea defendible y no inventada para la ocasión.
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Corto, gratis, y lo más persuasivo que puedes reenviarle a un compañero que aún no lo tiene claro.
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. Una organización grande operando en público con actualizaciones de estado asíncronas. Prueba de que el modelo funciona a escala, aunque GitLab tenga interés en el argumento.
Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. Se informó de que eliminó miles de reuniones recurrentes del calendario de la empresa y de que prohibió las reuniones recurrentes de más de dos personas los miércoles. La cifra concreta de horas recuperadas viene de la propia empresa, así que atribúyesela a Shopify en vez de darla como hecho medido.
Atlassian Agile Coach, standup guidance. Guía del sector que recomienda mantener los standups breves y adaptarlos a las necesidades del equipo, formatos asíncronos incluidos. Útil porque viene de una fuente en la que tu manager ya confía en materia de práctica ágil.
Herramientas: Geekbot y Standuply para standups asíncronos en Slack y Teams, Range para check-ins de equipo. Verifica el precio actual y el estado del producto antes de recomendar uno 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. El origen real de la afirmación de que el cambio de tarea se lleva “hasta el 40% del tiempo productivo”. Lo pongo aquí para que puedas comprobarlo tú en vez de repetir la versión deformada.