Good testers = crap code?

Fascinating phenomenon noted by Kevin Rutherford at Silk and Spinach (post here).  As he notes in his original post (here), a good tester (or testing team) can tempt developers to outsource all quality management to the testers.

However, because this is described as an “agile” project, I’m curious: What flavor of agile was used?   It sounds like that the “bad code” developers were throwing code over the wall to their tester, which seems like a parody of a waterfall life-cycle. 

The lack of details leads me to wonder how well the poorer-performing team was organized and led.  Per Kevin Schlabach’s comment, I’d expect that testers would be in the sprint team already.  That sounds like pretty standard practice.  I wonder about the team dynamics as well.  Lots of questions on that point:

1. Where there interpersonal issues?
2. How short were the effective iterations?  In other words, did the poorer-performing team behave more like a waterfall team, waiting until the last possible moment to turn over code (or did the tester only accept code at that last possible moment)?
3. Implied in Kevin S’s comment are questions about the relative strengths of the sprint/iteration teams.  If the business team was working closely w/ developers, how did the tester end up testing so much crap code?