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.

Hey @Chris Belknap

Really appreciate the way you framed that. The idea that many teams sit in a space between prediction and adaptation hits home. I have seen that same tension where leadership still wants precise forecasting while delivery teams want room to learn and adjust. Both sides end up tugging in different directions.

Your point about tools staying invisible is also spot on. When the tool starts demanding attention instead of supporting the work, you can feel the energy shift. In my experience the better setups are the ones where the platform simply makes things visible and reduces noise rather than shaping the process too tightly. That is usually when both the organisation and the team can breathe.

The part that interests me most is the shift you mentioned from managing tasks to delivering outcomes. I have seen a few teams try to make that transition and the real challenge was keeping stakeholders confident without sliding back into old control habits.

How do you usually help teams maintain that outcome focus while still giving stakeholders enough clarity to feel secure in the direction of the product?

Hey Benedikt Aufermann

I really appreciate how you expanded on that idea. You brought in a level of clarity that is often missing when people talk about projects and agile work. The distinction you made about time limited initiatives still being able to use iterations and learning really matches what I have seen on a few teams as well. A project can be temporary and still benefit from agile principles while the team is together.

The part you mentioned about organisations using the word agile without changing the underlying mindset also feels very true. I have watched teams go through that where the ceremonies get added but the decision making and expectations stay fully traditional. It looks like agility from the outside but nothing really feels different for the people doing the work.

To your question about what I was asking earlier. I am trying to understand how people here see the difference between genuinely agile project management and project management that is only named agile. The lived experience on teams can be very different from the theory and I am curious how others make sense of that gap in their own environments.

Hey Ian Mitchell

I really like the way you framed the Sprint as the real project. That perspective cuts through a lot of the confusion around what organisations call a project and what Scrum actually treats as meaningful work. When you look at the Sprint as the place where empiricism happens, the whole conversation shifts away from big predictions and back toward learning and value.

The point about organisations wanting certainty even when it is an illusion is something I have seen a lot too. That pressure often pulls teams back toward heavy planning even when everyone knows the plan will not survive contact with reality.

Your advice on being agnostic about the project word makes sense. It keeps the focus where Scrum places it anyway. Clear Sprints, valuable products, and quality outcomes. When teams anchor themselves in those practices the need for traditional project thinking starts to fall away on its own.

Curious if you have seen any practical ways teams help stakeholders make that shift from certainty seeking to outcome thinking without causing too much friction.

Curious if you have seen any practical ways teams help stakeholders make that shift from certainty seeking to outcome thinking without causing too much friction.

A certain humility is needed in that these are not our organizations to change. We don't own them. Sponsorship must be obtained, in which enough of a sense of urgency is created for change to become more important than the day job, and organizational gravity is thereby overcome.

How do you usually help teams maintain that outcome focus while still giving stakeholders enough clarity to feel secure in the direction of the product?

You might anchor teams on a real Product Goal and then use Evidence Based Management to make the work transparent in a way that builds confidence instead of control. A Product Goal provides a shared direction that does not change every Sprint. EBM gives a simple structure for showing progress in terms of outcomes rather than tasks. Each review becomes a check on what is improving, what is not, and what the team has learned that should shape the next bet. That usually gives stakeholders a clearer sense of trajectory than any predictive plan.

Progress toward the Product Goal can be inspected at the Sprint Review. Asking open questions about whether the Sprint Goal was achieved and whether it moved the product closer to the Product Goal strengthens alignment and reduces anxiety.

The team stays outcome focused because each Sprint ties back to the Product Goal and the evidence showing whether the direction is improving. Stakeholders feel secure because the product is becoming more visible and understandable, not because the team is producing more documentation.

Hey Ian Mitchell

That is a really grounding way to put it. I think a lot of us fall into the trap of feeling responsible for changing the entire organisation when in reality we only influence small parts of it. Your point about humility is important because without sponsorship the team ends up pushing uphill against structures that are not ready for change.

The idea of creating enough urgency for change to matter more than the comfort of the day job makes a lot of sense too. I have seen teams try to introduce new ways of working without that urgency and everything slowly drifts back to what feels familiar. When leadership actually feels the need for outcomes instead of predictability the shift becomes much smoother.

In your experience what usually sparks that sense of urgency for sponsors. Is it market pressure, internal frustration, or something else entirely.

Hey Chris Belknap

I really like how you connected the Product Goal with Evidence Based Management. That combination makes the path forward feel a lot less abstract for stakeholders while still letting the team work with discovery and learning. When everything comes back to a steady Product Goal it removes that scramble where people expect a new plan every week.

The way you described Reviews also clicked for me. When the conversation shifts from tasks to what actually improved and what was learned it does a lot to lower the pressure on teams. I have seen Reviews become much healthier once the focus moves from reporting to understanding. Stakeholders end up feeling closer to the product rather than just inspecting output.

Your point about visibility replacing documentation went straight to the heart of it. When people can see the direction clearly, even if the details are still forming, the need for heavy prediction starts to fall away.

In your experience what helps teams practice this consistently. I have seen some teams adopt the idea but slip back into task reporting when things get stressful.