One of the differences in the management of Agile projects is in the roles of various people that define what the project is. In traditional methodlogies you have confusion about how and when decisions are made about the scope or focus of a game. Some people working on a project may have a completely different vision of the project than the people paying the bills.
Agile methods define the roles of the customer and the developer very clearly. The developers don't work on anything that is not clearly defined by the customer. These definitions include specific user stories and acceptance criteria for determining when a requested feature is complete.
I saw the following diagram in Agile Project Management that clearly shows the relationships between the customers and the developers.
There are major benefits for both groups. The customers get clear control over the priority and definition of the features which determine product value. The developers get control over the mechanics of implementing the feature, including the schedule.
The developers don't get handed a 300 page document and a time-drame and budget to complete the game defined by the document. Every iteration they allow the customers to decide how they want to spend the iteration budget. If they request too much for that iteration, the developer let's them know in planning that they need to reduce the scope of their request. Once the iteration plan is made, the developers go off on their own to implement the stories without being disturbed with changed goals, etc.
Customers in the game development world are not only the publishers, but the designers and artists that will use systems developed by tech. Additionally design, art and programmers assume the developer role to polish and tune features (with programmers) to be accepted at the end of an iteration.
One interesting thing has come up with our R&D efforts. Since R&D will produce core tech that will be used by the production teams, the programmers that will use the product of R&D are the customers of that product. Having "programmer customers" and "programmer developers" trying to hammer out things such as intermediate file formats and APIs can be challenging. This is where having the CTO as the "Product Owner" of R&D comes in.