黑先生

【Scrum第一次Relax】 在跑Scrum時，每次的Sprint基本上都是專注且盡全力，不然怎叫"衝刺"。所以我的經驗上，適當在回顧會議之後加上Relax time，讓團隊有稍稍喘息時間與空間。同「 霍桑效應 」的結論之一，提高良好的互動關係、安全感、和諧與歸屬感有助於提升生產力。 右下角三個會議，我稱作3R(Review,Retro.,Relax) 上圖是此專案節奏，會在專案開跑前，告知團隊成員流程的基本樣貌，再去做調整。每個團隊因為成員組成不同，都會有不同節奏，而制定好屬於此團隊的呼吸節奏，是SM最大的責任。 如果SM安排了Relax time，那當然可要好好負責，什麼叫"負責"呢? 就是安排任何一個Relax活動，都要有背後的意義「 促進互動與凝聚力 」，譬如說， 桌遊 電競(switch) 團隊活動 密室脫逃 團隊競賽運動 開放空間技術+吃吃喝喝 放下電腦、放下手機一小時 善用每次活動，替下一次的Sprint好好充電，也是替這次Sprint下個斷點。 時間則是利用Sprint最後一天的最後一小時空檔，當然可以延伸到下班時間囉，只要大家有共識就行。 再來說說活動項目，雖然說SM要對其負責，但也不是SM說了算，最好還是回歸到團隊一同決定。再此提供一個活動共識的好時機點，就是在回顧會議。以"帆船圖"來說的話，其中的"太陽"就是可以讓團隊提議的地方，貼上想要的活動，並由SM引導合適性。 據經驗，每個團隊成熟度不一樣，Relax也要不一樣，不管是內容或者時機，端看每次Sprint的狀況予以Relax。通常越成熟團隊，對其意義是愉快、放鬆，然後間接提升效率。而經驗越淺的團隊，也比較沒有餘力來享受Relax，可以著重在凝聚力的提升。 結論： 這時間的投資與否，就看團隊整體狀態來評估，不一定非得要有。如果新團隊或剛成立，SM可以好好利用這時間來補其不足的地方，間接認識、磨合彼此價值觀。 上一篇： Scrum第十六步：第二次Retrospective meeting 下一篇： Scrum第十八步：持續迭代衝刺 Scrum過程總結

【Scrum第二次Retrospective meeting】 有了 上一次的回顧經驗 ，SM可以從上次團隊在回顧中的態度進行思考，如何讓大家更"容易發言"。有可能是方式不對，也有可能是SM表達不對，或者是團隊個性不適合某種方式，SM都有責任找出屬於此團隊最理想的討論場域空間。 通常第一次可以用最保守方式，「Good、Could have been better、Improvement」，試看看大家的反應。但要注意，人都是健忘的，SM在前2.3次的Sprint期， 最好能記錄下所發生的任何事件 ，在拿到會議中當作觸發點回憶，不然很可能會在不熟悉、不知如何討論中渡過，浪費了此會議的精神。 實際狀況中，前幾次團隊發言可能不會很踴躍、容易進入指責、偏離主題...等等，但這也都是顯性反應，對於SM來說也是要一直迭代持續改善。好在前人都有準備好很多工具輔助大家思考。 Happy、Unhappy、Do more、Do less Good、Could have been better、Improvement 帆船視覺圖 SKS(Stop、Keep、Start) ORID 故事骰、說故事 經驗中，基本款的Good.Better如果不好讓大家發揮思考，推薦使用"帆船視覺圖"容易進入狀況。另外，通常初期成員在討論狀態時，比較不容易聚焦寫上便利貼，這時SM可在適當時候扮演紀錄者，幫發言的人摘要重點並重述，再拉隴大家共識後，貼到對應的位置進入追蹤改善。有時親自身教也是必要方式，幾次習慣後，大夥就會自己來囉! 結論： 當人員心態、環境都準備好後，就要開始回歸此會議最重要的意涵， 「 Sprint Retrospective 提供 Scrum Team 一個自我檢視的機會，並建立一個改進計劃以便在下 一個 Sprint 中落實。 」 最後我們用「 霍桑效應 」來解釋，當你開始關注、重視它時，就會開始慢慢變好。 所以身為SM要落實與重視任何的回饋，當你開始重視，才有機會變好。 霍桑效應(Hawthorne Effect) 上一篇： Scrum第十五步：第二次Review meeting 下一篇： Scrum第十七步：第一次Relax Scrum過程總結

