Death march
It should not be confused with a demanding period or a critical delivery. A death march is characterized by a structural imbalance: the plan does not fit reality, warning signs are ignored, and the human or technical cost is treated as acceptable collateral damage.
Origin and context
The expression became popular in software development following Edward Yourdon's book Death March, which describes projects with constraints so severe that their participants can barely survive them professionally, let alone complete them with quality.
In agile environments, a death march directly contradicts the principle of sustainable pace. Agility is not about always going faster, but about maintaining a flow of value delivery that can be sustained over time without destroying the team's quality, motivation, or capacity to learn.
Signs of a death march
An initiative starts to look like a death march when several of these signs pile up:
- The delivery date is fixed, but the scope is not negotiable.
- Estimates are treated as a firm commitment, not as planning hypotheses.
- The usual response to any deviation is to ask for more hours.
- The team communicates risks, but the organization does not change priorities, scope, or expectations.
- Quality is cut to meet deadlines: less testing, less review, less useful documentation, more technical debt.
- Urgent work systematically displaces important work.
- Morale drops, and it becomes normal for the team to work while exhausted, anxious, or feeling powerless.
- Progress indicators hide the problem: many tasks are "almost done," but there is little truly usable increment.
- People stop raising impediments because they feel that doing so changes nothing.
A death march does not always stem from bad intentions. It often arises from naive optimism, commercial pressure, political commitments, lack of technical knowledge, overconfidence, or an inability to say "no" in time.
Relationship with agility
Scrum and other agile approaches reduce the risk of a death march when used with sound judgement: frequent deliveries, inspection, adaptation, prioritization, and continuous conversation make it possible to detect early on that the plan does not fit reality.
But death marches can also happen with agile vocabulary. This occurs when sprints, dailies, and boards are kept in place but are used to push more work than the system can absorb. In that case, agile practices stop protecting the team and become a more sophisticated form of pressure.
To avoid this, the team and the organization must treat scope, deadline, and quality as explicit decision variables. If a significant deviation arises, the healthy options are to renegotiate scope, split the goal, change priorities, add realistic capacity, or accept a different date. What does not work is keeping all the constraints in place and shifting the cost onto the team.
Practical example
A team has six weeks to launch a critical new feature. During planning, it becomes clear that the actual scope includes integration with three external systems, data migration, interface changes, security testing, and training for the support team.
The team warns that the goal cannot fit within the timeframe at the expected level of quality. Management replies that "we have to make it no matter what" because the date has already been announced to the market. Over the following weeks, working days get longer, testing is postponed, half-finished tasks pile up, and the review of technical debt is put off.
Even if the team manages to release something, the project has already fallen into death march dynamics: delivery is sustained by sacrificing quality, trust, and sustainability. The agile alternative would have been to reduce the scope to a useful first version, validate the value with real users, and maintain a transparent plan for its evolution.
Death March and AI
At Scrum Manager, AI should be understood as technology at the service of people, not as a substitute for professional judgement or as an excuse to force unsustainable paces. If the team ends up working at the pace set by the tool, instead of using the tool to improve its delivery capacity, the organization drifts away from agility.
To avoid AI-assisted death marches, it is advisable to:
- Explicitly estimate the tasks for reviewing and integrating AI-generated outputs.
- Do not consider an AI-assisted increment done until it meets a reinforced Definition of Done.
- Distinguish between quick prototypes for learning and robust production code.
- Maintain verifiable acceptance criteria.
- Check whether AI is reducing bottlenecks or simply shifting them toward review, integration, or support.
- Ensure that an accountable person validates the result before it is put into production.
Common mistake
Resources
📄 Scrum Master v.4.0Free download · Scrum Manager
📄 AgiLevel v.5.0Free download · Scrum Manager
📄 Scrum en equipos con IA [Scrum in Teams with AI, in Spanish]Free download · Scrum Manager
📄 Estimaciones ágiles, métricas de productividad, #NoEstimates y otros animales [Agile Estimates, Productivity Metrics, #NoEstimates, and Other Animals, in Spanish]Scrum Manager Blog · Dec 2019
References
- Beck, Kent et al. (2001). "Principles behind the Agile Manifesto". AgileManifesto.org.
- DeMarco, Tom; Lister, Tim. (2013). Peopleware: Productive Projects and Teams (3rd ed.). Addison-Wesley.
- Schwaber, Ken; Sutherland, Jeff. (2020). The Scrum Guide. ScrumGuides.org.
- Yourdon, Edward. (2004). Death March: The Complete Software Developer’s Guide to Surviving "Mission Impossible" Projects (2nd ed.). Prentice Hall Professional.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.