Projects die all the time. Even languages can (mostly) die. The death of a project is a valid part of a project lifecycle and knowing how it dies can affect h

Projects die all the time. Even languages can (mostly) die. The death of a project is a valid part of a project lifecycle and knowing how it dies can affect how you deal with previous project phases. Agile never assumes project death is a reality. It philosophically implies that you can always measure and iterate your way to the next phase... but that's just not true. No one measures and iterates their way to a dead state on purpose and yet, projects end up there all the time. So how are the projects getting there and what is Agile doing about it? And don't give me the Agile vs. "Agile" argument. Assume a flawless execution of agile principles with completely accurate measurements and successful iterations took place when answering that question. To me, agile just assumes infalsifiability because it refuses to acknowledge, let alone, prepare for project death. And worse, according you agile, you can even measure and iterate your way out of the grave. The operation of a projects has more in common with biology than immortality. Treating projects like immortals flies in the face of the reality of project lifecycles and it brings very bad mental states to problem solving. It makes far more sense to treat a project in lifecycle phases (birth, child, youth, adult, mature, elderly, dead) than assuming a singular monolithic philosophy that completely ignores the arc of a project. A: "The code base is too unwieldy, no one understands it any more" B: "Oh, just measure and iterate" A: "But that just creates more unwieldy code!" Agile makes sense as a subphase of a project lifecycle for when that lifecycle is spinning its wheels in the mud, not as a end-all-be-all philosophy. TL;DR: Agile should used if a project stalls, not as a guiding philosophy.