Oct. 24 22:14~23:07
▲工作中的阻礙
幾年前有一次機會參加一個行政團隊的sprint review與retrospective會議。這個團隊剛開始接觸Scrum，他們對於Scrum的理解是由公司內上過Scrum課程的同仁所傳授。在review會議中，同仁甲展示他的工作成果—召募新人流程。他將這個流程視覺化，並比較舊有招募流程與新流程的差異。
Product Owner對於這個展示沒說什麼，倒是Scrum Master問了很多問題。Scrum Master以前是行政部門主管，跑Scrum之後轉為Scrum Master。
***
Review結束之後，在retrospective會議Scrum Master請團隊成員各說出三個好的與三個有待改善的項目。
同仁甲：我覺得Scrum Master要求我們將自己工作流程視覺化這一點很好，讓我比較容易看出現有流程有問題的地方。有待改善的地方就是關於校園招募這部分，我覺得吸引學生來填寫資料的誘因還不夠，這部分的流程以後還可以加強。
就在每位同仁都發表意見之後，Scrum Master請Teddy提供一些建議。
Teddy：我想請問你們知道retrospective會議的目的是什麼嗎？
Scrum Master：知道啊，就是流程改善啊，讓我們可以越做越好。
Teddy：你說的沒錯。請問各位同仁，你們剛剛所提出Good與Improvement的項目，是屬於需求面的改善，還是流程面的改善？
此時安靜了幾秒，大家你看我，我看你，對於Teddy所提出的疑問，大家一臉黑人問號的感覺。
Scrum Master：我不懂你的問題，我們剛剛提出來的的確是流程的改善。像是同仁甲就很明確提出他在校園招募流程方面的改善建議。
Teddy：同仁甲，請問您的主要工作是什麼？
同仁甲：我負責招募與其他人事方面的工作。
Teddy：所以新人招募是你提供的服務，對嗎？
同仁甲：這是我的工作，要說是我提供的服務也可以。
Teddy：你們是行政團隊，不像開發團隊需要寫程式，做出可動的軟體。你們所提供的「服務」就是你們的user story。
Scrum Master：所以你是說，我們剛剛都在討論「需求的改善」？
Teddy：沒錯。
同仁甲：可是我們討論的明明是「流程改善」啊，以我來說，我談的是招募流程改善。
Scrum Master：啊，我知道了。我們實作的「需求」，是對公司提供某種服務。我們討論的都是這些服務的流程，就好像軟體功能怎麼被使用的流程一樣，這是屬於需求的範疇。
Teddy：沒錯。
Scrum Master：我還是有一點不明白，retrospective所謂的流程改善，是什麼流程？
Teddy：是團隊合作的流程，有什麼阻礙存在，讓團隊無法更快、更好的交付價值給客戶。
Scrum Master：可以舉個例子嗎？
Teddy：例如，我觀察到你們每個人所負責的工作彼此獨立，無法互相幫忙。這對你們來說會是一個問題嗎？如果有同仁請長假，他所負責的工作會不會無法進行？你們在提供服務的時候有沒有遇到什麼阻礙？是否很清楚用人單位的需求？會不會經常發生找到人被RD打搶等等問題。
Scrum Master：如果撇開Scrum不談，難道我們不能找時間討論我們提供服務的流程嗎？為什麼要侷限在retrospective所規範的活動範圍？
Teddy：團隊當然需要時間來討論供服務的流程，也就是你們團隊的需求。在Scrum框架中，你們可以在product backlog refinement workshop討論，也可以在sprint planning討論，但不適合在retrospective討論。
Scrum Master：可是我就是不想被框架限制住啊。
Teddy：你會在告別式的時候包紅包嗎？
Scrum Master：啊？當然不會啊，我沒那麼白目。
Teddy：那你為什麼要在retrospective討論需求改善呢？如果你在這個活動討論需求，請問你要在什麼活動討論「工作流程改善」？Sprint planning嗎？不會吧。
Scrum Master：是不會啦…
***
友藏內心獨白：先學會走再看看要怎麼飛。
