有一个非常普遍的误解,公司在选择“敏捷”或者“瀑布”的开发流程时只能做二元互斥的选择，导致的结果就是一些公司会试着让他们的业务和项目严格遵循这种模式到一种极致的状态。而正确的解决办法应当是让开放方式去适应业务需要，并且很多时候，两种开发方式应当兼而有之。出于这种考虑，所谓的“敏捷组织”其实并没有标准的模式，而且PMO（如果企业设置的话）并没有一个标准的角色定义。一般来说,任何PMO都有责任去最大化组织内部项目组合的投资回报率，他们通过以下方式去达成：通过选择对业务可能带来最高回报的一揽子项目，从而促进项目组合的管理过程。这种情况下，PMO扮演了辅助（facilitation)的角色——而商业赞助商则是整个项目管理过程的真正决策者。
作为一个管理和汇报项目进度的焦点，PMO有职责去核实所有项目是否都在达成目标的正轨上运行。这个角色的重点是经常跟踪项目成本和计划的目标。规范并贯彻项目管理的流程，从而确保项目得到妥善管理并且切实符合公司的业务目标。总的来说,当一个组织向敏捷化做出方向性改变时,PMO的角色(如果存在PMO)也需要进行如下改变: 项目组合的管理过程将变得更加动态，而且业务机构可能会取代PMO,在管理过程中发挥更直接的作用。PMO会继续发挥在汇报项目进展时，担当对数据进行修缮巩固（Consolidating)的角色,但这个角色完全可以被合适的项目管理工具所取代，从而使项目团队可以跟踪和报告自身项目的进展。同时，整个管理重心也很可能会从对成本和时间的管理转向更注重提供切实的业务价值。PMO不再像从前一样那么注重成为“过程的强制执行者”，而更像是扮演顾问支持的角色，确保整个过程支持团队发挥最大的作用。目前，大多数的IT组织都敏捷化了。敏捷改变了人们的工作方式，不仅仅是开发部门，而且还包括其它的部门，例如HR、财务以及PMO等。组织敏捷带来了一些影响，例如业务单元有偏差、项目组合规划不满足敏捷的步调，以及项目管理办公室不知道如何支持敏捷团队。在大多数组织中，PMO是一个控制体。它指导项目团队的规范、模板以及流程。
一个经典的PMO突然必须处理敏捷项目时都会表现相同的方式。他们会解释PO或者Scrum需要准备每个月的项目计划。为了做到这一点，他们需要在企业工具中填写他们的项目计划，基准线是现在，并且项目可以很详尽地被管理。当PO或者SM解释说他们没有项目计划，但他们有优先级的产品待办列表，PMO会温柔但很坚定地要求他们将其转化成甘特图。在下个月的项目计划中，PO会显示甘特图，并且慢慢地会改变他的行为。在敏捷社区中很多人都会说在敏捷和精益的环境中没有PMO的角色，因为PMO的整体概念与敏捷不一致。整个想法是基于陈规的PMO角色， 即PMO在选择与管理项目和项目集的执行上，主要与控制和执行严格的瀑布式策略有关。他提到，在敏捷环境中，PMO更倾向是顾问与咨询的角色而不是一个控制角色。项目中提供项目方向变化的主要职责更多地在产品负责人所代表的业务这边，并且他们与业务这边有更加紧密地耦合，更加重视提供业务价值，而非简单地管理项目成本和进度。在敏捷组织中，PMO需要遵循如下措施： 1、要求PO为主要的项目驱动人员——对该项目最重要的是什么?我们是否有计划发布的最小范围?2、要求PO为产品代办事项负责——产品代办事项是否健康，是否做过估算，是否有优先级?3、提供PO敏捷发布计划(Release Planning)工具——PO应该能够根据产品代办事项绘制发布的燃起图。这会给他(以及项目计划)对该项目评估的一个很好的预览，一个迭代接一个地
迭代，并且促进敏捷式的思考，发布产品增量直到实现足够的商业价值。因此说，PMO能够在敏捷计划中扮演重要的角色。