I find that automation and testability have to be designed in from day one. It's a bitch to try and implement it later.

If you want flexibility then again you have to take design decisions with flexibility as a requirement.

Flexibility is also hampered by failing to address technical debt in a timely manner.

I would also like to point out that buying expensive tools but scrimping on training in the use of those tools is a massive fail. Correct tooling and the knowledge of how best to use them is a massive productivity booster and will pay back many, many times the cost of the tool.

Then there's blame hounding. The DB is blamed for every delay even though business decisions were not made in a timely fashion and had to be repeatedly chased over several weeks.

Gary is right to bring up over anticipation of requirements. IT can be guilty of filling in the blanks. In fairness this can be driven by poorly defined requirements and the lack of interest or commitment by non-IT to get the details defined.

I've found that an effective way to deal with this is to state clearly what is going to be delivered, ask the stakeholders to confirm that the blanks that IT would normally fill in are actually required, and then list the out of scope stuff.

Always remember that IT requirements are also business requirements. You don't have to ask for permission to implement a backup strategy don't descope IT necessities through unnecessary abdication of power.