We went through exactly this. The turning point was dropping the idea that the PMO owns the process, and instead positioning ourselves as the people who make the portfolio visible, regardless of how individual teams work.

We stopped requiring teams to use our templates and started asking for outcomes: what are you delivering, when, and what's at risk? Agile teams are actually quite good at answering those questions, they just don't like filling in a RAID log to do it.

Worth acknowledging that some of the tension is legitimate. Agile teams do sometimes use "we're agile" as a reason to avoid accountability. And PMOs do sometimes impose process for process's sake.

The healthiest dynamic I've seen is when the PMO and the agile coaches work together, not as adversaries. If you don't have that relationship yet, it's worth investing in it before trying to sort out the process questions.

The things we kept non-negotiable: dependency tracking, resource demand visibility, and strategic alignment checks at key milestones. Everything else we made flexible.

The things we let go of: stage gates for every project, standardised reporting formats, and the assumption that a project without a Gantt chart is unmanaged. Some of the best-run projects I've seen used a Kanban board and a weekly standup.

I'll say the thing nobody wants to say: a traditional PMO and genuine agile delivery are fundamentally incompatible. Agile is built on autonomous teams, rapid adaptation, and trusting the people closest to the work. A PMO is built on oversight, standardisation, and centralised visibility. These are not complementary philosophies; they're competing ones.

What most organisations call an "agile PMO" is just a PMO that uses agile vocabulary while doing exactly what it always did. The scrum ceremonies become status meetings with different names.

I think the debate here is conflating two separate questions: (1) can a PMO and agile teams coexist, and (2) should they? The first is clearly yes, many organisations manage it. The second is where I think Joost's challenge is legitimate.

The coexistence often comes at a cost that's hard to see: the agile teams spend a significant portion of their time feeding PMO reporting needs rather than delivering product. Whether that overhead is worth the portfolio visibility is a genuine strategic question, and I've seen it go both ways.

Joost, I disagree with the framing. Agile is about how teams deliver. Portfolio management is about how organisations decide what to deliver. These operate at different levels and the tension you're describing is real but not fundamental; it's mostly organisational immaturity.

The APM published a good paper on the agile portfolio as fact or fiction that makes exactly this argument. Portfolio-level oversight is not incompatible with agile execution; they just need clear interfaces.

Irene raises the right question. The overhead cost is real and it's often underestimated at the point of implementation. But I'd counter that the alternative, agile teams operating without portfolio visibility, has costs too. Dependencies get missed. Resources get double-booked. Strategic priorities get ignored because no single team has the mandate to enforce them.

The question isn't whether to have oversight, it's how to make the oversight as lightweight as possible while still being useful.

We implemented SAFe about two years ago to try to bridge this gap. I have mixed feelings. It gives you a framework for connecting portfolio decisions to agile delivery, which is genuinely useful. But SAFe is also enormously complex, and the overhead of running PI planning, ART syncs, and portfolio kanbans on top of actual delivery can be punishing.

The honest assessment: SAFe solved our visibility problem and created a new overhead problem. Net positive, but not by as much as the consultants promised.

What tools are people using for this? We're trying to get portfolio visibility across six agile teams without drowning them in reporting. Currently using Jira at team level and a manual Excel rollup at portfolio level which is painful and always out of date.

Thomas, SAFe is a great example of what I'm talking about. It's agile theatre at scale. The teams are doing sprints, the ceremonies are agile-flavoured, but the fundamental dynamic is a large central bureaucracy deciding what gets built. That's not agile in any meaningful sense.

I'm not saying that's wrong; maybe that's exactly what a large organisation needs. But let's not pretend it's agile. And let's not pretend the PMO hasn't just rebranded itself as a Release Train Engineer.

Fleur, we use Jira Align (formerly AgileCraft) for the portfolio layer. It syncs directly from team-level Jira and gives you reasonably clean portfolio views without requiring teams to do separate reporting. It's not cheap and the setup took three months, but it solved the "manual Excel rollup" problem for us. Atlassian also have a lighter-weight option now with their Advanced Roadmaps feature if you're already on Jira Software.

Joost, that's a bit uncharitable to SAFe. Yes, it's a framework with overhead. Yes, it gets misimplemented frequently. But the core insight, that you need portfolio-level coordination without it destroying team autonomy, is valid. The execution is often poor, but the problem it's trying to solve is real.

Planview have an honest guide on agile portfolio management that acknowledges the tensions without pretending they don't exist. Refreshingly honest compared to most vendor content.

We went with a different approach, instead of tool consolidation, we reduced what we actually needed at portfolio level. Rather than tracking every story and sprint, the PMO only looks at three things per team: what's the team's current focus, what dependencies do they have on other teams, and what risks are they carrying that need escalation.

Teams update a one-page view fortnightly. The PMO aggregates it. Takes about 15 minutes per team. Not perfect visibility but it's data that's actually trusted because it's not buried in tool noise.

Marloes, the "less data, more trust" approach works until you need to make a resource decision across teams and the one-pager doesn't have what you need. I've seen that approach collapse at the point of stress: a major delivery risk, a budget cut, a request from the board for detailed status.

Lightweight reporting is great when things are calm. When things aren't calm, you suddenly need the data you didn't collect.

Bas, that's fair. The answer we found was to have a lightweight regular cadence but a well-defined "escalation pack" format that teams can produce quickly when needed. It's not maintained continuously; it's produced on demand. So you get the low overhead most of the time and the detail when you actually need it. Not ideal but it's a workable compromise.

I want to return to something Daan said earlier about the problem being real even if SAFe's execution is poor. I agree the coordination problem is real. My issue is that PMOs and agile frameworks tend to solve it by adding structure rather than by actually improving trust between teams. If teams trusted each other and shared context freely, most of the portfolio overhead would be unnecessary. But building that trust is harder than buying a tool or implementing a framework, so we default to the tool.

Joost, that's true and also a bit utopian. High-trust, context-sharing organisations do exist, but they tend to be small or have been through something that forged that culture deliberately. Scaling trust is hard in a way that scaling processes isn't. I wish the answer were "just build more trust" but in practice most organisations need structure to compensate for the trust they don't have.