一切PO說了算? 權力不對等下的Scrum樣貌

[討論] 大家會很在意做出來的產品好不好用嗎?

身為一個愛潛水的鄉民，有時總會在海面下發現有趣的地形地物，在3月時偶然在PTT上看到這一篇文章，有種身歷其境的既視感，就想和各位讀者分享一下，也一同討論在實踐敏捷的過程中，大家可能會遇到的窘境和議題，並想想有什麼方法可以讓團隊更接近敏捷想要的狀態。

敏捷教練的視角

由於該篇文章並沒有特別提及Scrum Master面對RD所遭遇情況時的做法，我特別以一位教練的身分先點出幾項從文中所感受到的情境 (RD的內心os)。

1. 等需求全數盤點後，再作後續修改

針對第一點，我相信對Scrum有一定程度理解的人而言，會知道敏捷開發本身是一項價值驅動(Value Driven)的開發模式，用更簡單的話來說明，每次Sprint Planning時，PO必須和所有成員溝通當前需求變動的狀況，並說明各項待辦項目背後所具有的商業價值，並和團隊成員討論決定該sprint需要選擇哪些項目，可以最大化市場價值。

單單從文章的敘述來看，團隊貌似陷入瀑布式敏捷 (Waterfall-like Scrum)的場景，這個狀況的成因可能來自團隊成員會很直覺式地用過去工作經驗繼續處理Scrum框架下的各類活動，而Scrum本身是應用在未來需求變動不明的狀況下持續迭代，測試用戶及市場反應再調整自身的開發步調。這樣的矛盾狀態下就會出現文章內所看見的壞味道(Bad Smell)。

若要改善這類現象，Scrum Master必須與Product Owner溝通討論改善方式，例如用一頓飯的時間和PO釐清他對需求處理以及Scrum的做法差異，畢竟PO可能並未完全理解Scrum各類活動的意義，因此在導入的過程中教練有義務持續提醒PO抓住它的核心概念，另外在Sprint Retrospective中開發團隊也可以點出這個議題，持續優化PO與開發團隊間的合作關係。

2. 公司風氣是由PO說了算

這類問題對多數人而言就會是比較敏感的議題，尤其是身處在亞洲國家，我們容易被教育成服從權威，因此即便是Scrum Master，在面對公司文化如此的狀況下，也不一定願意(或敢?)花力氣處理這類問題，回顧Scrum框架下的活動，難道這真的沒有解嗎? 其實不然，Scrum還是有給出工具。