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.
It looks like you took some fancy items from agile development, put them to waterfall process and now you call it agile.
The product is developed for a customer who will re-sell it while
paying us royalty.
This is OK.
The team does not get to talk directly to the end user. Only to
the reseller.
This is OK. Product owner talk to reseller and collects requirements.
A product requirements document was created before starting
development.
This is not OK. I haven't seen the project where definite requirement set can be defined upfront. Change your product requirements document to product vision (short) with some initial set of requirements which are subject to change.
The requirements are rigid and do not change.
This is not OK and you will see in the future that it is also not true.
A delivery schedule was agreed on with milestones such as "alpha",
"beta" etc. and features/times attached to those milestones.
This is not OK. The real schedule will be visible from the team progress. You can make general milestones but assigning exact set of features which will be implemented in these milestones is not agile. This can change during development.
All developers on the Scrum team report to the product owner, a
software manager.
This is not OK. I would not say that developers report to product owner. Scrum process keeps visibility of the process but developers do not report anything except regular meetings. It is responsibility of product owner to be in contact with a team and as active participant see the progress himself.
Testers on the team report to a QA manager.
This is not OK. Testers should be part of development team because user story is not done until it is tested (there should be automated test to validate acceptance criteria). There can be separate QA but it is additional level of complex testing and it is usually done on customer side (but doesn't have to be) to validate that SW does what customer expects and the feedback is collected as new backlog items or bugs to existing completed backlog items.
Separating complete QA outside of development team leads to breaking the whole purpose of definition of done. Some QA must be part of the team and that part is not related to any QA manager - that part is doing commitment with development team.
The product owner has directed the team towards certain high risk
technical tasks. The output of those tasks is not usable by the end
user but rather some technology/code that will eventually be used in
the product.
This happens in every project but it should be part of some product backlog item targeting end user. It can be included directly in backlog item implemented in current iteration or it can be included as a spike (proof-of-concept) to clarify complexity of some backlog item which should be implemented in the future.
The product owner has created a backlog based on the requirements.
This is a must.
The product owner is unable to answer some questions regarding the
product. He refers to others or to the documented requirements.
This is not OK. It is job of the product owner to know answers. He has a responsibility and he must do decisions. If he doesn't know answer he must find it asap.
The team goes through the motions of Scrum. Daily Scrum, Sprint
Planning, Retrospective etc. There is a ScrumMaster.
This is OK but it doesn't mean that team is doing Scrum.
Every sprint the product owner and management decide what backlog
items the team works on.
This is definitely not OK. The product owner and management can make priorities but commitment (selection of most prioritized items) is teams responsibility.
There is a burndown chart. Scrum board with stories and tasks. The
estimates on those come from the team.
This is OK.
The team sits in an open floor "bull pen" shared with other teams,
all visible and audible. There is cross-team noise and there is foot
traffic around the team area.
It is Scrum master's responsibility to make end of this if team feels like it reduces their productivity.
The team may be required to attend various meetings not directly
related to the goals of the sprint.
It is OK, the time wasted on these meetings will result in smaller commitment (team will do less real work). It is up to Scrum master / management to reduce these meetings to increase team's velocity.
There are pressures to select certain technical solutions. Some
tools and processes are mandated.
This is partially OK. There can be non-functional requirements for tools and architecture and there can be defined processes but still final implementation is up to the team.
Best Answer
I will say that there are very few software shops that are fortunate enough to have the rare distinction where Agile truly doesn't make sense as a methodology. If your entire team consists of truly exceptional software developers with a deep understanding of aspects of the business and longevity with the company and each other, and if your business requirements and client needs are typically always similar and rarely subject to changes in the middle of a release then you are fortunate to work in such a rare environment where Agile can probably actually HURT.
It is designed to be the most effective approach amidst chaotic and constantly changing business requirements and customer needs, evolving or changing project resources, and tight or shifting deadlines. Such an environment spells certain doom for typical waterfall development as it is vulnerable to team changes mid project, vulnerable to changing requirements, and extremely vulnerable to a changing date.
I feel for your valuable team members who don't find joy in their work anymore. They very well may be exceptionally talented people who engross themselves in their work but in the end, a number of factors outside of their best control can still kill the project. The best way to approach feature development is for them to lose the individual attitude and expression and think in terms of the team approach.
If you find that this won't work for them then you can find special use for them. If they are exceptionally talented and experienced, see if they would be interested in an architectural role, laying out high level designs, approaches, experimenting with new technologies and evolving best practices. Have these people control and review design documentation.
If this doesn't suit them still then perhaps have them work seperately on extremely complex technical refactorings on a seperate branch, hugely involved prototypes and proof of concepts, or other trailblazing work that sometimes needs to be done but doesn't fit well in the scope of a single project or release.