Marcha fúnebre
Una marcha fúnebre —death march en inglés— es un proyecto o iniciativa que sigue adelante aunque sus condiciones hacen muy improbable entregar valor de forma sana y realista. Suele aparecer cuando el alcance, la fecha, el presupuesto o la capacidad del equipo son incompatibles entre sí, pero la organización actúa como si el problema pudiera resolverse con más presión.
No debe confundirse con un periodo exigente ni con una entrega crítica. La marcha fúnebre se caracteriza porque el desequilibrio es estructural: el plan no encaja con la realidad, las señales de alarma se ignoran y el coste humano o técnico se trata como un daño colateral aceptable.
Origen y contexto
La expresión se popularizó en el ámbito del desarrollo de software a partir del libro Death March, de Edward Yourdon, donde se describen proyectos con restricciones tan severas que sus participantes apenas pueden sobrevivir profesionalmente a ellos, y mucho menos completarlos con calidad.
En entornos ágiles, la marcha fúnebre contradice directamente el principio de ritmo sostenible. La agilidad no consiste en ir siempre más rápido, sino en mantener un flujo de entrega de valor que pueda sostenerse en el tiempo sin destruir la calidad, la motivación ni la capacidad de aprendizaje del equipo.
Señales de una marcha fúnebre
Una iniciativa empieza a parecerse a una marcha fúnebre cuando se acumulan varias de estas señales:
- La fecha de entrega es fija, pero el alcance no se negocia.
- Las estimaciones se usan como compromiso cerrado, no como hipótesis de planificación.
- La solución habitual ante cualquier desviación es pedir más horas.
- El equipo comunica riesgos, pero la organización no modifica prioridades, alcance ni expectativas.
- Se recorta calidad para cumplir plazos: menos pruebas, menos revisión, menos documentación útil, más deuda técnica.
- El trabajo urgente desplaza sistemáticamente al trabajo importante.
- La moral cae y se normaliza que el equipo trabaje con cansancio, ansiedad o sensación de impotencia.
- Los indicadores de avance ocultan el problema: muchas tareas “casi terminadas”, pero poco incremento realmente usable.
- Las personas dejan de levantar impedimentos porque perciben que hacerlo no cambia nada.
Una marcha fúnebre no siempre nace de una mala intención. A menudo surge de optimismo ingenuo, presión comercial, compromisos políticos, desconocimiento técnico, exceso de confianza o incapacidad para decir “no” a tiempo.
Relación con la agilidad
Scrum y otros enfoques ágiles reducen el riesgo de marcha fúnebre cuando se usan con criterio: entregas frecuentes, inspección, adaptación, priorización y conversación continua permiten detectar pronto que el plan no encaja con la realidad.
Pero también puede haber marchas fúnebres con vocabulario ágil. Ocurre cuando se mantienen sprints, dailies y tableros, pero se usan para empujar más trabajo del que el sistema puede absorber. En ese caso, las prácticas ágiles dejan de proteger al equipo y se convierten en una forma más sofisticada de presión.
Para evitarlo, el equipo y la organización deben tratar el alcance, el plazo y la calidad como variables de decisión explícitas. Si aparece una desviación relevante, las opciones sanas son renegociar alcance, dividir el objetivo, cambiar prioridades, añadir capacidad realista o aceptar una fecha distinta. Lo que no funciona es mantener todas las restricciones y trasladar el coste al equipo.
Ejemplo práctico
Un equipo tiene seis semanas para lanzar una nueva funcionalidad crítica. Durante la planificación se detecta que el alcance real incluye integración con tres sistemas externos, migración de datos, cambios de interfaz, pruebas de seguridad y formación a soporte.
El equipo advierte de que el objetivo no cabe en el plazo con la calidad esperada. La dirección responde que “hay que llegar como sea” porque ya se ha anunciado la fecha al mercado. Durante las siguientes semanas se alargan jornadas, se aplazan pruebas, se acumulan tareas a medio cerrar y se pospone la revisión de deuda técnica.
Aunque el equipo llegue a publicar algo, el proyecto ya ha entrado en dinámica de marcha fúnebre: la entrega se sostiene sacrificando calidad, confianza y sostenibilidad. La alternativa ágil habría sido reducir el alcance a una primera versión útil, validar el valor con usuarios reales y mantener un plan transparente de evolución.
Marcha fúnebre e IA
En Scrum Manager, la IA debe entenderse como tecnología al servicio de las personas, no como sustituto del criterio profesional ni como excusa para forzar ritmos insostenibles. Si el equipo acaba trabajando al ritmo que impone la herramienta, en lugar de usar la herramienta para mejorar su capacidad de entrega, la organización se aleja de la agilidad.
Para evitar marchas fúnebres asistidas por IA conviene:
- Estimar explícitamente las tareas de revisión e integración de outputs generados por IA.
- No considerar terminado un incremento con IA hasta que cumpla una Definition of Done reforzada.
- Distinguir entre prototipos rápidos para aprender y código robusto para producción.
- Mantener criterios de aceptación verificables.
- Revisar si la IA está reduciendo cuellos de botella o simplemente desplazándolos hacia revisión, integración o soporte.
- Asegurar que una persona responsable valida el resultado antes de ponerlo en producción.
Error frecuente
Recursos
Referencias
Yourdon, Edward. (2004). Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects (2.ª ed.). Prentice Hall Professional.
Beck, Kent et al. (2001). “Principles behind the Agile Manifesto”. AgileManifesto.org.
Schwaber, Ken; Sutherland, Jeff. (2020). The Scrum Guide. ScrumGuides.org.
DeMarco, Tom; Lister, Tim. (2013). Peopleware: Productive Projects and Teams (3.ª ed.). Addison-Wesley.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.