From my experience whatever you do in Sprint 1 dictates the success of your project. If you opt for a running start and ignore practices such as TDD, Pair Programming, Automation, and Refactoring then your velocity won’t account for them. You face a similar challenge if you have a herculean Sprint 1. Whatever you do sets an expectation with the customer – the velocity achieved in Sprint 1 sets an expectation of what can be achieved in future Sprints. It is incredibly difficult to reset that expectation as your velocity will dip if you decided to start Refactoring or doing TDD or working a 40 hour week.
As professionals we have a responsibility to write clean code from the start. The customer may feel we are moving slowly but we are investing in the future maintainability of the software. Through TDD we are building testable software and providing the team with the confidence to Refactor. In turn Refactoring allows us to evolve our design so they remains simple. The story is similar for the other practices of professional software engineering.
As the software grows the teams has pride in the software they are engineering. The quality is high and its easy to change the software as new requirements are implemented. In the end customer satisfaction is high, why wouldn’t you practice TDD and Refactoring from day-1?