【Scrum第二次Review meeting】 先來回憶一下大部份會執行的流程 與PO先規劃討論Review內容與方式 初期可由SM來主導會議流程甚至於內容 透過Story、Task的AC描述，找出適合的展示方式與內容 熟悉後，可由PO或Teams輪流主導 會議中利用簡報或操作Demo來開啟"對話"、"討論" 會議後再透過"對話"整理收斂，供下次衝刺參考 Review是團隊唯一有對外"正式會議"，但還是有些時候Sprint很技術面，對於利害關係人來說，會不小心變成"聽不懂的進度報告"。可以回頭先檢視，是否在Planning時就無法MVP讓關係的人了解目前產品狀態。 如果無法避免會有此Sprint，內容也真的不好轉換成高層較關心的資訊，此時利害關係人也可以去擴大思考，未來可能會承接維護單位或有技術價值資訊邀請參加， 一來，藉由此溝通管道讓資訊透明 二來，轉換成"技術舞台"增加互動與成就感 其中的成就感來自於自我承諾達成與展示，當然相反的意思也就代表，如團隊內有不精實的成員，當下就會被血淋淋的反應出來，並在之後回顧會議馬上檢討。 有了 上一次的Review經驗 後，身為SM要自省還需要哪些動作才能達成指南意涵，「利用已知來漸漸掌握未知」，主要原則 對外 - 產品狀態是否透明 對內 - 對於下一次的衝次價值是否有疑慮 衝刺期間團隊專注在完成任務上，對於不同專業、職能的溝通，大多停留於功能上的交握足夠就好，很少有進一步的機會去深層認識。 有個隱形的價值要注意，那就是"團隊認知與共識"，在與產品價值不衝突情況下，適當安排屬於內部Review，會讓團隊對於產品的認同感與參與度大大提升。 以「周哈理窗」套用解釋的話也通用，別人對於你講解的技術深度越夠的話，會越信任你做的東西越穩定，也會樂於互動、溝通，進而間接提高工作效率。 結論： SM可以拿捏一下分寸，目前團隊還缺哪些層面，進行不同層次的安排，讓內與外都愉快。同時也要避免 「穀倉效應 」。 圖源: Hiking Artist 上一篇： Scrum第十四步：第一次Refinement m...

【Scrum第一次Refinement meeting】 Refinement meeting(精煉會議)，通常用開車的遠光燈來形容，替前方不明路照一下，讓車子可以繼續安全往前進。 指南 中也僅僅只有幾行的簡短描述 Product Backlog items 透明性通常要經過上述精煉化活動來獲得。 先理解它要傳達的內涵 - 持續讓待辦事項關注、最新，「 模糊變明確，未知變已知 」；我們來用人、事、時、地、物劃分出原則。 人： 不必全部人參與，用最少且必要相關人進行有效討論。 事： 最新資訊持續更新，至少要讓下一次衝刺任務是清楚的，可被挑選出來拆解。 時： 視開發節奏保持彈性，但也可以固定在某一天。通常是在下一次Sprint前一個星期內。 (初期不熟流程狀況下，SM可以視情況是在哪一個Sprint才開始，不用第一次就到位。) 地： 在 使用者故事地圖 、待辦清單 看板前，隨時以全貌有系統的修正資訊。 物： 修正待辦事項的明確性，盡量讓下次的Planning meeting是有效率且可聚焦規劃。 實際情境： 如果沒有特別定出這時間來整理目前的使用者故事地圖或待辦清單，通常在Planning meeting中，人多容易失焦，又會多花一、二個小時整理後才能進行規劃。 Refine中，SM可以先與PO討論，先把目前資訊梳理到看板，問有沒有下一次想做或調整的MVP。如果有的話，目前還有缺哪些資訊須要了解，或者哪些資源須要備妥，在下一次Planning meeting前趕緊準備好，讓成員可以順利進行拆解任務。 結論： "衝刺"表示身體過程全神專注目前狀態，因此要有SM或PO如教練般旁觀，在場外觀看整體與資訊整理，再消化後轉成策略傳達給團隊，讓贏面更大。 參考： @產品待辦清單精煉會議 參考： 梳理會議(Refinement Meeting) 上一步： Scrum第十三步：第二次Planning meeting 下一步： Scrum第十五步：第二次Review meeting ------------------------------------------------------------------------- Scrum起手式第一步：團隊建立Team build...

