Standup Meeting Explain (站立會議)

[Aiko]

7 Tips for Improving the Daily Scrum

http://agilesoftwaredevelopment.com/blog/artem/7-tips-daily-scrum

1. 所謂每日站立會議, 就是要站著舉行, 不可以坐著
2. 保持儘可能的短, 不要超過15 分鐘
3. 要站在工作白板面前舉行, 因為其內容可以幫助討論
4. 團隊每個人都要出現
5. 不需要一直紀錄談話內容, 要專心聽對話內容
6. 專心在第二個和第三個問題, 而不是第一個.
7. 要對團隊成員報告, 而不是Scrum master

---

1.每日站立會議的成功要件

Daily Scrum 在 Scrum 流程中, 是一個重要的會議. 在 "Scrum 用一半的時間做兩倍的事” 一書中, Jeff 提到好的每日例會應該具備以下條件:

1. 每天同一時間, 同一地點舉行, 每個人都要參加
2. 會議不能超過 15 分鐘
3. 每個人要積極參與

前面兩點, 我想是大家都很清楚. 可是關於最後一點, 卻是很少有人提起.
如果你的團隊成員不積極參與, 不在意團隊會不會成功, 任何方法都沒有用.
很多團隊之所以無法把 daily scrum 實施的很好, 其根本原因, 是大家只在乎自己的事情, 只管自己做完沒做完, 可是專案能不能準時交付, 這東西能不能賣錢, 並不是他所在乎的.
你看看職棒選手, 哪個人破紀錄, 或者是拿到完全打擊, 可是球隊輸球, 他還能高興得起來. 球隊沒有贏球, 一切都是 nothing!!

所以每日立會成功的要件, 就是在於你團隊成員想贏的心態. 而關鍵是, 你如何打造出這樣的環境呢? …

2.每日立會不是流水帳

很多人不喜歡每日立會, 覺得他很無聊, 很浪費時間. 可是為什麼會這樣呢? 我想請大家思考幾個問題

1. 在不在乎你做的東西是否影響別人?
你做的東西都真的跟別人沒有關係嗎? 如果有關係, 為什麼別人不需要知道你做了什麼? 或者你改了什麼東西, 不會對他們有影響.
當然啦, 如果是負責多個專案的狀況, 或許就不該和在一起開, 應該要分開處理, 讓會議有專注性, 大家才會集中精神, 把會議給開好

2. 在不在乎專案是否成功?
你覺得專案成功, 是否會帶給你成就感? 是否會讓你覺得與有榮焉? 可是這些事情都不會無冤無故發生, 都是要你有所付出, 願意一起把它做好, 這才會發生.

3. 明明專案出了問題為何不說?
如果你常常加班加得很晚, 專案 spec 不清楚, 或是時程已經延遲,你為何不想說, 為何都只報平安. 明明你討厭官員這樣做, 可是你為何也如此呢?

4. 我們坐在一起, 所以我知道他所有事情
即使再親密的情侶, 都有可能會有對方不知道的小秘密. 有時候你覺得這些小事不重要不想說, 可是對方卻很在意. 所以你怎麼可以假設你知道同事所有事情呢?

講這些問題, 並不是要說這是誰的錯誤. 想說的一個 practice 的導入, 並不是要大家去照著步驟去實施, 而是要去思考, 當初這個 practice 想要解決的事情是什麼, 他所在的 context 是什麼? 這樣你在施行時, 你就能知道重點為何.

所以回到每日立會上面, 雖然每日立會要談的是三個問題:

1. 你昨天做了什麼?
2. 你今天打算做什麼?
3. 你遭遇到什麼問題?

其實前面兩個問題, 都是在為第三個問題鋪陳. 想要跟大家說我做了什麼會影響到大家; 我遇到了什麼狀況, 你們可能也會遇到; 我延遲了, 專案可能因為它而有風險 ……

如果你沒有想清楚它問題背後想解決的問題, 沒有轉變你的思維, 那你的每日立會就會是流水帳, 你只是在 doing agile, 而非 being agile. 你的 agile 終究有天會失敗的

