My current client is a major telco. They have been developing high qaulity software for decades (literally). They have heavily entrenched waterfall process. They are used to doing everything to the letter of their methodology. When I first came on site two years ago I used to dispair of them ever doing anything agile.

Today, they seem to be doing agile pretty well. Its not been a universially posiitve experience and there are plenty of non-agile values and practices still floating around. On the whole though I have been impressed that rather than seeing Agile as an excuse not to write documents, they have embraced the disipline required by a leaner software process.

I have worked with clients who were much more reactive and used to being at the cuting edge. They embraced agile becuase it appeared to legitmise the lack of structure in their approach. They produced poor software when they produced up front designs and they continued to produce poor software when the developers were 'let off their leashes'.

Upon reflection I think my current client, with its long history of rigour and application of best practice has made far better use of the agile techniques. Maybe its becuase they continue to apply disiplince. Possibly its becuase they are very aware of the dangers of a less formal approach and are always trying to mitigate any risk that not having the waterfall in place might bring.

Ever since I started with Test Driven Development back in early 2004 I have always advocated out-of-container testing and regarded any test scheme that requires deployment before execution as flawed.
I still think this is largely true and there are many many good reasons why having a fast, automated and comprehensive test suite which runs without going near the full stack is essential.
I have come to believe that this is not the whole story though. Testing by humans is an expensive and time consuming activity, often executed poorly and with debatable results. Often the best thing you get out of a test team is somebody to blame if it doesn't work in production. That sounds harsh but how many times have you heard the developments team response to a defect be 'what the hell were the testers doing for two weeks?'?
If you really want to be able to remove humans from the equation then unless you are very confident that nothing in your execution environment can affect the functionality of your software then you need to create automated tests which run against a deployment in-container.
The added advantage to in-container tests is that they can be used to seed load tests which reflect the user stories being delivered rather than some cobbled together random sample by the expensive performance consultant the week before go live.
We are writing in container tests for a RESTful web service. The tests are developed using a home rolled framework designed to be as readable as possible to the test and analysis teams. The tests are driven by the user stories being delivered and are very easy to validate against the API documents we publish.