Death March, Second Edition by Edward Yourdon is an interesting study of high-risk software projects, which would normally be expected to fail - author defines a death march as a project for which an unbiased risk of failure is greater than 50%.
The books starts by exploring death march project concepts, introducing various causes and reasons why people would join them. After looking at such projects from a very personal perspective of an individual member, the author then presents several other viewpoints - from the perspective of corporate politics and from the perspective of other people involved in the death march team.
Primary audience of this book are project managers, and they will benefit from ideas and techniques aimed to identify key players, decide whether corporate politics allow any chance of success for the project, how to negotiate the project so that it does not become a ‘suicide’, how to build a team for an imminent death march and how to prevent team self-destruction.
For the development, rather then advocating any single methodology, the author provides a list of pragmatic tools and techniques and references to some best/worst practices for death march projects collected by other researchers, such as feature triage, prioritisation, ‘good enough’ software and avoiding methodology police. Software development methodologies are discussed mostly in terms of the role they play in helping or sabotaging a death march project - with a very interesting comment on how insisting on methodology can turn a normal project into a death march. The second edition of this book was published in 2004, and includes a comparison between techniques used to get death marches back on track and agile methodologies that emerged between two editions. The book as a whole can be even seen as a great case for agile software development, as XP does a good job of minimising some risks that lead to a death march project, and there are a lot of similarities between proposed death-march best practices and XP principles.
Although my personal experiences are different from one of the key ideas of the book, that ‘death march projects are the norm, not the exception’, I recognised several of my projects in the descriptions of ‘mission impossible’ and ‘ugly’. Death March is quite a thought-provoker, and it made me revisit my own dark experiences, thinking about what we did and how we did it, why projects succeeded and failed, where we were wrong and how not to do it again. Case studies in this book discuss problems common in software development (though typically not so extreme, as ‘stakes are higher and emotions stronger than in normal projects’), so the proposed solutions are a good starting point for ideas that can be applied to improve typical projects.
The book has 225 pages, filled with interesting ideas, stories and quotes. Thanks to it’s unique form, it provides readers with several viewpoints on best practices and explanations - most chapters are followed by a list of e-mail excerpts that offer greater insights and clarifications. Reference sections of most similar books can safely be skipped, but I suggest reading these carefully, as quite a few contain hidden gems.
Although it is aimed mostly at project managers, ‘Death March’ should prove to be an interesting read for a broader audience, and I strongly suggest it to all mid-level and senior-level software workers, regardless of what they exactly do in the industry. Key lessons to be learned from Death March are equally important to developers, testers and project managers - especially how to notice that you are being dragged into a death march, how to make a rational decision whether to get involved, what you can do to get out and how to survive it, should you decide to stay or cannot escape.
