Of course waterfall is viable. It brought us to the moon!
And it's a agile coach talking here!
Unless you can clearly identify problems related to the way you manage your projects, there is no valid reason to change.
As an alternative of Agile and Waterfall methodologies, I will suggest YOUR methodology. Adapted to your specific business, your specific team, your products, you way of working, your company culture... It's why Scrum is called a simple framework instead of a methodology.
Wanting to implement a methodology because someone on a blog you like talked about it is as stupid as letting problems going without doing anything.
From your description it is not clear whether the teams are actually working on separate projects - I assume they are.
In the ideal case, I think this should be mainly decided by the teams themselves, but they would come to more or less the same conclusion (i.e. using Agile). Especially if prominent members of the teams used to work together in the single Agile team before, they tend to naturally bring with them the practices they tried and proven to work.
However, each new team is bound to encounter its own, more or less different situation and challenges, so over time they will develop their own process a little bit differently from the others. And that is fine, within certain limits. In order to make management's life easier, it is advisable to agree upon and stick to some common way of reporting towards management. But since Agile is not reporting-heavy, I don't think this imposes huge restrictions on any team.
Now, if one team comes up with a process improvement, it is indeed useful for other teams to learn about it - as long as it actually solves some problem of theirs too. So IMO the best approach would be to keep up communication between teams regarding retrospectives and process improvement solutions, by way of some designated team members (one from each team would be enough - e.g. the Scrum Masters) to regularly meet after each sprint and discuss the problems they encountered, the solutions they tried, and the results.
So if Team A tells about a problem, it is possible that Team B has already got a working solution for it, which can be applied right away. Or if Team A has an idea to solve same problem, it is possible that Team C has already experimented with a similar idea and they have gained useful experience which they can share with Team A. Etc. The point is that any team is most interested in solutions to their concrete problems, so it is best to approach knowledge sharing from this perspective: adapting solutions to concrete problems, rather than trying to adapt processes to imaginary "solutions". Development teams would be pretty normal to resist the latter approach, but not the former.
Best Answer
Testing is absolutely essential to agile, primarily because agile is based around incremental improvements: the difficulty is that it can sometimes be hard to see how the current changes will effect your old code. The best way to be confident that you haven't broken something is to test it, and to know HOW to test it. That way you find the bug immediately, not down the road when you have forgotten exactly what you did when you were writing the code that broke some old feature.
The reason this is different from more traditional, top-down design type programming is that in that environment its a) very difficult to test until you have the finished product b) in theory you are considering all the design criteria at the same time, and so you are less likely to make a design decision that breaks previous design decisions.