---

3.每日立會報告方式

在實施 Scrum 時, 最容易被人家採用的, 就是每日立會(standup meeting). 它主要是用來同步資訊, 互相幫助, 以及儘早解決所遭遇的問題.

在我待過的團隊, 通常有以下幾種報告方式:

1. 每個人輪流報告
說明: 大家站在一起, 不管是在站在 task board 面前, 或者不是, 但是在報告的時候, 就是大家輪流講自己的部分, 並不會看 task board, 或是某個檔案.
好處: 很容易就開始, 大多數人都這樣做.
壞處: 他講的東西, 跟 task board 上計劃的東西可能不同, 但是你無法比對

2. 針對每張 task 報告
說明: 大家站在 task board 面前, 針對自己負責的便利貼, 說明處理的狀況如何
好處: 每個 task 都不會漏掉, 每個人的狀態都無所遁形
壞處:
(1) 時間可能會有點久
(2) 每個 task 做好了, 但是不知道每個 feature 到底被處理得如何

3. 針對每個功能報告
說明: 大家站在 task board 面前, 由第一個功能開始, 由負責的人解釋, 跟這個功能有關的每一張便利貼, 目前處理的狀態如何
好處: 可以知道每個 feature 被處理得如何, 從客戶關心的角度出發, 而非只是自己做完就好
壞處: 有可能會報告多次, 如果有人同時負責多個功能.

4. 針對有問題的項目報告
說明: 大家站在 task board 面前, 針對有問題的工作來報告, 通常是已經延遲的, 風險比較大, 離 deadline 比較近, 或者是優先順序高的.
好處: 比較節省時間, 不需要全部的人或事情都講
壞處: 必須事前就檢視哪些是有問題的, 才能讓大家報告

5. 由流程的下游開始報告
說明: 大家站在 task board 面前, 從下游的工作開始報告, 讓下游的工作能夠順利被處理. 也就是 stop starting, start finishing.
好處: 讓每個故事能儘快完成
壞處: 需要改變大家心態, 願意互相幫忙, 否則大家會覺得都是在處理別人的事

那個比較好呢? 個人覺得不同時機, 你要採用不同做法, 沒有所謂的標準答案. 根據你的環境和需求, 不斷演進調整, 這才是 agile 要的.

[erik]

問題導向, 看板式的每日站立會議

http://agile.luminis.nl/?p=65

我想很多團隊在執行daily standup 一段時間後, 可能會覺得這樣的事情很沒有效率, 很無聊. 這時候你必須對你的standup meeting 做refactoring.

甚麼? refactoring? 是的你沒有看錯, 雖然不是寫code, 但是還是可以做refactoring.

Refactoring是指, 在不改變對外的介面或功能下, 把內部的事情改善得更好.

同樣地, daily standup 主要目的是要即時溝通, 適時收到回饋, 及早發現問題. 對內你可以改變你的做法,

以更有效率的方法來達到相同的目的.

本文作者想出了一個方法, 來增加daily standup 的有效性. 他認為會議最主要是要處理問題, 所以他把會議形式改成問題導向的站立會議.

此外並且搭配kanban WIP 的觀念, 也就是問題的量要被限制. 要先確保這些問題被解了, 然後才加新的問題進去

source: http://agile.luminis.nl/?p=65

所以你變成要回答以下三個問題

1. Who is working on this issue? (目前誰正在處理這個問題?)
2. issue progress since last meeting + today? (這問題從上次會議到今天的處理進度為何?)
3. when will the issue move to the next lane? (這問題何時能個被解決, 然後可以移到下個step?)

做這樣的轉變後, 作者發現團隊變得更有熱情了. 此外, 另外帶來的好處是會阻擋進度的問題能夠很快被處理掉. 因此, 作者認為說不定每隔幾個iteration, 都該更換一下開每日會議的方式, 讓團隊能保持在高檔的狀態.

[erik]

人數太多如何進行standup meeting