【Scrum遊戲化體驗-用戶故事地圖】 故事地圖在初期引入時候，通常成員也會比較無感，導致需求產生總是卡卡。有了地圖的雛型後，開發端也會在coding時預留彈性，間接的把風險降低，不一定要完美才呈現。持續改善才是敏捷核心精神。可以透過遊戲來體驗，強化故事地圖的存在、源頭。 大致步驟：(1.5小時) 。前置作業-準備好Persona人物誌的描述、圖像、個性 。講題目 - 寫下從早上起床到出門上班，過程中所有做過的事情 。討論5分鐘 。觀察每組討論狀況，是否呈現比較無法聚焦討論(各講各的) 。適當時機與介紹，把Persona拿出來給個組討論，讓大家容易進入相同的想像空間 。讓大家討論20分鐘，寫在便利貼上，並依照時間順序排列 。分類動作並且命名 。狀況題 - 起床後，只剩半小時可以動作，而且早上有個會議絕對不能遲到。這種情況下該怎麼做? 。把不必要的動作往下方區隔出來 。狀況題 - 出門前一刻，公司同事打電話來說會議臨時取消。時間突然多出來半小時不趕，那就再做點什麼事吧! 。把想要額外的動作往下方區隔出來 。遊戲體驗完後，再拉大家回目前專案使用的故事地圖，看看有無別的想法想做修正 額外思考訓練 - 模擬市場不確定性的想像 大致流程： 。用海龜湯題目：便利商店、水、店員、槍、謝謝 。這五個關鍵名稱，讓每個人自行想像補出細節 。每個人列出流程後，再統一合併成一個流程 練習面對不未知情境的想像!! 實際情境： 通常跑Scrum有一定前提，需求已經大部份被PO確認完畢，開發團隊要做的就是在迭代持續回饋與改善，對齊PO的產品需求。但對於開發團隊，尤其是希望這團隊未來是朝自組織狀態，把全貌描繪出來，讓所有成員都能清楚知道自己正在哪個階段做什麼事情，心裡不安定感會降至最低，最事起來也會間接影響較有效率。 就算故事地圖很粗糙也沒關係，它也是個回饋反應，讓大家理解與共識目前狀態不確定性，去做開發的彈性預留空間。 結論： 開發團隊通常是在被局限在某個視野下去做開發，很容易失焦。如果想要讓團隊擁有系統思考去做討論或開發，把地圖視覺化呈現後，會讓彼此容易共同討論也聚焦。 樹葉就像執行認務，樹枝串連凌亂的樹葉讓其有序，進而呈現整棵大樹。 它是個全貌視野，也是個系統思維，更是戰略地圖...

