We've been using Scrum and TDD for about three years now and have released several versions of a very complicated application suite that has an extremely large number of possible configurations.
We've been running into problems related to specific configurations that have slipped through the cracks. For example a specific feature is not working with a specific version of the JRE. This has been ongoing for sometime and the last release we created an entire Scrum team [Release Engineering] to handle compatibility testing. This team was not formed until a few sprints before the anticipated release date.
We have a large amount of automation, from unit tests, right up to GUI verification tests.
So... how can we mitigate the risk involved with a large number of supported configurations? Since the system is changed so often, a configuration we tested 2 months ago may have broken and we already moved onto another. Our unit [ie build automation] and FitNesse tests are maintained on a single configuration and run continuously. It doesn't seem practical to maintain a large number of build environments, we all ready spend a great deal of time maintaining a single one. It would be a massive investment to run though every configuration each time a feature is added.
It seems that this kind of configuration testing is almost a pure QA task and it's been suggested that this work be outside the normal development process, hence the dedicated team. Telling the teams that each new feature must be verified on every configuration would basically grind them to a halt.
Have you done any sort of risk analysis on the different configurations?
It sounds like you are at the point where 100% regression testing on each sprint is just not practical anymore. Barring that, you will need some sort of methodology to determine which pieces of regression to drop. Risk based analysis may be that methodology.
Another may be the total number of potential users for that configuration. Go for the 80% configuration versus the 20%.