Lessons Learned
We experienced great results with a fully integrated testing team working alongside developers from the beginning. When testers and developers worked together to ensure that designs were coherent and to quickly find and fix defects, development went quite smoothly. We were a single team working together, not two departments constantly at odds.
New testers found testing in an iterative environment to be a challenge. Not having a "big design up front" requirements document was a struggle. Having to be more proactive to get the information on features they were testing was an adjustment. Also, the demand for testing with speed was difficult for testers used to spending a long time pre-scripting test cases and writing detailed test plans. In an iterative environment, there simply isn't time for this course of action.
In later Sprints, we found that the features already developed piled up and affected the new features we were testing. As a result, we had a lot more testing to do in later Sprints. In some cases, we would do less integration testing, incurring an "integration testing debt" that we covered in the last testing Sprint with a completed product. On smaller projects that kept up with bug fixing, this delay wasn't as difficult to handle; on projects that had more bug fixing later on, our testing duties were compounded.
There was a danger of burnout: Testers were testing new features as those features were developed in a Sprint, testing features developed from previous Sprints, looking after defects, getting information on testing from developers and customers, and supporting other team members who were testing. The upside was that a tremendous amount of testing was achieved, so we had to monitor testers to make sure that they weren't taking on too much. Now that a lot more testing was going on during development and the team needed rapid feedback, we sometimes needed more testers to help with testing tasks.