How Do You Approach Agile Project Management in Real Teams?

In most companies, "Agile Project Management" is a bridge between the old and the new. It often means traditional control with a touch of agility. But project management is about prediction and control. Agility is about learning and adaptation. Can both coexist for long without conflict?

Take a look at the Scrum Guide and notice how many times "Product" and "Project" are mentioned. Scrum certainly has an affinity towards Products, that's why there isn't Project Owner, Project Goal, and Project Backlog. It manages uncertainty through clear accountabilities: the Product Owner focuses on value, Developers on quality and delivery, and the Scrum Master on enabling the system and the team to be effective. When teams truly work empirically, there is little left to "manage" in the project sense.

Tools only help if they stay invisible. A whiteboard can be more agile than the most advanced software if it supports real conversations. Are your tools serving the team, or is the team serving the tool?

Mixing Waterfall and Agile happens when the organization still thinks in milestones instead of outcomes. The top plans, the teams adapt, and both sides quietly frustrate each other. Its a Fish with Feathers than can neither swim or fly.

Scrum is not Agile Project Management. It is a framework for product development and discovery. Once you shift from managing tasks to delivering outcomes, the project mindset begins to dissolve.

• But project management is about prediction and control.

I partially disagree with this statement. This statement clearly applies to the traditional approach to project management. But not necessarily.

If we look at the definition of a project:

• A project is a temporary endeavor undertaken to create a unique product, service, or result.

The main difference between a project and a product is the time limitation. 
Uncertainties can also arise in a project, and usually do. Goals also emerge during the project's lifetime (hopefully through learning). 
Projects can be managed in an agile way with clear responsibilities, iterations and bottom-up intelligence. Examples include relocating a large company or integrating existing products into a new system following a company takeover. Often, tasks are carried out on behalf of a customer, who then maintains the outcome once the current goal has been achieved.

These time-limited tasks can be carried out by an agile team which is then disbanded or moves on to a new project.

However, I fully agree with Chris on this point

• In most companies, "Agile Project Management" is a bridge between the old and the new. It often means traditional control with a touch of agility.

The term 'agile project management' is mostly used because organisations want the 'agile' label without making any fundamental changes. They often try to achieve this by naming a typical product development process a 'project'.

Trent, what is your question? 
Is it about project management that is truly agile, or project management that is only named agile?
The real-world setup will be completely different.

The most important project is the Sprint, because that is the project which allows empiricism to be established and maintained. That isn't what most companies mean by "project" of course. To them a project is a much bigger leap-of-faith. Empiricism gives organizations their connection to the real world. Yet in the real world organizations favor prediction and certainty, however fake it might be.

This is the irony which Scrum professionals deal with every day. There are many hills you can die on in Scrum, and some of them are worth it, but I'd suggest that the project word isn't one of them. My advice is to be agnostic about projects. Let others talk about them. We will talk about Sprints, valuable products, and quality.