Scrum and fixed date contracts? Not a good idea.

Can Scrum be used for projects with a fixed date contract? That question comes down to how much you care about the quality of the software you are shipping. Why? Well, in the real-world software project contracts, two things are always strictly specified – scope and date. However, the quality of the shipped software is usually left out.
There are two main reasons for leaving out the quality out of the contract. First, it is really hard to specify quality on paper. Can it be measured by the number of the bugs, or by the severity of those bugs? Unless the bug is completely blocking the usage of the software, bug severity is something that is prone to discussion, which is why quality is hard to specify in the contract strictly.
This is the reason why projects with fixed date often tend to fulfill the scope by the set deadline, but quality is the first to suffer. So what does that have to do with using Scrum for fixed date contract projects? In short, Scrum is about breaking development into short cycles and iterating development of the features which have the biggest value to the project first, in order to achieve desired functionality and quality. Those who argue that you can use Scrum to deliver projects with the fixed date contract suggest negotiating the scope instead of quality with your client while doing those iterations.
What if the whole scope is really crucial for business? We can cite the famous Pareto principle in favor of those who claim that we should cut the scope first, but truthfully that principle can be applied to a project that has a vast amount of features. What if you need to deliver a small invoicing system within two months? In real life, invoicing features don’t really function without vendors features, and vice-versa. If you happen to be lucky to have a vast amount of features in your software project, rock-star negotiators on your team and understanding clients, you might consider negotiating the scope cut. However, that trick doesn't usually work twice. You could use Scrum then, but you really should not.
You can benefit tremendously by providing an estimate that is real, instead of an estimate that your clients want to hear.
So you are saying that I should not use Scrum for projects with a fixed date contract - what should I do then instead? How can I reach maximum client happiness without overworking my developers? I say, take the best out of Scrum. One of the great benefits of Scrum is improving the quality and getting feedback as soon as possible by delivering MVPs to the clients. That is the principle that Scrum utilizes and nothing is stopping you from utilizing it in fixed date project, regardless of what project management methodology you are using. Deliver an MVP to your client as early and as often as you can. You should do so not just to ensure that you are building in the right direction, but also to build up the trust with your clients. Nobody ever said “I don’t care to see the first build of my product”.
Also, try using some techniques to break down the scope better, plan more precisely, and get to know your teams velocity better. Estimation techniques like Planning Poker or Relative mass valuation can also help you to understand the scope of the fixed date contract. Do not be afraid to voice out concerns early, and place buffers just-in-case. Last, but not the least, you can benefit tremendously by providing an estimate that is real, instead of an estimate that your clients want to hear. Even if the competitors are giving what seems the better estimate on the paper, do not be afraid to underpromise, but then work smart to overdeliver.