“Project” 一詞，儼然成為 agile 及 DevOps 圈子的禁語。
見微知著。這個圈子，褒 product，貶 project，是政治正確的常模。 1
這個圈子，對於 “project” 反感，對於素來予人控制與監管印象的 “PMO” (Project Management Office，專案管理辦公室) 2 就更反感了。
但 PMO 真的與敏捷水火不容嗎？
聽聽看 Scrum 領域三位大神的說法吧。
Scrum 避免使用傳統的「類」瀑布式的專案計畫，但是策略性的日常專案管理的本質是堅定不移的。高級成員需要觀察每個團隊各自的 iteration 和發佈計畫，才能全面的評估整個專案所處的狀態。
Scrum 是追求「近期可能性的藝術」，而不是詳細預測未來 6 到 12 個 sprints 內應該交付什麼的黑色藝術。但隨著團隊的擴大和增加，為了未來較遙遠的 sprint 做額外嚴謹的分析，將有助於避免日後需要對架構做過多的重構。為了能將系統架構未來可能的演變方向看得更清楚，進行額外的發布計畫也是合適的。因此，sprint 計畫會議中，可以「看看過去的幾個 sprint」，也可以進行一些「萬一」(what-if) 的計畫，如此將能夠協助團隊權衡產品待辦清單，並向發起者傳達一個更合理的願景和產品路線圖。
在敏捷領域，Mike Cohn 雖然是祖師爺等級的人物，但不是基本教義派。譬如說，雖然 “project” 一詞儼然成為這圈子的禁語，但他可不這麼認為：
Projects provide a planning horizon that is longer than a sprint—typically in the range of two to six months. This “definite beginning and end” that is focused on a “unique product, service or result” encourages product owners to select truly important things to work on rather than whatever some customer or salesperson screamed about yesterday.
I always encourage product owners and their teams to identify a milestone they are working toward that is longer than a single sprint.
Projects remain a useful construct. They provide a motivation to accomplish something grander than could be done in a single iteration.
畢竟 milestone 這種策略控制點的設置與控制，原本就是專案管理知識體系的擅長之處。
他甚至鼓勵將傳統上 PMBOK 重視的某些活動，引進敏捷開發的節奏中：
Becoming agile does not mean we need to throw out everything we’ve learned over the past 100 or so years of doing project management. Some things—project kickoff meetings included—remain valuable.
Risk management is not formally defined as part of agile frameworks like Scrum. And that’s understandable as a lot of risks do go away (or get exposed) with the short iterations common to agile. But there are still projects that benefit from lightweight but explicit risk management. I suggested starting that during the kickoff meeting.
也來聽聽看 PMO 領域的說法吧。
PMO 並不是像敏捷基本教義派陣營口中那麼僵化守舊的。像 2013 年《業務驅動的 PMO 最佳實踐》一書主張，有成熟敏銳度 (maturity acumen) 的 PMO，需要根據專案類型與管理方法兩個維度，將組織層級的專案管理分成四個象限，並以宏觀視野統籌處理：
至於最正宗的專案管理國際組織 PMI 是怎麼想的呢？
在 “An agile PMO transformation” 一文中，列舉 “agile PMO” 的「八要八不要」，並且主張：
For many organizations, using the words “PMO” and “agile” in the same sentence could be considered an oxymoron. It may come as a surprise to expect the PMO to lead the agile transformation, but we think that for organizations to reach the full potential of the approaches outlined in this update, such as managing the enterprise-level portfolio and creating stable teams, the PMO will need to be engaged and lead the way.
If PMOs are ready and willing to transform, they can greatly influence the success of their organization’s agile transformation.
可見，狀似傳統僵化的 PMO，其實也已經正視敏捷變革。因此，我們不時可看到新名詞 “agile PMO” 出現，連管顧公司也湊熱鬧湊出一個 “Lean-Agile PMO” 呢。4
敏捷陣營常會對 “agile PMO” 一詞嗤之以鼻，認為只是換湯不換藥。
因此，Mike Cohn 挑明地說，為了避免困擾，不妨考慮換個名字：
A project management office (PMO) that is engaged in and supportive of transitioning to Scrum can be a tremendous boon.
Many PMOs choose to rename themselves to better match their revised role. Though there is no one standard name, I have heard these most frequently: Scrum center of excellence, Scrum competence center, Scrum office, and development support.
Many people have become cynical and suspicious of name changes and of well-crafted names. That cynicism will be directed at the PMO if it is renamed but remains otherwise unchanged. So, whatever it’s called, the PMO that supported the organization’s sequential development process will need to change more than just its name to succeed with Scrum.
PMI 在 Agile Practice Guide 第六章也提及 “center of excellence” 一詞：
Some organizations have been transforming their PMOs into agile centers of excellence
至於崇尚極簡作風的 LeSS 陣營，則主張廢棄 “project” 或 “office” 字眼，改用 “Head of Product Group” 概念，以及 “Go See” 管理：
No project/program organization or project/program management office (PMO). No support groups such as configuration management, continuous integration support, or “quality and process”.
Head of the Product Group — Most LeSS organizations still have managers including a “head of product group.” They support the teams by Go See and help them remove obstacles and improve. LeSS organizations don’t have matrix structures and there are no “dotted-line” managers.
“Head of Product Group” is called differently in different organization, here we mean the hierarchical manager of all the teams.
— LeSS Organizational Structure
看了這麼多論點，你認為 “agile PMO” 是噱頭嗎？
Mike Cohn 在敏捷領域的名作：User Stories Applied: For Agile Software Development (2004)、Agile Estimating and Planning (2005)、Succeeding with Agile: Software Development Using Scrum (2009)。 ↩︎