Large organizations have to deal a lot with process. They have to or nothing would get done. On the other hand, too much process can halt an organization from going anywhere.
That's why trying to implement Agile methods in a large organization is very scary for the stakeholders up the tree. However, I was pleasantly surprised to find organizations that, despite the "rebellious" nature of Test Driven development have found it to be acceptable from the get-go. That is, talking and explaining to stakeholders such as the testing-managers and methodology experts in the company about TDD, they said one thing: "That's what we've been trying to get people to do all along". Here's how.
Many of these large organizations have training facilities and managers that train the coders to do the job the way the company thinks is best. The methodologists set the material. For testing, they usually get together with testing experts and decide on the best method of implementing better code quality using testing. Such organizations will usually teach Unit testing as a theory and practice, only in a manual manner. In these courses they teach about white and black box unit testing, verification methods and more. Developers are taught to do the testing manually and enter the test steps into 3rd party test managers, and perform the tests before and after the code works.
Yes, you read it right. They are encouraged to write the tests before the feature is implemented. Test Driven development - not just hype - proven methodology. The problem is that implementing this in a non-automated way is too hard for any developer to do well, if at all. So many developers simply skip it meaning product is tested less and quality diminishes. So - the things I teach - doing TDD in the developer world, using automated frameworks, is just the thing for such organizations. It's the real-world way of implementing the methodology they have been teaching all along.
When I first realized this I was totally surprised. I thought organizations would frown upon such ideas, and it turns out these ideas have been part of the big methodologies as well for a long time. They just haven't found a way to make people do them. The frameworks we have today are a bridge between the organization's and the developer's wishes for better quality, and the reality of time limits.