Agile PMO

“Project” 一詞，儼然成為 agile 及 DevOps 圈子的禁語。

譬如說，敏捷祖師爺 Martin Fowler 的網站有一篇 “Products Over Projects” 文章，DevOps 巨著 The DevOps Handbook 第 7.7 節的篇名叫做〈投資於服務和產品，而非專案〉。最近甚至還有一本新書，直接取名叫做 Project to Product 叫人棄暗投明呢。

見微知著。這個圈子，褒 product，貶 project，是政治正確的常模。 ¹

這個圈子，對於 “project” 反感，對於素來予人控制與監管印象的 “PMO” (Project Management Office，專案管理辦公室) ² 就更反感了。

但 PMO 真的與敏捷水火不容嗎？

敏捷陣營的聲音

聽聽看 Scrum 領域三位大神的說法吧。

頭兩位大神 Jeff Sutherland 及 Ken Schwaber 是 Scrum 發明人。他們合著一本小書《告別瀑布，擁抱 Scrum》，言簡意賅，完全是務實的經驗談。附錄Ｃ〈企業級敏捷攻略〉專門探討敏捷擴展的議題，難得看到兩位老爹發表與其他基本教義派不同的接地氣觀點。其中對於 “project” 的看法是：

Scrum 避免使用傳統的「類」瀑布式的專案計畫，但是策略性的日常專案管理的本質是堅定不移的。高級成員需要觀察每個團隊各自的 iteration 和發佈計畫，才能全面的評估整個專案所處的狀態。

他們也進一步闡述遠光燈的觀點：

Scrum 是追求「近期可能性的藝術」，而不是詳細預測未來 6 到 12 個 sprints 內應該交付什麼的黑色藝術。但隨著團隊的擴大和增加，為了未來較遙遠的 sprint 做額外嚴謹的分析，將有助於避免日後需要對架構做過多的重構。為了能將系統架構未來可能的演變方向看得更清楚，進行額外的發布計畫也是合適的。因此，sprint 計畫會議中，可以「看看過去的幾個 sprint」，也可以進行一些「萬一」(what-if) 的計畫，如此將能夠協助團隊權衡產品待辦清單，並向發起者傳達一個更合理的願景和產品路線圖。

Ken Schwaber 創立的 Scrum.org 培訓機構，也刊登過一篇 “The Agile PMO” 文章，說明他們對於 PMO 並未排斥。

第三位大神 Mike Cohn，是 CSM/CSPO/CST 等認證的主辦機構 Scrum Alliance 的共同創辦人，著作等身，都是敏捷領域的經典 ³。最近也在他的機構 Mountain Goat Software 開辦很精彩的 Better User Stories 線上課程，是非常活躍的 Scrum 培訓師。

在敏捷領域，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.

  — “Is It Time to Stop Thinking about Projects?”

畢竟 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.

  — “Advice on Conducting Agile Project Kickoff Meetings”

三位大師的論述，像極了《神鵰俠侶》中「不滯於物，草木竹石均可為劍」的境界，大師風範，令人佩服。

PMO 陣營的聲音

也來聽聽看 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” 呢。⁴

正名？

敏捷陣營常會對 “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.

  — “The Roles of the Project Management Office in 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” 是噱頭嗎？