I have to laugh to myself (to keep the insanity at bay) when I think about the first release of the project I mentioned earlier. To make matters worse, the "management" discovered a "silver bullet" that they were going to leverage to make us more productive: TDD/CI.

Don't get me wrong, I firmly believe in TDD/CI. However, if you force the team working on a major project to adopt such technology and techniques without any formal training and expect it to have an immediate effect tantamount to "saving the project from failure" then you have left the realm of rational behavior and have embarked on a journey to the island of insanity. We did only a mediocre job at TDD/CI on that project and it often became a bone of contention that actually reduced our capacity and velocity as people argued over "what is a unit", "what should be mocked", "why does code coverage not guarantee functional coverage", etc. I can't tell you how many "silver bullets" have been forced on me over my career without proper expectations and management.

Nowadays we use SCRUM to manage our agility and the management has succeeded in subverting that as best they can, rendering it almost ineffective in our case. The team is not empowered and is discouraged from innovation. What a mess...

Another major reason for all the overtime is that people often times have a feature in mind but cannot adequately describe it. What ensues is a constant struggle to get them to say what they mean and establish the communication necessary to validate that the feature has been defined well enough to be effective from a product perspective. SCRUM can help but only if you let it (i.e. proper story development and making the proper distinctions between epic and simple stories and acting accordingly).