在我們公司中, 有不少團隊是大於10個人的, 因此要進行standup meeting, 是會有點困難的. 因此有不少詢問要怎麼處理. 以下是常見的方式:

1. 全體集合 (1)
- 所有的人都出席
- 所有的人都需要回答三個問題
- 好處: 大家知道最新訊息, 彼此可以相互交流
- 壞處: 時間會拖得很長. 之後大家就會逃避這個會議

2. 全體集合 (2)
- 所有的人都出席
- 代表來綜合回答三個問題, 這個代表的分法可以是根據role(RD/QA), 專案/部門群組, 或是feature team.
- 但是其餘的人是可以提出問題的.
- 好處: 資訊依舊可以交流, 並且時間可以控制範圍內.
- 壞處:
* 沒說話的人容易不專注, 或是不在乎這個會議. 可以藉由輪流代表報告的人, 來減輕這個問題.
* 資訊內容可能較不詳細. 因為有些的狀態是別人代替報告的. 不過可以由及時問問題, 讓原先負責人加以補充

3. 代表出席
- 僅由代表參加. 這個代表的分法可以是根據role(RD/QA), 專案/部門群組, 或是feature team.
- 好處: 資訊依舊可以交流, 並且時間可以控制範圍內.
- 壞處:
* 資訊內容可能較不詳細.
* 其他人可能無法知道一手資訊. 或者經過二手傳播後, 資訊可能失真.

4. 功能群組(feature team)
- 相同群組的人自行開standup meeting. 在人數不多的狀況下, 會議可以有效進行
- 至於不同群組的溝通, 可以利用scrum of scrums, 僅由代表參加
- 好處:
* 大家知道最新訊息, 彼此可以相互交流
* 不用浪費時間在不相關的事情上面
- 壞處:
* 有時候訊息是比較局部性, 無法詳細知道別組的狀況

不管你使用哪些方法, 我個人覺得重點是要先開始做, 唯有先開始做了以後, 才能知道問題出在哪裡, 然後馬上集思廣益, 討論要如何改進. 唯有這樣, 你才會學得東西. 所以記住, 要用手體驗.

[erik]

根據 VersionOne 的調查[註1]，Scrum 中最受歡迎的的實務之一是站立會議。公司內很多團隊在導入 agile 時，都會採用這個實務。但是水能載舟，亦能覆舟。雖然它很容易被導入團隊中，但是也是聽到不少人對它抱怨連連，認為那是罰站會議，是一個無奈的活動。

到底發生甚麼事情，會讓工程師這麼沮喪呢？根據我所參與的專案，以及和別人交流後，以下是常見的困境：

1. 每日站立時間過長

有些團隊動輒要花 20~30 分鐘以上來執行，日子久了，大家會覺得這一種折磨，沒有效率, 漸漸地大家便會沒有興趣參與。

通常會這麼久，有可能是在會議中討論如何解決問題。要切記，解法是會議結束後，再由相關的人留下來談論，並不是在會議中占用所有人的時間來討論。另一種可能是團隊太大，請試著使用 scrum of scrums，根據不同的目的，找不同代表來參加。或者利用 feature team 的結構，讓組織維持 5-9 人的大小。

2. 當成 status report meeting 來執行

Status report 只是站立會議其中一小部分。重點是要提出你所遇到的困難，並且要相互幫忙來解決困難。若是只是 status report，容易發生只是報喜不報憂的狀況，會讓人誤以為專案進行一切順利。

以正常的狀況來說，專案進行都是充滿了許多不確定性，有許多事情你需要假設、求證或是提出疑問。這些事情若是能及時提出，別人也可以即時給你意見，你也才能及時修正。如果大家只是流於形式化的狀態回報，這只是在粉飾太平。

此外，每日站立會議還需要修正 task board 上面的 task (也就是隨時修正計畫)，像是從 To do List 中移到 In Progress，或是從 In Progress 移到 Done 等等。否則常常有人會覺得雖然每天開會，但是還是無法確認工作是否已經做完了。此外，在這 task 移動過程中，可以適當地利 用同儕壓力，來促使大家遵守承諾。

