Tom’s team is preparing a highly anticipated release, but QA hasn’t gone well.  More bugs were found than were anticipated.  Too many fixes have been of the hack-n-slash variety, meaning there could be lingering problems after the deploy.  There’s also a concern that tech debt is being accrued which will have to be paid later (with interest).

Tom considers his options:
1. Deploying on-schedule.  Deploying allows Tom to keep his commitment to his customers but may cause weeks of clean-up and unhappy users.  Sure, there will be a lot of clean-up, but at least his team will get credit for hitting the target.

2. Delaying the release.  Delaying means breaking a promise and explaining to customers (and bosses!) what went wrong.  It also may hurt the delivery team’s reputation and credibility.  But his team will have time to fix things the right way, and the users won’t be frustrated by broken software.

Stuck between a rock and a hard space, Tom ponders what to do.

Have you seen this?

What did you do?

What did you take into account in your decision?

How did your team feel?