Systems Thinking Radar - Vol. 6
Deadlines: ¿herramienta o trampa? MECE framework. Caso real de aplicación de lean.
🧐 Un paper
Deadlines: ¿herramienta o trampa?
Hace un par de meses leía en la newsletter de Steve Stewart-Williams sobre una investigación titulada «On time or on thin ice: How deadline violations negatively affect perceived work quality and worker evaluations» (A tiempo o en la cuerda floja: Cómo las violaciones de plazos afectan negativamente la percepción de la calidad del trabajo y las evaluaciones de los trabajadores).
Los «deadlines» son una característica común en el entorno laboral moderno. Aunque investigaciones previas se han centrado en cómo los plazos influyen en el comportamiento de quienes completan las tareas, se sabe poco sobre cómo los plazos afectan el juicio de quienes evalúan el trabajo entregado.
A través de ocho experimentos de laboratorio y campo, complementados con 10 estudios adicionales (N = 6,982), los resultados indican que:
No cumplir con los plazos disminuye la confianza en la competencia del trabajador.
Esto afecta negativamente tanto la evaluación del trabajador como la percepción de la calidad del trabajo entregado.
En contraste, entregar temprano no confiere ningún beneficio adicional.
Este estudio me llevó a reflexionar sobre cómo usamos los deadlines en el desarrollo de software y a conectar con otros debates relacionados.
Fake deadlines
Poco después, leía en
, Using fake deadlines without driving your engineers crazy, entrega que me generó sentimientos encontrados. Esta táctica de «fake deadlines» como herramienta para motivar me recordó un viejo post de DHH: Remove the stress. Pick a deadline. Uno de los comentarios de un tal Jim, captura muy bien una perspectiva alternativa con la que estoy más alineado:Prefiero «release date» en lugar de «deadline». «Release» genera impulso, sensación de alegría y progreso. «Deadline» crea la sensación de «estás muerto si no lo terminas a tiempo».
Este contraste lingüístico no es trivial. Cambiar el término puede influir en cómo los equipos perciben el trabajo y sus objetivos, pasando de una narrativa de presión a una de progreso.
Siempre listos para entregar
Mi libro de cabecera para estos asuntos es The Nature of Software Development de Ron Jeffries. En apenas un párrafo Jeffries articula una solución pragmática a los problemas asociados con los deadlines rígidos:
Aquí hay una mejor manera: establece un presupuesto de tiempo y dinero; produce primero las funcionalidades más valiosas; mantén el producto listo para entregarse en cualquier momento, y detente cuando se acabe el tiempo. Es muy probable que incluso nos detengamos antes de que llegue el plazo, porque ya habremos completado lo importante. Entregamos la mayor parte del valor en mucho menos tiempo y con mucho menos dinero.
En Audiense hace años que adoptamos un principio similar: Always Ready to Ship. En lugar de deadlines, utilizamos las fechas como referencias tentativas. Nos enfocamos en desarrollar lo que aporta más valor y evaluamos si estamos listos para lanzarlo cuando el momento llega.
Deadlines reales
Como expliqué en mi analogía del triángulo de hierro del ajedrez, todo proyecto tiene tres restricciones principales: recursos, alcance y tiempo. Si el tiempo está fijado (como ocurre con los deadlines), al menos una de las otras restricciones debe ser flexible.
Cuando los deadlines son reales y no negociables, como propone Edu Ferro en Deadlines and commitments… the fallacy, los tratamos como información valiosa. Esto nos ayuda a tomar decisiones informadas: priorizamos tareas y posponemos decisiones menos críticas, enfocándonos en entregar el mejor resultado posible dentro de las restricciones.
Los plazos reales son el contexto que debería ayudar al equipo a tomar decisiones, y es esencial que el equipo los conozca, comprenda su importancia y utilice esta información para entregar el mejor resultado posible dentro de ese plazo.
Rompiendo el círculo vicioso de los deadlines
Desde una perspectiva sistémica, los deadlines rígidos y las estimaciones pueden generar bucles de retroalimentación negativa. Las organizaciones que penalizan los retrasos, directa o indirectamente, priorizan la entrega a tiempo sobre prácticas fundamentales como el refactoring o las pruebas automatizadas. Esto perpetúa ciclos de estrés y burnout, afectando tanto la calidad del producto como la innovación.
Algunas ideas para romper este ciclo:
Medir el flujo, no los plazos: En lugar de estimar, enfócate en métricas como el cycle time para mejorar la capacidad del equipo.
Priorización continua: Concéntrate en maximizar el valor entregado, dejando que el tiempo necesario sea el adecuado para mantener la calidad.
Diseño antifrágil: Crea sistemas y equipos que puedan adaptarse a la variabilidad inherente del desarrollo de software.
En resumen
Los deadlines deben ser usados con cuidado. Adoptemos prácticas que respeten la complejidad de nuestro trabajo y promuevan sistemas más adaptativos, humanos y efectivos. Como propone Dan North, debemos abandonar la búsqueda obsesiva de un «destino final» en proyectos complejos. En su lugar, centrémonos en un progreso iterativo, priorizando la entrega de valor y ajustando continuamente las expectativas, permitiendo que los equipos se adapten al cambio de manera sostenible y sin la presión innecesaria de un alcance rígido o metas inalcanzables.
Los deadlines y su prima las estimaciones son temas complejos sobre lo que me gustaría escribir un ensayo más extenso. De momento os dejo estos diferentes puntos de vista para que cada cual vaya formando su opinión. Opinión que me vendría bien que compartáis.
Lecturas recomendadas:
On time or on thin ice: How deadline violations negatively affect perceived work quality and worker evaluations — David Fang y Sam Maglio
The Nature of Software Development — Ron Jeffries
Deadlines and commitments… the fallacy — Edu Ferro
Are We Nearly There Yet? — Dan North
Making the Date — Ron Jeffries
The Planning Fallacy — Wikipedia
Estimation Is Evil: Overcoming the Estimation Obsession — Ron Jeffries
The NoEstimates Movement — Ron Jeffries
Deadline Defense — Ron Jeffries
McGregor's Theory X and Theory Y — Wikipedia
🛠️ Un framework
MECE Framework
Estás de guardia. Te suena el móvil a las 3 a. m. y recibes una alarma: el formulario de registro de tu producto no está funcionando. Tu equipo está perdiendo deals.
Sigues todos los protocolos, runbooks y buenas prácticas disponibles, pero ninguna acción logra estabilizar el sistema. Toca pedir ayuda y comenzar un análisis más profundo para encontrar la causa raíz del problema.
Tu primer instinto es formular hipótesis de manera desordenada y comenzar a investigarlas de forma reactiva:
¿Han actualizado alguna librería de terceros?
¿Está el sistema bajo un ataque?
¿Existen otros problemas subyacentes?
¿Qué problemas tiene este enfoque? Podrías estar dejando fuera posibles causas debido a que estás pensando a un nivel de abstracción incorrecto (demasiado alto o demasiado bajo) o ignorando categorías completas de problemas. Además, podría suceder que algunas causas no sean mutuamente excluyentes, y la solución de una podría impactar a otra.
Aquí es donde el MECE Framework (Mutually Exclusive, Collectively Exhaustive) entra en juego y nos puede ayudar a abordar estas situaciones de manera estructurada.
Esta metodología fue desarrollada originalmente por McKinsey & Company para categorizar y descomponer problemas de manera que sean:
Mutually Exclusive (Mutuamente Excluyentes): Cada categoría o causa identificada debe ser única y no solaparse con otras.
Collectively Exhaustive (Colectivamente Exhaustivas): La suma de todas las categorías debe cubrir todas las posibilidades, asegurando que no se queden áreas sin explorar.
En este ejemplo de incidente, podrías haber aplicado MECE creando un árbol de decisión asegurándote de que las posibles causas estén divididas en categorías claras y no solapadas (Mutuamente Excluyentes), como se muestra en el árbol.
Iterativamente revisamos el árbol para asegurarnos de que todas las posibles causas pertenezcan a una de estas categorías (Colectivamente Exhaustivas). Esto asegura que no dejamos puntos ciegos en nuestro análisis.
Con esta estructura clara, puedes priorizar las categorías más probables según el contexto y asignar tareas a diferentes miembros del equipo para abordar las categorías en paralelo. Así evitamos pisarnos y garantizamos que todas las hipótesis se exploren de manera eficiente.
Otras aplicaciones
Otro ejemplo es su uso en la generación de árboles de oportunidades (opportunity trees), una herramienta propuesta por Teresa Torres que ya hemos comentado por aquí. En este contexto:
Mutuamente Excluyentes: Tener oportunidades bien definidas y sin solapamientos permite que el equipo aborde oportunidades en paralelo sin pisarse.
Colectivamente Exhaustivas: Asegurar que todas las oportunidades posibles se consideren minimiza el riesgo de pasar por alto soluciones potenciales.
Fue en este artículo de Torsten Walbaum donde descubrí que este framework, aunque parezca trivial, tiene muchísimas aplicaciones, como:
Entrevistas:
Ejemplo: “Hay cuatro formas principales de mejorar el rendimiento del sistema: A, B, C y D. Podemos descartar A y B porque no son factibles bajo las restricciones. Entre las opciones restantes, C es la más prometedora por [razón], por lo que enfocaré mi respuesta en esta opción.”
Al dar actualizaciones de investigación:
Ejemplo: “Estamos seguros de que encontraremos la causa raíz para finales de la semana. Primero, hemos descartado que sea un problema de datos o estacionalidad; en otras palabras, sabemos que hay un problema real con los registros. Luego, hemos reducido el problema solo a usuarios de iOS; como paso final, solo necesitamos averiguar qué paso del flujo de iOS está roto.”
Al explicar un proceso o parte de un sistema:
Ejemplo: “Los leads se agregan desde cuatro fuentes a nuestro sistema: Se ingresan de uno de tres proveedores de datos o se agregan manualmente mediante una carga CSV. Dado que el 95 % del volumen proviene del proveedor de datos A, me centraré principalmente en este flujo…”
Al proponer ideas durante la planificación:
Ejemplo: “Si queremos aumentar los ingresos por publicidad, tenemos tres opciones como empresa: Podemos aumentar el compromiso de los usuarios, incrementar la carga publicitaria o mejorar los CPM. El compromiso lo gestiona otro equipo y ya incrementamos la carga publicitaria agresivamente el último trimestre, por lo que recomiendo enfocarnos en los CPM. Una victoria rápida podría ser habilitar anuncios en video en Android.”
🎥 Una Charla
Mejor con un equipo de 25: por qué y trucos para conseguirlo
Alex Fernández resume en menos de una hora la magia de trabajar en un entorno con equipos de producto realmente empoderados y con una mentalidad lean.
El título de la charla despista un poco, casi me la salto porque no consideraba el tamaño del equipo como un problema a resolver y, sin contexto, 25 me parecía un número demasiado grande como para encontrar una «bala de plata» que lo hiciera funcionar.
Pero en la charla eso es lo de menos. Alex describe el flujo y las metodologías de trabajo en Cooltra y presenta un caso real de aplicación de muchos de los principios de Lean, eXtreme Programming y DevOps.
Aquí te listo algunas de las prácticas clave que han contribuido a su éxito de la transformación de su equipo, pero te recomiendo que las veas en el contexto de la charla:
Olvidarse de dogmas sobre el tamaño del equipo
No seguir reglas arbitrarias como «el equipo debe ser del tamaño de dos pizzas».
El tamaño ideal depende de la estructura y los procesos de la empresa.
Trunk-Based Development en lugar de Feature Branching
Desarrollar en una única rama principal en lugar de múltiples ramas largas.
Evita conflictos de integración y acelera el flujo de trabajo.
Un único objetivo a nivel de empresa
Todos los equipos deben estar alineados en una única meta clara.
Evita dispersión y conflictos entre equipos.
Ciclos de feedback rápidos
Minimizar handovers y validaciones innecesarias.
Detectar errores y corregirlos en el menor tiempo posible.
Equipos cross-funcionales de verdad
Me encantó la metáfora de los cromos de fútbol para ilustrar la mentalidad T-shaped.
No se trata solo de mezclar roles, sino de que todos comprendan el valor del producto.
Evitar la fragmentación entre «negocio» y «técnico».
Cost of Delay: priorización basada en impacto
Priorizar tareas según el valor que aportan y el tiempo que requieren.
Reducir el impacto de retrasos en decisiones y desarrollos.
«Sé vago» → Máximo impacto con el mínimo esfuerzo
Limitar el WIP (Work in Progress).
Hacer el challenge del 3 amigos tradicional de negocio + dev + QA.
No hacer tareas innecesarias.
Buscar siempre la solución más simple y efectiva.
Todos deben entender la economía del negocio
Compartir costos y métricas clave con todo el equipo.
Facilita la toma de decisiones alineadas con el negocio.
Estructura clara de comunicación en Slack
Canales diferenciados para temas técnicos, decisiones de producto y noticias importantes.
Evita la sobrecarga de información y la pérdida de mensajes clave.
Decisiones documentadas y estructuradas
Seguir una jerarquía clara de validación y documentación (por ejemplo, ADRs).
Permite tomar decisiones más informadas y evita repetir errores.
Uso de OpenTelemetry u otras herramientas de observabilidad
Registrar métricas clave para entender el impacto de cambios en tecnología y negocio.
Facilita el diagnóstico de problemas.
Distribuir tareas de mantenimiento del equipo
Rotar responsabilidades en retrospectivas, documentación y otros procesos clave.
Evita que ciertas personas se quemen con trabajo invisible.
No meter jefes intermedios innecesarios
Agregar capas de gestión solo cuando realmente aportan valor.
Evitar burocracia y cuellos de botella en la toma de decisiones.
Esto es todo por hoy. Me encantaría que dejaras en los comentarios qué te ha parecido esta entrega y compartieras ideas sobre los temas que te gustaría ver en las próximas ediciones.
¡No olvides suscribirte para no perdértelas!