When using agile with this approach, Discovery and scoping are lighter weight and if at all possible you will want to have the whole development team involved with the process so they have tacit knowledge of the business values and reasoning for the project. this helps in the long run with the team understanding of what is meant by a given requirement. Scoping and Business Cases would be where I would develop story cards to document the scope and business case.
Development is where your iterations happen. and the vast majority of your testing.
Testing/Validation becomes mostly Validation because you have been doing daily builds and testing all along the way. you may have even been doing TDD where you develop the software with the sole purpose of addressing the tests
Launch is launch.
You could use this in an iterative approach where you go through the dev/test/launch every iteration, though that is not common with Stage Gate approaches. More typically in this kind of environment you would do your iterations within the Development stage gate. doing integration testing within the development stage alone then, again, the test/validation stage is more validation than testing.

1 – Doesn’t really give you much information but makes time tracking easy. If your management relies on burn down/burn up then you can and should use this approach.
2 – works IF your stories are larger than a sprint. if they are smaller than a sprint then I wouldn’t bother with this approach, you are getting WAY too into the weeds
3 – If your stories are smaller than a sprint but your epics are larger then you MIGHT consider this approach. BUT, if the stories are not handled sequentially then I wouldn’t recommend this. What you will see is great progress for a bit. then a long time of no movement, then progress, then no movement. If your sponsors aren’t using burn down they will keep asking you questions about this. If your scope is fixed (for example a compliance with a Federal Mandate) and you are using agile to gain the Quality and reliable releases, then you could use this approach
4 – This is good if you have regular releases, say, every quarter. then this approach will allow you to see progress toward the release. through delivery of the stories.

Anyway you slice it the Gantt approach only makes sense when used in conjunction with burn down / burn up charts for Agile projects.

You can apply the principles of Agile/Lean to any project. The real question is what value do you want to get out of the implementation. What you want to get out of it will dictate what you use on it.

Listen to this podcast with Amr Elsamadisy about Agile Adoption Patterns.

http://gallery.josephflahiff.com/podcast/Amr_Samadisy.mp3

In Agile you test all the way a long. The developers do their integration testing, then an independent tester does a round of integration testing. this independent tester could be another developer but I tend to have an embedded tester on my team, sometimes two, depending on the size of the team. The thing is the testers will pay for themselves in the quality of your code.

Two answers: You have to ask. “WHY are we doing agile?” What benefit are we getting from it? You can do a mixed approach that will allow you to achieve the Speed to market benefits of Agile, without the adapting to change parts (See “Agile PM with Scrum” by Ken Schwaber Appendix D) You just add a requirements definition phase before the agile development.

Answer 2: The problem you are seeing is that the PMO is too far removed from the real customers to track actual customer VALUE so they track to a metric. This metric might be as much as 50% off from real customer value but the project has to track to it. This is a foolish approach. Mary Poppendieck calls “Cost Center Disease” she did a case study about this with IBM. The IBM VPs were required to commit to the release months and months ahead. After implementing a lean/agile approach they still had to commit but they only had to commit to something like 70% of the feature set leaving 30% available for change.

Peace
Joseph