I have seen the Carnegie Mellon site covering TSP. I am looking for a practical, non-academic guide to application of TSP in the real world. I would really like to know, how does TSP reduce bugs?
If you aren't familiar with the Personal Software Process (PSP), I'd start with Watts Humphrey's book PSP: A Self-Improvement Guide for Software Engineers. This book is geared for practitioners looking to apply the PSP in their job. It also begins to introduce the Team Software Process (TSP) in the later chapters. A very brief, high level introduction to the PSP can also be found in Introduction to the Personal Software Process, also by Watts Humphrey. Although I don't own them, the canonical books on the Team Software Process are Introduction to the Team Software Process (a high level overview to get started), TSP: Leading a Development Team, and TSP: Coaching Development Teams. Since you've mentioned the TSP website, you've probably already seen the Team Software Process Technical Report along with other reports published by the Software Engineering Institute about the TSP.
The PSP, and by extension, the TSP, reduce defects by introducing a repeatable, quantatively measured process. The TSP calls for a team (or teams) of PSP-trained engineers working together on a larger project. In order to understand how the TSP reduces defects, you need to first employ the PSP to reduce defects on an individual level by gaining insight and making adjustments to the individual process.
At PSP0, you begin making measurements to help understand how you current build software - size, time, number of defects, and so on. The act of simply recording data and analyzing it can provide insights into which life cycle phases are most problematic for the individual, either by individual data elements or some combination of them.
PSP1 doesn't add any quality aspects, but does improve estimation. There might be a quality improvement here since you have a greater understanding of how you use your time and can allocate and utilize time more efficiently. Even though you don't use this data until PSP2, you start tracking it now to have a historical record to start with. Being able to know if you need to spend more time on a particular aspect of the product life cycle or if time is being wasted might help you improve process quality, if not also product quality.
In PSP2, you add reviews in order to prevent and remove defects. You also add process improvement - utilizing your measurements and estimations, as well as recording where defects happen. By taking your time, size, defect, and estimation data, as well as defect injection data newly added, you can answer more questions. Relationships form between program size and defect rates, time spent in reviews versus defect rates, and so on. Using this allows you to act (as an example, if you're spending a long time in reviews, yet many defects are escaping to the next phase, there's a problem with how you conduct reviews).
The Team Software Process takes a team of engineers all utilizing PSP, scales it up, and adds management-level tasks to coordinate their interactions and explore measurements and metrics relevant to a team of software developers rather than just at an individual level. The ability to identify relevant measurements and metrics and then apply them to identify weaknesses in the process is the whole point of both the TSP and PSP.