最近和 team member 聊天, 他談到有了 Daily Scrum 後, 為什麼還要 status report 的會議呢?
 
 Five-Whys  
 
為什麼會有這個 status report 會議呢? 因為在 Daily Scrum 時, 大家雖然有回報他的狀態, 但是還是不清楚整個 project 或是每個 feature 的狀態. 所以我們被要求要更新 task board 外, 還另外要送 status report 給 lead.
 
為什麼還是不清楚整體狀態?
(1) 因為每次報告時, 我們可能輪著每個人講, 但是每個人講完後, 跟 task board 沒有關聯.
(2) 或者雖然是依每個 feature 講, 但是每個人只講他的部分如何, 對於整體合起來倒底還差多少, 沒人知道, 沒有和 task board 有什麼對應關係
 
那為什麼不問清楚呢? 或者是和 task board 對清楚呢?
(1) 因為我們有 20 個人一起開會, 不可能問到這麼詳細, 如果要問到很詳細, 可以要花很多時間.
(2) task board 似乎也是過期的資訊, 可能和現在做得對不起來
 
那能不能分組分小一點? 或者是每個 feature 有專人負責報告或是回答問題? 不可能, 因為現在的分工, 或者是系統架構, 導致一個人在多個 feature 上面出現; 並且撰寫 UI 的只有兩個人, 是 shared resource, feature team 的方式不可行
 
很多時候會造成某些結果, 可能的原因不一定很單純, 需要很深入挖掘才會知道. 就如範例所示, 人太多沒有分成 feature team 是根本原因, 但是可能無法一下就清楚. 這時候五個為什麼 (5 whys) 就很好用. 可以隨時來進行小型的 retrospective.
 
另外, 另外原因可能很多元, 不定問題點只在一個地方. 像前面這個例子, 人多沒分組是一個. 但是是誰決定要同時開 Daily scrum 又要召開 status report meeting, 並且同時又要更新兩邊的資訊, 這似乎也看出了決策是 manager 下的, 而不是團隊決定的.
 
所以當問題的地方爆出很多個時, 五個為什麼的方法就不太夠, 這時候代表問題很複雜, 需要再搭配 fish bone, 並且以團隊討論的力量來得出結果.
 
此外, 藉由這樣的方式, 你可以有系統地, 把大多數的現象給列出來, 以及這個現象背後的一連串可能的原因, 也被整理出來.
 
或許你可能無法解決所有問題, 但是成員也會知道原來有這麼多關聯, 哪些可能比較重要, 哪些可能沒有關係. 所以當事情沒有全面被處理, 他們也比較能理解.
 
因此五個為什麼的做法提供了以下好處:
視覺化問題來龍去脈
集體討論的架構
背後原因其重要性的相互比較 (搭配 finshbone)
對問題的集體共識
 
 
但是方法管不管用, 都要在於你要不要用, 以及你在不在乎要處理這些問題. 有時候沒心的話, 任何仙丹都沒有
 
這也就是組織文化永遠比任何 practice 來得重要. 人永遠比任何 process 還要寶貴
 
 

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()