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.
If you really want to do this right, you have to accept that there's going to be a lot of manual work. Unit/system/integration/regression testing is vital, but it'll only verify that the software works the way the tests require. Requirements traceability means that each requirement gets an ID of some sort, and that ID is traceable throughout the development process. A requirement ID has to be tied to one (or more) features, features have to be tied to a design, and designs are tied to tests. Ultimately, you can look at any part of the system and trace it back or forward. If a test fails, you can see what requirement isn't being met. Look at some code and see why it is required and what parts of the system use it. If a requirement gets dropped, you can identify what code and tests can be removed. Unfortunately, there's no good tool support for this (we had a bunch of Perl scripts that wired FrameMaker, a custom change management system and a design tool together).
Best Answer
The formal answer is you misunderstood agile, agile does not dictate requirements, stakeholders do. The core of agile is not to carve your requirements in stone but rather have them emerge as you go, in close contact with your client, benefiting from progressive insights.
But that's all theory. What you have witnessed is indeed a common trait of many software production lines that adopted an agile way of working.
The trouble is, listening to the customer and swiftly responding to the customer's needs often soon ends up in not doing any thinking about the product or doing any design at all. What used to be a pro-active process fed by vision and expertise can and often will deteriorate into a passive, entirely reactive process fed by the customer's wishes. This will lead to making just the bare necessities that "will do the job".
The automobile would never have been invented if manufacturers at the time would have been "agile" because all the customers were asking for was a faster horse.
This does not make agile bad though. It is a bit like communism. A great idea that hardly ever works out well because people are just people, doing people things. And the method/ideology/religion lulls them into the idea that they are doing well as long as they are going through the motions and/or following the rules.
[edit]
Slebetman:
Remember the golden rule of automation? "First organize, then automate". If you automate a broken process, the best that could happen is that you accelerate everything that goes wrong. The people at Toyota were not idiots.
The typical reason for adopting any new methodology is that things are not going well. Management acknowledges it, but they may not understand the core problems. So they hire this guru that gives a resiliant speech about Agile and Scrum. And everyone loves it. For their own reasons.
The developers may think "Hey, this might work. We would be more involved with business issues and we could provide input for filling this backlog. This could be an oppotunity to make sales and customer service understand what we do, why it is necessary, and we would have them out of our hair while we are transparently burning down what we agreed on." No more "stop what you are doing, this needs to be done now" by some dude you do not want to put off popping up at your desk.
Sales, customer service or the owner on the other hand may see it as a way to gain (back) control over this black box of a department that is presumably doing stuff that is necessary. They do not see what is happening in there but they are pretty sure the core of the problem is burried somewhere in there. So they introduce Scrum, install a product owner of their choice and all of a sudden they have all control, all the strings are in their hand. Now what?... Ehrr...
The real problem is often that the shop was not organized well in the first place and this has not changed. People have been assigned resposibilities they cannot handle, or perhaps they can but Mr. Boss is constantly interfering and ruining what they did, or (most often in my experience), crucial responsibilities have not been recognized or assigned to anyone at all.
Sometimes over time an informal organization will emerge in between the formal lines. This may then partly compensate for the lack of a formal structure. Some people just end up doing what they are good at, whether they have a business card to prove it or not. The blunt introduction of Agile/Scrum may ruin that instantly. Because people are now expected to play by the rules. They feel what they used to do is not appreciated, they get yellow little papers with little stories on it instead, the message will be: "whatever you were doing, no one cared". Needless to say this will not be particularly motivating on those individuals. They will at best start waiting for orders and not take any initiative anymore.
So things get worse and the conclusion will be that Agile sucks.
Agile does not suck, it is great for maintenance projects and can even be good for new developments if applied carefully but if the wrong people do not understand it or adopt it for the wrong reasons, it can be most destructive.