3. 除了每日站立會議之外，還有每周會議
很多團隊在執行 agile 的作法，是除了原先要做的事情外，再加上 agile 的活動。這時候不管這些事情性質是否重複，用意是否良好，同仁都會抱怨事情做不完，以及質疑 agile 是否真的那麼 agile。

像每周會議，當每日站立會議有在進行時，便可以不用再執行。當然啊，相反地，若是有人質疑有每周會議，為何還要每日站立會議？那就代表你的每日站立會議的重點在 status report，並沒有做到前面所講的重點。

4. 時間不固定

剛開始時可能因為不知道那個時段比較合適，或者因為需要配合長官的開會時間，因此時間常常變來變去的。也許剛開始還好，但是時間一久，很多成員會對這件事情，感到非常不耐煩。

開這會並不需要配合長官的時間，或許長官無法天天參加，但是一週來個兩至三次，對於團隊狀況的掌握也是有幫助的。千萬不要變成長官不再就無法開每日站立會議，需知道這會議是為了同步團隊狀況以及解決問題而開，並不是為了長官。

5. 長官問太多問題

長官或許希望知道一些細節，或者想知道是否成員有些地方沒有注意到。建議可採取以下方式來解決：
(1) 做完的定義(Definition of Done)：若是能詳細定一一些檢查的清單，或是完成驗收標準，自然成員就會注意到這些事情，不用重複提醒這些事情。

(2) 增加檢查的 task：若是要確認的事情太多，不如增加一些檢查的 task，像是 design review、code review、單元測試、整合CI系統等等，來檢視是否事情做的正確，這樣就不用在每日站立會議上刻意再問。

6. 成員報告的內容詳細程度不一

每個成員與會時，需要將自己的事情，在一到兩分鐘內講完，並且是要和多數人有關的重要部分。有些人會滔滔不絕講很久，可是並沒有重點也和其他人沒有關係。 或者幾乎甚麼都沒說，讓人實在不清楚他在做甚麼。一開始執行站立會議時，這確實是件不容易的事情，但是這是需要練習。在與會前花 5-10 分鐘思考整理一 下，讓人家能很容易知道你的重點，並且強調在跟大家有關的部分。

註1: 5th Annual State of Agile Development Survey Final summary report, VersionOne

[erik]

專案經理在每日站立會議要做些甚麼?

Agile強調要self-organized, 一切都是由團隊來決定, 因此經理在裡面要做甚麼呢?

在這篇文章中, 提出了經理在每日站立會議中, 要做哪些事情:
(1) 誰有來誰沒來?
- 是否整個團隊所有人每天都有參加?
- 是否某些人一直都沒來?
- 是否沒來的人會影響到團隊?

(2) 投不投入?
- 團隊看起來是否很投入很有動力?
- 如果不是, 那為什麼會這樣?
- 如果有事情讓團隊會挫折, 你應該要了解那是甚麼
- 有成員在團隊中並沒有很投入嗎?

(3) 相同的問題是否持續發生?
- 是否每次你參加都聽到相同的問題?
- 或是團隊或是某批人都遇到相同的問題?

一般人對於經理參加每日站立會議, 通常會提出以下問題
(1) 我應該需要參加每日站立會議嗎?
- 你不用每次都參加, 每周出現一至兩次就可以
- 重點在專案一開始就持續參加, 而不是等到出問題才參加. 這樣人們會覺得你是來監視他們的, 感覺會很不好

(2) 在會議中經理可以提任何事嗎?
- 通常你只是聽, 除非是回答問題
- 若是要提出意見, 是在會議開完後才和團隊討論

(3) 經理可以幫忙嗎?
- 可以幫忙, 但是不要過度承諾, 因為你可能因為很忙而無法實踐

(4) 如果團隊有問題我應該怎麼辦?
通常試圖去解決, 是傳統command and control管理方式的人, 第一時間會做的事.

