The Hotrodder's Triangle

In the automotive performance world there's a saying called "Fast, durable, cheap: Choose any two.
" The same saying either originated or found it's way into (more likely) the project management world and is commonly referred to there as the Project Management Triangle. The point is you can't have all three things at the same time.

Moving toward any two traits shorts you on the other.

If you're in the software industry, you're familiar with deadlines.

You've made a commitment to the customer to have functionality to them by a certain date and now you have to deliver.

Compounding the problem is the on-boarding time of new developers to devote to solving an issue because you can't expect the new guy/girl to be fluent out of the gate; there's ramp-up time involved to learning the nuts & bolts of the project. If you follow Brooke's Law (from the excellent book The Mythical Man-Month), time is actually added to the scope of the project when you bring on new developers late in the game to help out. Paradoxically, the more programmers you devote to a late coding project, the tendency is for that project to become even later. If you want to deliver the features promised faster, the only way you can do it is to skimp on the remaining side of the triangle: Quality. What do you do? Transparency, always. If you've made a mistake your customer is going to appreciate the candid insight you give them into the reasons you don't want them using your product yet.
You never have a second chance to make a first impression; that bad code you give to the customer will make them forever suspicious of future releases you make (translation: they don't value your product as much).

Apple is a great example of a company that (up until the Maps fiasco) thoroughly exercises their products to the point where everyone is excited to upgrade.
With respect to my friends at Microsoft, it's been a long time since I applied a service pack without planning on having issues because I've been burned too many times over the years.
(Don't get me wrong here--I think Apple is to office productivity what double bladed skates are to an ice rink.
) Agile teams operate on a Definition of Done.

If the code does not meet that DoD, it doesn't leave the room.

DoDs generally contain testing and documentation standards, code reviews, demos and anything else the team can think of to preclude bugs finding their way into their customer's hands.

The DoD is essentially a contract the team has with itself; if the work done during the sprint does not meet the criteria established in the DoD, the work is not done. The DoD serves as guard against doing virtually the only thing you can to deliver a late project on time: sacrifice quality.