Assumptions of Agile Project Management?

UPDATED a bit...

Any good discussion of a technical or even non-technical subject needs to start with a set of assumptions. I've listened to and read many posts of recent about Agile Project Management, without the underlying assumptions being explicitly stated.

Here's my take on some assumptions, possibly false in some cases, regarding the forum discussions on Agile Project Management (with a slight smile): (I did this post after a long meeting discussing the impacts on our plan of enegineering changing the design)

1. Agile Project Management is targeted at managing agile software development projects. Projects beyond just XP and Scrum software development. This has been clarified in the past, but it seems the discussion always comes back to XP or Scrum experiences as the topic of "project management," when in fact these are software development methodologies
2. Decisions made during an "agile project" have little or low impact on cost or schedule at the completion. Therefore, "planning in advance" is not an important issue in an agile project management process, since what comes next can be worked out in the next cycle of the "planning game" or Scrum cycle. Long range planning adds little value.
3. Design is not directly connected upfront with operations, maintenance, funding profiles or other business operations processes. Therefore, the design can proceed in the absence of these fianlized discussions and their impacts will be discovered as the system is deployed - this assumes incremental deployment.
4. Procurement of long lead items is not an issue in a "agile" project, so when we need something it will be available in short order.
5. The "Concept of Operations" (ConOps) will "emerge" in an agile project and the customer will be able to deploy these operational concepts to the field without too much impact on the ongoing business processes
6. Cost trades (life cycle costs, development, maintenance, and retirement) are not that important in agile projects
7. Risk trades (performance, completion success) are not that important, as the risks will emerge and we'll be able to deal with them when they do.
8. Operational trades are not important, because how we operate the system across the enterprise will be worked out as we go. This is actually that  case in many IT projects, but for other domains it might be an issue.

Now if the answer to each of these assumptions is "write a story" for the need, then an agile project starts to look like a "plan driven" project and the stories start to look like "requirements" for future needs and the whole process of planning, assessing impacts, making cost and schedule trades and all the those "traditional" project management processes start to blur.

The point here is that talking about project management using words of software development methodologies leaves out many of the issues that are important to projects:

1. Lead time for materials
2. Operations concepts and their impacts on the business processes
3. Making trades for all the independent variables of the project
4. Designing the foundation (architecture) of the product to provide a stable set of guidelines for further development.

I think these are the things project managers talk about (I know we do). The code development processes are critical but they are peripheral to the "management of the project" - the "business management of the project."