Re: Blaming the tools...
Then I would suggest that your sprint model is wrong, not the concept.
I hold 1 x 2 hour planning meeting per week with a preset agenda for each meeting so that we can achieve enough in 3 meetings to populate a sprint. We run 3 week sprints from Wednesday to Tuesday with a code freeze 3 days before release and use git flow to control this. We have a daily standup for on-site and Skyped-in developers plus project owner plus scrum master which takes no more than 10 minutes.
The point of the scrum/standup is to quickly identify any weakness in the project. Developers should be able to speak openly about issues that cause concern ('blockers') or if they feel that someone is not pulling their weight on the project. Certainly there is an argument for having the project rushed through and having flaws and defects fixed at a later date, but only if you have a QC unit that is separated from the Agile process, which many larger companies have now. Otherwise you need to fix defects as a part of the sprint cycle or move the task into the next sprint.