That's the dangerous way of thinking. As far as I'm concerned and seen projects fail because their either build the wrong thing, or don't deliver (on time). The

That's the dangerous way of thinking. As far as I'm concerned and seen projects fail because their either build the wrong thing, or don't deliver (on time). The practices can slow you down, but they can also speed you up. Sometimes the failure to deliver is a managerial failure or the problem is too complex for the team tasked with it to deal on deadline. It's rarely because of "we keep code clean and production running" or "instrument everything". What I've seen instead much more often is that good practice is replaced with common practice or deviation (problem) is normalized. The latter leads to some rather interesting failures - bugs, and failing to deliver. Sometimes explosions if you're dealing with rockets. I've also seen bad workflows cause serious slowdowns and issues, while not being replaced because things are "done" on paper. I find this on par with lying to your boss, which it is. Also in case of bigger multiple teams, tardiness to implement improvements because someone might have to change something about their setup, instead of engaging them with a discussion, leaving it for a flag day. (When everything invariably goes wrong.)