There is evidence that doing TDD takes about 15% longer than not doing TDD (George and Williams 2003). But there is also evidence that TDD leads to fewer defects. Two studies at Microsoft found that the number of bugs found went down by 24% and 38% with the use of TDD (Sanchez, Williams, and Maximilien 2007, 6). So, yes, TDD may take longer initially, but the time will come back to the team in the form of reduced bug fixing and maintenance time.

QSMA calculates a productivity index for the projects in its database. This index takes into consideration effort, schedule, technical difficulty, and more and is an attempt to help make cross-team comparisons more meaningful. In his comparison between agile and traditional projects, Mah found agile projects to be 16% more productive, an increase that he found to be statistically significant.

The QSMA study comparing 26 agile projects to a database of 7,500 mostly traditional projects found that agile projects have a 37% faster time to market.

David Rico's research bears out the claim that agile teams produce higher quality products. In his survey of 51 published studies of agile projects, he found a minimum quality improvement of 10% and a median improvement of 63%.

When quality was measured a month later, the team members were given their bonus--a four-week sprint during which they would be their own product owners and could work on whatever they wanted. They took the opportunity to do some refactoring that had been bothering them. One tester took time to explore a new testing tool. Two developers added a scripting interface to a part of the application. This type of bonus was a win all around and avoided the problems that tend to arise with cash or similar bonuses.

With billiard ball sprints, the team finishes one sprint, isn't ready to start the next, and--whack!--the start of the next sprint is pushed into the future. The second sprint often starts in name, but the team is so unprepared to do the work of that sprint that it spends days learning about what is expected. The best way to avoid billiard ball sprints is to follow the boy scout motto: Be prepared. Expend a little effort in each sprint preparing for the following sprint. Ken Schwaber recommends allocating about 10% of a team's available time in any sprint toward preparing for the next sprint (2009). I've found this to generally be about the right amount as well. The team should, of course, adjust this amount up or down based on its experience.