但作者會去思考以下事情:
a. 新聞只是新聞
- 有些事情講講完後, 成員會自行去處理它, 或是事情就消失了. 所以你不需要做任何事

b. 你希望得到決策還是意見?
- 要思考一下成員是希望得到決策還是意見. 因為不要試圖去解決一件事情, 但是是在沒有得到團隊的共識下進行.
- 所以可以幫他們, 而不是告訴她們要做甚麼. 讓資深成員或是scrum master來找出解決方案

參考文獻:

Scrum Daily Standup Meetings: A Manager’s Field Guide
http://www.ademiller.com/blogs/tech/2009/01/scrum-daily-standup-meetings-a-managers-field-guide/

[erik]

如何確保taksboard中的task是否真的做完和做好

**1. Task 要切得很小
**- 1-2天的大小比較合適, 這樣幾乎每天engineer可以移動他們的task, 會比較有成就感.
- 並且manager可以確認他們真的是有進度
- 大的task你不容易知道是否有些細節有被處理到, 較細的task比較可以知道engineer如何處理這個feature.

**2. 定義每個task做完的定義為何
**- 讓engineer知道manager對你的期待是甚麼, 避免做完後讓雙方落差很大
- 讓engineer在估算時, 會依據做完的定義來考量要多少時間

**3. 定義一些milestone或是check point之類的task
**- 有時候engineer拆解出的task, 很難實際上知道他到底做了哪些事情, 或是到底做完了沒有. 因此需要有些特別的task來讓你清楚實際的狀態
- 像是開立測試個案, engineer一開始通常只有test case creation這個task, 但是你很難知道他到底做得如何, 所以你可以要求加上test case review, check-in test case to test case management tool等tasks. 這樣你可以藉由review 來知道它的品質, 並且check-in這個task來確保他有做到你想要的做完的定義.
- 對於RD開發某項功能時, 一開始也只會寫implement XXX. 可是這樣你也很難知道他到底做得如何. 所以要請他加上, design review for XXX, code review for XXX, integrate with CI for XXX, defin demo scenario for XXX, demo for XXX 等等. 這樣你就不用有太大的落差.

**4. 確切檢查每天的進度
**- 在會議前先檢查task的狀況, 確認那些已經落後, 那些項目編排的很奇怪
- 在會議過程中, 針對這些有問題的task多加關注, 傾聽其報到結果
- 在會議後和這些task的owner討論, 是否需要一些協助, 或者如何補救

**5. 從daily standup的過程中給於建議
**- 在會議中會聽一些他決定如何優先順序的事情時, 須注意他是否做了正確的決定, 若不是的話, 在會後需要加以提醒
- 或者engineer有發現任何問題, 也需要會後立即加以處理, 讓所有會block的事情能夠降到最低

**6. 安排demo
**- 在sprint結束時, 安排engineer展示他所做的功能.
- 通常為了自己的名聲, engineer會讓成果維持一定的品質, 並且加快其處理的腳步

7. 安排developer執行基本功能的測試
- RD和QA討論出一組測試個案, 來當作驗收測試, 以檢查主要功能是否正確

[erik]

Daily Scrum: 只是報告現狀而已嗎?

簡介 在Scrum中最重要的, 最關鍵的一個實務, 就是daily scrum. 在sprint內的每天都要舉行, 並且整個團隊都要參加.
在daily scrum進行的時候, 每個人要回答以下三個問題:

1. What’s been accomplished since the last meeting?
2. What’s going to be done before the next meeting?
3. What obstacles are in the way?

通常很多人會把daily scrum視為是狀態的回報, 因此並不是很認真的看待它, 最後導致於不好的結果產生.

這不是只是一個狀態更新的會議, 用來讓project manager 或是team lead收集目前團隊狀態的資訊, 或者是知道誰進度落後. 相反地, 這個會議的目的, 是使每個團隊成員信守他的承諾, 幫助所有成員知道承諾的重要性, 以及他的承諾的對象是團隊中的其他成員.(不是manager而已). 這各會議不是用來 problem-solving or issue resolution. Issue提出後, 在daily scrum後會有另一個分組會議來討論. Daily scrum的時間, 應該不要超過15分鐘.

