Death March

I read Death March over the weekend.  There were some interesting points about  Death March projects:

·         There are a number of good, in fact, necessary reasons to work on Death March project.

·         The fact that the software industry employs many young people who have both the time and energy to work on a Death March project

·         The absolute necessity to get away from the overall bureaucracy when working on a Death March project – esp the methodology police, the physical plant police, etc..

·         The importance of negotiation in the project –esp with the stakeholders

·         The law of diminishing returns – after a certain point the overtime that is put in works to the detriment to the code base and the overall project. 

·         The team is critical – you need people who can and like to work together

·         I liked his suggestions to separate the team: “skunk works”, telecommute, and graveyard shift are all good ways to give the team a physical separation they need from the normal bureaucracy.

·         The most important point of the book: Triage.  All external constraints need to be filtered before they get to the project (including requirements!)   I liked his 80/20 rule – 20 of the “required” functionality will not be delivered, so triage to filter it out early.  The project will still be considered a success.

·         One more interesting point: the author seems to embrace XP (and many of the processes in Agile like daily/continuous builds, etc…) to solve Death March problems.  After reading this book, I would agree with him.