Good testing is one of the bottlenecks that needs to be solved if your organisation wants to embrace shorter iterations and quicker feedback. On team level it seems possible to do almost continuos testing, but when it comes to testing integrated systems and products, with deliverables from numerous teams it is critical to have a well-understood test strategy, in the sense what to test, why doing it and when does it needs to be done.
I am the first to admit that I am not a tester, but as a software designer and architect I have been inspired by skilled colleagues who are testers, which is a skill in its own. I regularly follow the blog thoughts from the test eye since they have a view of testing which inspires me as a software architect. Not only do they have a an approach to their craft which I think resonates very well with how I think software design and development should be done in ana agile context. They also produce some really useful reference material, for example i regularly use their Software Quality Characteristics 1.1, which is the best summary of quality attributes in a concise form I know of. They have other useful material, like Den Lilla Svarta om Teststrategi (unfortunately only in Swedish).