它要求的是團隊成員的紀律，而不是在詳細討論你所遇到的障礙, 只是確保其他人被通知到. 如果有需要的話, 在找有關的人, 再個別去開個會討論.

1. 意義 這裡大家可能會有問題要問: 為什麼只需要回答這三個問題, 而不是討論what’s new?

原因如下:
a. High visibility of progress
這是讓大家, 可以每天在同一個地方, 知道團隊的progres, 以及很容易了解他們的貢獻是什麼

b. Improve estimation
藉由了解大家昨天所完成的進度, 因此團隊成員可以知道, 他們自己所評估的事情的準確性為何, 漸漸地, 他們可以改善他們評估能力

c. Self-organization
團隊成員決定他們每日的工作內容, 他們需要對sprint所要做的需求負責任. 這會議會幫助成員了解他們每日的責任為何, 有助於團隊變成一個self-organization. 因此團隊成員會慢慢地變得成熟, 願意地去承諾一些事情, 或是有效率地處理他們所遇到的困難.

d. Increase the quality
每日的溝通將有助於refactor他們的工作, 並且減少因為要排除障礙所需要花的時間. 它會幫你建立相關的知識, 以及很快重新再利用這些知識.

2. 常見的問題 以下是常見的問題, 會對daily scrum帶來負面的影響:

a. Lack of a clear understanding of Scrum practices
如果團隊對於scrum的實務不是很清楚, 這將會使得daily scrum執行起來不是很正確, 會導致要花較多的時間才能完成. 時間一久之後, 團隊會失去它的耐性, 最後導致變成只是一個status meeting, 並且頻率從每天變成每週.

b. Old mindset/habit
這是很常見的障礙. 在傳統的專案,團隊成員需要向PM或是Team lead (不是scrum master)來做status report. 因此在daily scrum時, 他們會像以前一樣的方式來報告他們所做的事情. 因此會比較是generic或是high level的答案, 而不是仔細到每件task上面.

c. Faced critical problem
當有成員面臨了一些關鍵的問題, 並且嚴重影響到他目前或是將來的工作. 在這種狀況時, 大多數的人會開始解釋這個事情, 因此而浪費許多時間

d. Communication problem
有時候人們不擅長去解釋或簡化技術性的問題, 這是另一種溝通的問題

e. Information about barriers shapes the discussion
當有障礙發生時, 很容易吸引人們去討論它, 因此這會將daily scrum變成討論會, 其它的人也會因此而慢慢地加入這個討論中

f. Start requirement/design clarification/discussion
人們很容易在daily scrum中, 討論設計或是釐清需求, 因為他們認為這是一個好的時機去做這樣的事情, 並且也花不少時間做這樣的事情.

g. Team is too big
如果團隊太大, 會需要較多的時間去完成daily scrum. 在這種狀況, 人們會抱怨所討論的東西和他們沒有關係, 並且他們將會希望能及早發言, 以便能夠及早離席.

3. 如何處理這些問題 以下是一些方法來處理這些問題

a. Proper team training on Scrum
規劃正式的訓練課程給團隊成員, 或是提供偶發性, 小型的scrum 介紹課程給團隊

b. Reiterate the three questions
有需要的話, 多次重申這三個問題的重要性給團隊, 直到大家真正了解它的意圖為止

c. Avoid a lengthy technical discussion
如果有人試圖解釋一些技術性的問題, 或是無意中形成技術性話題的討論, Scrum master必須停止他們, 並且要求之後offline再討論. 只能著重於目前這個sprint中task的狀況.

d. Scrum of Scrums
如果是一個很大的團隊, 可以考慮使用scrum of scrums. 對於大型或是分散式團隊, 這是非常有效率的方法

結論
Daily Scrum有助於提高團隊成員對團隊的承諾, 以及團隊的成熟度, 和self organization的程度. 最終, 它會使團隊真正變成一個self organized 的team