If I'm Doing Project Management Right am I Agile?

This is the crux of the "argument without end," about the role of project management in modern software development. The first question is:

If the project is managed in a credible manner, using current "best practices," is the agile manifesto being fulfilled?

Let's look at each part of the Manifesto in a context and domain beyond 4 developers in the same room with there customer:

1. Individual and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following the plan

Individual and interactions over processes and tools

Both are mandatory. Projects are delivered by people. Interactions between these participants is mandatory. The "plan of the day," is common on complex projects. I work with a team of several 100 developers building flight qualified software. We have a morning brief, a weekly progress assessment, a weekly business rhythm meeting for the larger program, and a monthly progress and forecast review with the remote customer.
This project is subject to the highest rigor in the software development business DO-178B. While at the same time executing a "rolling wave" plan, where the detailed requirements emerge during the execution of the previous rolling wave. The overall mission remains pretty much intact. But the details MUST change because this is a "System Design and Development (SDD)" program.

Working software over comprehensive documentation

The weasel word approach is "don't do documentation unless it's needed." So what is the project needs comprehensive documentation for all the good reasons. Maybe we need Interface Control Documents (ICD) to specify how components will be assembled from various subcontractors. Maybe we need specific detailed specifications for the ASIC production facility to understand what we need in the silicon devices. Maybe we need detailed and traceable documents for the back file conversion house in Indian to move 50,000,000 health records from one system format to another, each with dozens and dozens of fields, some conflicting.

Customer Collaboration over Contract Negotiation

Both are mandatory. Oppressive contracts are bad. No contract is bad. In any project beyond the trivial, someone has to define what the deliverables are in exchange for the money. This is what contracts do.

Imagine hiring an electrician to redo your wiring in the house and letting them go to work without some understanding of what they are going to do, how much it will cost in the end, and what their obligations are for the safety of their workers, your house, and its equipment, and how they will be paid. You'd be silly not to have a contract in some form. A "quote" for the work at least. But this is a contract. Contracts are agreements between supplier and consumer. As set of cards on the wall is a contract.

Responding to change over following the plan

The notion that Plans (schedules actually) are developed and then fixed is nonsense on any practical project. There are no doubt projects where this is the case. But it's still nonsense. Anyone suggesting this is good project management practice is either selling you a bridge or seriously misinformed abotu how projects are managed.

Plans - the strategy for the successful completion of the project, and the schedule - the sequence of work needed to fulfill the strategy are subject to change for every imaginable reason.

But the reasons have to be the right reasons, they have to be reviewed, the impacts understood, and concurrence that this is the right thing to do. Then the plan and schedule need to be updated to reflect these changes.

So The Big Question?

Is Agile Project Management just Good Project Management?

What elements of an agile project management method would NOT be found in the Knowledge Areas and Process Groups of PMBOK(r)?

In fact here's a better Manifesto

1. Individual and interactions enabled by supporting processes and tools - tools don't design products, people do. Use tools for what they are designed to do.
2. Working software produced through appropriate documentation - the documents don't fly, the product does. The documents tell us what to how to fly the product.
3. Customer collaboration guided through a well written contract- people make decisions within the confines of the "rules." Just like nations do. We need guidance on the mechanics of executing the project - who gets paid what, who owns what after we're done, etc.
4. Responding to change through a well run change control process that produces new plans and schedules - this is the role of the change board. Be it rigid or loose, managing change is needed otherwise its chaos.

This is called credible project management.