【Scrum第二次Planning meeting】 〈 Scrum第一次Planning meeting 〉前提摘要：採用Bottom up方式，以理解Scrum元素為主，先寫出Task再補上Story。 先來回憶一下指南說的： Sprint Planning 回答以下問題：  ● 這次 Sprint 可以發佈什麼樣的 Increment？  ● 如何做才能夠達成 Increment？ 有了上一次經驗，團隊成員應該都稍微熟悉有哪些流程與內容要做，這次SM可以大膽嘗試，只做開場說明，然後交由團隊寫出這次要Sprint任務。 這次大致目的： 。SM以第三人旁觀角色，觀察與紀錄整個過程，並事後回饋修正 。了解User Story為何， 。PO寫出User Story，讓Develop Team有依據寫出Task， 。驗收標準在Planning meeting中先不寫，可以在Review meeting前在找關係人討論寫上， 。順序、估計則視狀況，通常越熟悉整體流程與資訊越完整情況下，寫的意義會比較大，但也表示付出的Plan時間成本會更多。 大原則，比上一次(只寫出Task)再多一些了解(User Story與標準驗收)與進步(由User Story寫出Task)即可。 前置作業： 。先與PO討論、溝通流程(大致會進行的方式)與內容(預計輸入、輸出物)， 。請PO準備好這次要執行的User Story。 。印列User Story表格單 。列印Scrum指南中提到Planning meeting的部分資訊、別人的Planning meeting情境參考 。開場前可以花個5分鐘講解 實際過程： 。延續上次story map與系統情境流程圖繼續衝刺 。PO白板列出可能會有哪些關係利害人(提供思考)， 。PO白板標示出User Story的描述格式，"身為Role，我希望Goal/Desire，以便於Benefit/Value。"(提供思考)， 。PO依據"系統情境流程圖" 寫出User Story提供參考， 。Development Team與PO討論User Story， 。Development Team可以在理解後，另外嘗試寫自己的User Story或者直接依據P...

【Scrum第一次Retrospective meeting】 先來看看 指南 如何說 框架是這樣，但身為SM更要理解背後精神與意義。 我們先來回想一下以往專案經驗，是不是大多是在功能、產品上線後，才會"特別"空出時間回頭檢視專案。而且大多還不是聚焦在"如何改善"，大多是"究責"狀態或是查Bug等等。 專案中情緒起伏較高處，"怎麼又來了、又這樣、哀、好煩......"，反應出有問題，但卻總是壓抑過了就過了，沒有正式去面對，也就一直惡性循環囉。 SM要特別觀察團隊的情緒反應，那是最真實的，也許他們不會開口說。 情緒 Scrum提供這個溝通頻道與空間，讓每個衝刺結束前，成員可以靜下心來，好好回顧熱呼呼的記憶，最重要的是，記錄下來追蹤、改善。 初期不熟情況下，每次先聚焦一個點來改善，對於SM會得到不錯的信任回饋。讓每個人都知道，任何反應與問題，都是放在心上要去解決，是玩真的，自然而然團隊向心力也會慢慢出現。所以這會議強調的是 我們變好的決心 。 1的n次方再怎樣也                          沒任何改變 1.00001的n次方會慢慢趨近           無窮大 ~ 0.99999的n次方則會慢慢趨近於  零 ~ Infinity 每次做好一點點，團隊會越來越好；千萬不要讓團隊變成小於1的狀態。 來看看指南上要改的焦點可以放在哪些事情上， 總之呢，就是有反應就改，即使是情緒發言也要探討、解讀思考背後原因，再用張紅色便利貼好好記下來，貼在最顯眼的地方，最好是每天Daily可以看的到，試著去改善，然後再次回顧檢驗，移除或畫紅色XX，放在回顧區。這也是團隊成就感來源之一，不一定要等到產品做完才能感受。 SM對於每個問題反應都要當責，即便知道做了也不會有任何改變，還是要去做一次。成員初期在意的不是真的能不能改，願意去做，失敗了也是"一個好反應"，再與團隊一起共識調整出別的方法，持續改善。持續付出，才能感受到決心。 上面提到精神與方法都具備了，感覺很容易應用，那麼實際運作下會是怎樣的情境...