# 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？ — 工程師血淚史

- 作者：林鼎淵（Dean Lin）
- 網址：https://deanlin.net/blog/202207/scrum-master-vs-pm/
- 發布：2022-07-12
- 主題：團隊合作
- 系列：工程師血淚史
- 標籤：Scrum、Scrum Master、Project Management、Agile、Coworking
- 摘要：在過去的文章中有提到，為了提高團隊成員在 Scrum 的參與度，我們改成輪流擔任 Scrum Master 的機制，但這樣真的有效果嗎？而且 Scrum Master 跟 PM 的工作高度重疊，要如何區分兩者的權力與責任呢？

在[過去的文章](https://deanlin.net/blog/202205/team-development-problems/)中有提到，為了提高團隊成員在 Scrum 的參與度，我們改成輪流擔任 Scrum Master 的機制，但這樣真的有效果嗎？而且 Scrum Master 跟 PM 的工作高度重疊，要如何區分兩者的權力與責任呢？

這篇文章將與您分享我們是如何調整，以及調整後發生哪些改變。

> 本文提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

```
大綱
ㄧ、調整的目的是什麼？
二、定義 Scrum Master 跟 PM 的權限
  ➤ Scrum Master
  ➤ PM
三、調整後發生哪些改變
  ➤ 成員對專案、團隊有更深刻的認知
  ➤ Scrum 參與度提升
  ➤ 回顧時發表更踴躍
四、總結

```

## ㄧ、調整的目的是什麼？

明明跑的是 Scrum，卻沒有團隊合作的感覺。

每間公司跑 Scrum 的方式與目的不同，有些 Scrum 跑起來更像是傳統的工作匯報；即使在身處在同一個會議中，卻只有主管跟 PM 關心每個人的工作內容。

如果團隊成員不關心彼此的工作內容，單獨匯報或是用紙本報告其實更加省時；開 Scrum 的目的是希望大家了解彼此的任務，確認是否有需要調整的地方，避免任務的先後順序、優先度搞錯，導致專案進度延宕。

但如果只是口頭上說希望大家積極參與，實際效果就跟老師要學生好好聽課一樣，因此想透過流程來進行改善。

而我們選擇的方案是 — 讓團隊成員輪流擔任 Scrum Master。

## 二、定義 Scrum Master 跟 PM 的權限

**我們希望在提升成員參與度的同時，盡可能不要增加負擔。**

因為 Scrum Master 的工作內容與 PM 高度重疊，如果沒區分好彼此的界線，勢必會導致其他成員的困惑，比如：

1. 開單要找誰？
2. Sprint Planning 的規劃由誰負責？
3. 需求規格由誰來寫？

所以我們做了如下區分：

### Scrum Master

1. **主持 Daily Scrum Meeting**：了解每個人工作的進度、預計要做的事、以及遇到的問題。
2. **主持 Sprint Review、Retrospective 會議**：讓大家報告在這個 Sprint 中做了什麼，有哪些好的可以繼續保持，有哪些壞的要進行調整。
3. **參與 Sprint Planning 會議**：了解下個 Sprint 要完成的事項。

### PM

1. **專案管理**：追蹤成員的進度、討論需求、協調資源…原則上工作內容不變，只是部分工作交由 Scrum Master 主持。
2. **輔助 Scrum Master**：儘管已經簡化許多 Scrum Master 的工作，但因為部分成員並沒有接觸過敏捷開發，因此需要幫忙拾漏補遺。
3. **規劃 Sprint Planning**：無論是規劃要完成的工作，還是與每位工程師確認工時，都是需要花費不少心力的任務，因此主要還是由 PM 專職處理。

> 之所以這樣設計，是希望成員在擔任 Scrum Master 的同時，儘可能不影響到他的本職工作，我們期待這樣的流程可以讓每位成員更融入專案，而不是取代 PM 的工作。

## 三、調整後發生哪些改變

目前實行了 3 個 Sprint，成員的接受度還算高（希望不是敢怒不敢言 😅）。

### 成員對專案、團隊有更深刻的認知

不管是否願意，主持 Daily Scrum 時一定要了解每個人具體的狀況；原本專注在自己任務的人，也會因為主持 Sprint Review、Retrospective 而強迫了解整個專案，並更加認識團隊。

### Scrum 參與度提升

因為 Scrum Master 是輪流的，如果我今天不給你面子好好聆聽跟報告，下次換我當 Scrum Master 時可能大家會不理我；同儕間的心理因素會讓參與度變得更高（但這個情形未必適用在每個團隊身上）。

### 回顧時發表更踴躍

由成員來做 Sprint Retrospective 時，大家相對來說更敢發表意見；這就跟同學分組討論時比較熱絡，但當老師問同學有沒有問題時，台下直接靜音的道理一樣。

## 四、總結

**花的時間越多，就會越認真投入。**

其實並不是每位成員在剛開始的時候都願意跑 Scrum 的，因為他們覺得這是在浪費時間、單純走一個形式、對專案沒有幫助…

因此初期更像是每天集合匯報工作，直到要輪流當 Scrum Master 時，因為無法拒絕，所以每位成員都一定要有所了解，而這個過程促使團隊往好的方向發展（應該 🤔）。

當然還要更多時間來驗證，相信每次的 Sprint Retrospective 都能讓原本的流程更加完善。

> 如果讀者有敏捷開發的經驗，歡迎留言分享，你的留言或許可以幫助到其他人。

```
工程師血淚史
 團隊在系統開發上遇到了哪些問題
 需求不斷變更，到底哪個環節出錯了
 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？(本篇)
 如果沒有明確的開發流程，團隊將會無所適從
 你知道對專案來說，README.md 有多麼重要嗎？

```

---

關於作者：林鼎淵（Dean Lin），台灣的生成式 AI 企業內訓講師、外商資安公司軟體專家，也是生成式 AI 創新學院發起人。出版 7 本書（包含全台第一本 ChatGPT 應用專書），兩度獲得 iThome 鐵人賽佳作，累積上百場授課與顧問經驗。（https://deanlin.net/about/）
引用時請附上原文網址：https://deanlin.net/blog/202207/scrum-master-vs-pm/