如果你在軟體公司當中擔任 PM 職務，你的公司還沒有導入 Scrum 的話，你應該要導入 ，而且馬上就要。
一來，像是 Scrum 啦、XP 啦、敏捷開發啦、精實創業啦…雖然已經在國內外都已經講了好幾個年頭，但對很多人來說還是新奇的 Buzzword，導入這些號稱高效的工作方式，應該有助你提昇績效；另一方面，在 Scrum 裡頭「沒有 PM，只有 PO（Product Owner）」這一點，如果被錯誤解讀的話，那實在是種危險的想法，簡直就是思想的毒瘤。
如果改天有人不明就裡，也說要導入 Scrum，那麼，「沒有 PM，只有 PO」，就可能會讓公司誤以為可以開除所有的 PM，抹煞你多年來的貢獻，叫我們回家吃自己 — 我們絕不容許這樣荒唐的事情發生。與其消極地防堵有人提出這樣的想法，我們更應該主動出擊，先下手為強，率先主動導入 Scrum，並且要主導對 Scrum 的話語權，把持對 Scrum 的詮釋權，把 Scrum 變成我們想要的樣子。
我們要趕快要求公司打散原本的各部門，把人員編入多個小組，然後由我們 PM 來親自擔任每個小團隊的 PO－沒錯！「沒有 PM，只有 PO」真正的意思就是：導入了 Scrum 之後，PM 就會變身成 PO。PM 與 PO 這兩個名詞都是 P 開頭，而 M 與 O 這兩個字母在英文裡頭中間只差了一個 N，只要導入 Scrum，PM 就會自動升個兩級，變成 PO。
接下來才是挑戰的開始：你要能調和各種衝突的成分，兼融舊觀念與新作風，將績效管理與 Scrum 做一番完美的混搭。
你發現，就算你把職稱變成了 PO，但你好像沒辦法照著書本、或是那些貴森森的 Scrum 課程裡頭所講到的 PO 那樣行事，你的主管、更上層的老闆還是習慣你應該要有作為 PM 的產出，展露作為 PM 的績效。書本裡頭說，PO 不應該花時間做文件，因為 PO 擁有整個產品的最終決定權，應該要花時間思考產品、定義產品的價值（當初你學到不用做文件的時候，內心還不禁竊喜一番）。可是呢…老闆還是想要看到企劃書與投影片，所以你還是得做企劃書與投影片。而且要做什麼產品，做成什麼產品，你上頭還有好幾層的老闆可以隨時推翻你的決定。
即使如此，你還要表現出你在導入 Scrum。看來你只有一種方法，就是：Scrum 說要做的事情，我們都去做，Scrum 說不要做的事情，一樣都要做。
我們先來搞定團隊組成的問題。首先，由於公司原本人數的關係，所以沒有辦法讓每個 PM 變成 PO 之後，都可以有自己的一組人馬，導致我們得要把多個原本的 PM 放到一個團隊裡頭。說起來，如果我們把一些原本的 PM 放到新的團隊中的時候，變成其他 Scrum 需要的角色，像是擔任 Scrum Master，就可以解決、或紓緩問題，但我們不能這麼做。
教科書上說，Scrum Master 這個角色本身不負責開發過程中的實際工作，而是要從旁擔任教練的角色，觀察團隊成員，發掘團隊的問題，確保團隊中的成員都能遵守 Scrum 的遊戲規則，在開發過程中不被小問題卡住，讓整個團隊的 Scrum 運作順暢 — 這種角色實在是太沒績效了。就算兼任，也會影響我們拿來做投影片的時間，而且徹底違反 PM 在導入 Scrum 之後就會變身成 PO 的基本原則。就算我們當初為了證明我們具備在公司內導入 Scrum 的能力，我們都還去上了課，拿了 CSM 證照，但是，我們不可以當 Scrum Master。
換成讓來自其他部門的成員擔任 Scrum Master 呢？奇怪，沒有人想當，不知道是誰把 Scrum Master 沒有績效這種秘密洩漏出去的。也罷，讓外人擔任 Scrum Master，豈不是白端端把到手的 Scrum 詮釋權拱手讓人？讓菜鳥 PM 來當 Scrum Master 呢？雖然可以有效降低新人的績效，但是讓新人對你怎麼跑 Scrum 指指點點，想起來也不怎麼舒服，那還是來當 PO 吧，就算你到職不到兩個星期，我們也勉為其難讓你一起來 own 這個產品。
於是我們的成員名單拍板定案：在一個大概十個人左右的 Scrum Team 當中，有四個 PO，沒有 Scrum Master。四個 PO 也不可以相互代理，免得搶了彼此的績效。
這跟書本講的不一樣，但做事不應該墨守教條，每個團隊都應該要摸索出一套適應自己的方式，這就是我們的方式，這就是我們的 Scrum。
來跑第一個 Sprint 吧！因為我們要導入 Scrum，所以，Scrum 裡頭提到的所有會議，我們統統都要開。在每個 Sprint 開始的 Planning Meeting，每天的 Daily Standup Meeting、每個 Sprint 結束之後的 Review 還有 Retrospective Meeting，當然統統都要開，不開這些會，怎麼算 Scrum。
首先，我們要在 Sprint Planning Meeting 裡頭，決定這個 Sprint 要做哪些事情 — 或 Story，管他是什麼－不過，請注意，決定要做哪些事情的時候，不代表我們也就決定了這個 Sprint 中不做哪些事情。而且在列出每個 Story 的時候，書本上面教我們要用順序排列，讓開發團隊一件事情做完才去做另一件，而不是只有優先程度 — 這是完全錯誤的。我們的待辦任務都只有優先程度，而且每件事情的優先程度都是最高。
在我們的 Backlog中，有些是來自老闆的直接命令，有些是董事會的指示，有些是直接來自客戶的意見，我們不應該妄自對不同的人做先後高低之分，決定誰比較重要，我們對待所有需求都該保持相同的謙遜，這種謙遜是我們最重要的美德與智慧，甚至是職場上的求生本能：你非要在老闆跟董事會之間決定個順序，搞不好還惹上一身腥，捲入台灣公司常見的公司派與法人派之間的鬥爭呢。
我們在週一開了 Sprint Planning Meeting，週二就可以去另外一個例會上，跟老闆的報告我們接下來這個 Sprint 要做那些 Story，話說要在兩個會議之間趕快做好新的投影片還真是不容易。這時候我們可能突然收到來自行銷部門的新需求，像是下個月我們安排了一場大型的行銷活動，電視廣告時段、記者會時間場地都已經安排好了，為了配合行銷活動，我們必須馬上在產品上做出相對應的調整，時程呢，ASAP。
這時候其實可以凸顯出 Daily Standup Meeting 的好處，Scrum 教科書裡頭有很多東西是我們不要的，但這個會議是個好東西，提供了我們高速調整產品方向、修改產品規格的卓越機動性。 — 像 Retrospective Meeting 就味如嚼蠟，這個會議是在每個 Sprint 結束的時候，讓團隊成員提出問題，雖然這個會議可以讓我們有機會解決提出問題的人，但他們不該有問題才對。
回來說 Daily Stand-up Meeting。在這個所有成員都要參加的每日會議上，每個人都要報告昨天各自做了什麼，完成了什麼，工程師報告的部份其實我們可以直接略過，反正我們都聽不懂，不重要。重點是我們的部份。
在週三早上的會議上，我們可以報告昨天跟老闆討論了什麼，老闆又指示了什麼，這時候團隊應該要馬上協助 PO 估算出所需的開發時間，回報什麼時候可以上線。
對了，其實昨天老闆有想到一個點子，其實這件事情不急，老闆指示回去想一下再慢慢討論，那我們下午也再來敲個會議，討論看看可以怎麼做吧！
一直以來你都覺得工程師是一種奇怪的生物，我們都是非不得已，才會找工程師加入必要的會議，但是他們居然都還在抱怨一直都在開會、都在討論，沒有時間寫程式，這明明就是很簡單就能解決的事情，只要加班就好啦，為什麼不配合加班呢？說什麼工作的時候一直被打斷、一直 context switch 很花成本，晚上就不會有人打擾你啊？台灣從來就沒有過勞死的問題，如果有，那也是本來就有病。
我們都要加班才能把企劃書、規格書、投影片做出來，為什麼你們不該留下來加班寫程式？
才這麼一點會議就拒絕配合，這樣團隊要怎麼充分討論，凝聚共識？你們知道我們要開多少會嗎？你們知道光是四個 PO 之間要討論資源分配，就要花上多少時間嗎？
有時候老闆也會關心 Scrum Team 的狀況，照理說他應該要去問 Scrum Master 才對，因為 Scrum Master 才是確實從旁觀察團隊狀況的角色，不過，差點忘了我們沒有 Scrum Master，那就只能問你了。
你能怎麼回答？你只能說好啊！頭都已經洗下去了，不然你導入 Scrum 的價值何在？你對 Scrum 的詮釋權怎麼辦？你的績效怎麼辦？
你要說，不同部門之間的隔閡被消除了，討論更熱烈了，每件工作要怎麼做，都有一個經過團隊討論過的結果。不過千萬別告訴老闆：團隊討論出來的這個結果，每每都被你推翻；你剛剛推翻的，就是團隊討論出來的成果。
在一番混搭之後，有時候你都搞不清楚這到底是怎樣的團隊了，你甚至在想是不是應該要說這個團隊是個 Scrum Team，但做人一定要莫忘初衷，你還是要記得你是為了什麼導入 Scrum，不管選擇幾次，你都要選擇導入 Scrum，而且馬上就要。
不管這樣的團隊最後變成怎樣的團隊，被稱作什麼名字，你要記得你是 PO。你不是舊時代的 PM，你是新世界的 PO。
我們有很多地方跟書本講的不一樣，但做事不應該墨守教條，每個團隊都應該要摸索出一套適應自己的方式，這就是我們的方式。
這就是我們的 Scrum。