Death
Except in rare cases, I think every project death should be a homicide. A project should die when we decide it should. Perhaps it no longer makes sense. Maybe something else makes more sense. Best of all, the team just might have produced “enough” of a system to be useful, and everybody using it realizes that's really all they need after all.
In Extreme Programming Explained, Kent Beck describes how projects should die:
If the customer can't come up with any new stories [i.e., requirements], then it is time to put the system into mothballs….the system needs to die. It should happen with everybody's eyes open. The team should be aware of the economics of the situation. They, the customers, and the managers should be able to agree that the ...
Get Managing Software for Growth: Without Fear, Control, and the Manufacturing Mindset now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
