最近看到一篇很有趣的文章 "Overcoming Four Common Objections to the Daily Scrum"，裡面提到常見反對 Daily Scrum 的幾個理由，以及 Daily Scrum 帶來的價值，想起公司剛導入這個制度時也常聽到來自團隊質疑的聲音，讓這個會議差點不到一個月就夭折，在我的堅持下邊做邊調整，經過兩三個月才慢慢領悟 Daily Scrum 的價值所在，以下我結合文章的內容，外加這些年的實務經驗，讓我們一起來探討一下這個問題。
常見反對的四個原因：
重要的事情沒有被討論到：據說另一個常見反對 Daily Scrum 的原因是團隊成員認為過程中都沒有談論到重要的議題，關於這個現象可以思考下列兩點：
- 設立預期：由於 Daily Scrum 是每天開，以一個運作上軌道的團隊來說，本來就不太可能每天都有重要議題要討論，但正因為它是每天例行的會議，所以確實是捕捉很多議題的第一線警報器，把問題拋出來，至少讓其他人都意識到有這件事（例如：我的工作環境常被打斷），未必當場能解決，但至少開啟大家一起思考，或讓 Scrum Master 著手處理。
- 可能這是個警報：如果有這樣的呼聲，也可能反映了 Scrum Master 沒有在掌控會議的進行，例如：放任成員隨意漫談、沒有試著收斂討論議題，讓會議進行時間過長，以我的主持風格來說，我希望 Daily Scrum 是輕鬆但有效率的，可以小小的閒聊（也是一種 Team Building），所以當我發現一個話題拖太久時，還是會即時收尾。
不能用 Email 就好嗎？這個基本上是較無爭議的，Sprint 強調面對面的實時溝通，Email 完全無法取代（你多久才看一次 Email？），即使是 Slack 這種即時通訊工具也是，會導致對議題較不 responsive，面對面聊的化學作用也將完全喪失。
會議花太久時間：聽到這個意見時，Scrum Master 可以先檢查看看，是否有把會議控制在 15 分鐘左右，若否，則這可能是一個超時的警訊，因為大部分跑 Daily Scrum 的團隊都建議標準時長為 15 分鐘。
但若已經是在 15 分鐘以內，則可以列舉 Daily Scrum 的價值後，反問提出問題者覺得多久才恰當，例如：「你覺得如果要保持團隊同步、避免溝通問題、讓彼此互相了解正在進行的工作、界定並修正錯誤、建立信任，一天需要花多少的時間才是合適的呢？」
該文章也提到理想的 Daily Scrum 應該遵循下列原則，我一樣先列出來，後面加上一些自己的看法：
- 每天在同時、同地點舉行且準時開始：這點沒有爭議，確實應當如此。
- 不要超過 15 分鐘：站立會議有助於讓與會者節約時間這點沒毛病，然而我後來考量到有時候要把東西投影出來，所以都是坐著的，但我會有意識地控制時間和話題。
- 會議上只會蒐集問題，但不解決問題：若較為緊急，會後可以請相關人員留下來再把議題討論完，我的確是這麼做，除非該議題和所有人相關（通常關於團隊文化）。
- 與會者保持在主題上：只講昨天完成了什麼，今天預計要做什麼，以及什麼事情影響到他們的進度。如同之前說的，我不反對團隊成員簡短的分享自己最近的工作心得，所以我們可能偶爾會有小小的離題，但每次都盡量控制在五分鐘以內（包括我自己），考量到凝聚出的團隊共識，我目前的觀察是多這五分鐘利大於弊。
- 正確的意識：Daily Scrum 是團隊成員彼此報告進度，而不是對 Scrum Master 報告，所有團隊成員也應該意識到要共同維持會議的進行品質。這點實際執行起來不容易，因為幾乎每一件事情都只和某幾位成員比較有關，就難以避免其他人覺得自己比較插不上話，而身為主持人，我總是會盡可能「積極聆聽」，消化、問問題、互動，所以會顯得好像是每個人輪流向我報告，不過只要是遇到和多個人相關的議題，成員們就會自發性的加入討論，所以我覺得就結果論來說，這樣的模式是好的，且，若每個人都非常積極聆聽和自己沒那麼相關的議題真的好嗎？希望可以看到更多的討論。
- 全員參加，且只有全員：團隊以外的人僅允許以觀察者的身份參加 Daily Scrum，等到會議結束後 Scrum Master 再詢問他們是否有任何問題或意見。我們的 Daily Scrum 鮮少有部門之外的人參加，來參加者多為其他部門的同事，他們只是想了解 Daily Scrum 究竟是怎麼進行的，過程中也很自然的只聽，最後再講自己的想法，所以較無問題。
好了，這次的分享就到這邊，歡迎你在下方留言告訴我你的團隊舉行 Daily Scrum 的經驗喔！
留言
張貼留言