Mystic Pieces

在 Offsite Meeting 活動的前一週絞盡腦汁蹦出來的一個討論方式：世界咖啡館 + 焦點討論法！這次活動的主軸，在於深、不在廣；在於當下的交流、不在後頭高大上的 Action Item，加上人數偏多（17位），所以產出了這樣的討論模式。

最近恰逢一些機緣，嘗試了個匿名蒐集意見的方法，與各位分享～

前一陣子上了 ICA 的焦點討論法課程，在過程中設計了屬於自己的 workshop。在 ORID 的四個步驟中，我最感興趣的是 R（Reflective、感受）的層次，在我的感覺裡，這是一個特別需要協助引導大家多沈澱、停頓一下的環節。尤其在工程師思維的世界裡，習慣性的想要解決問題，思緒很容易穿過 R，直接進入 I （Interpretive、詮釋）的層次。因此，我想了一個方式想要多停留、捕捉一下 R 的存在。

在兩三年前，因為新竹敏捷社群的一次活動，初次接觸了焦點討論法。在不同團隊、不同公司，也引導團隊用了幾次來進行各式各樣的 retrospective，sprint retro、annual retro、跨團隊的 retro、...等。雖然實際操作過很多次，但其實都覺得仍有一絲絲空洞感，好像少了什麼基礎。在這次終於參加到 ICA 的 GFM-1 焦點討論法課程，之前因為沒有特別 follow ICA，每次想到都已經錯過課程了...。這次終於補齊了那個空洞！以下僅是一些作為個人回顧的心得，我想 ICA 應該是不需要我多做宣傳廣告。XD

在 Brainstorming 活動後，往往會產出很多 action item ，接下來就得將這些 action own 上一個 owner。當然人數很多又希望 owner 盡可能平均時，這個工作也不是太容易，而且通常到這個階段通常是會議或是活動尾聲，時間可能相當緊湊。這邊分享一個這次我使用的方式 — 志願序。

昨天分享了 Kanban 最基本的樣子，今天來聊聊 Kanban 牆上的板子應該要能夠呈現哪些訊息？

學習了近兩年的敏捷開發，也跑了近兩年的 Scrum，但對於 Kanban（看板方法）卻仍是一知半解。這次利用了 228 連假，給自己出了一道習題：好好的閱讀 Ruddy 老師的《精實開發與看板方法》，並於本週主動分享給公司內各單位同仁關於 Kanban 的資訊，就在今天完成了這項習題！

以下重新歸納了一些我對 Kanban 的最基本認識，希望對於初學者有一點點幫助。若有錯誤還請不要客氣的糾正我～！

幾個月前，因為社群夥伴的邀約，推了在坑邊猶豫的我一把，就這樣的參與了呂毅老師兩天的 CSPO 課程。在團隊中，我算是個兼任的 Scrum Master，在幾個月前的動機僅僅是想更了解 PO 該怎麼樣更好的和團隊協作。但就在最近，因為公司計畫變更，我面臨了更多不一樣的考驗。就在這樣搞不清楚的狀況下參與了課程，我甚至不知道哪邊有問題，只是很多不太自在之處，對於需求端僅能弱弱的吐出「需求變動時怎辦？」、「這不能即時反應市場吧」、「能早點做出 MVP 開始賺錢嗎？」、...。

經過這次課程洗禮，我不知道為什麼，好像突然茅塞頓開，一切都疏通了。但其實課程中並沒有特定的章節可以直接解答我的狀況，只是好像一切都串連起來了，問題清晰了，也甚至有解答冒出來了。（以下還不會談到我想通了些什麼，希望日後經過實際案例的檢驗，再行分享。）

這次剛參加完半場的 DevOpsDays Taipei 就前往東京旅行了，帶著滿腦子 Agile 的東東踏上了旅程，突然有些心得，特別記錄下來。

今年很開心的又能參加 DevOpsDays Taipei，第一天依然是 Open Space 的活動，這是我第四次參加 Open Space 形式的會議。有些心得，想要特別記錄下來。

昨天聊到專職 Scrum Master 這個話題時，聽到 91 哥一席話：「問老闆要 4+1 還是 4x2」，突然有個想法，用數學來推導推導這件事吧！先別提 x2 這麼誇張的戰力提昇，算算 Scrum Master 每個 sprint 要為團隊提高多少比重的戰力，才算是一個「合格」、「划算」的角色呢？

昨天結束了 Jackson 與 Philip 老師兩天的 「Scrum Master 領導力」課程，對於 Scrum Master 這個角色又有了更深一層的體悟。記錄一下自己的感想，也供日後自己能夠不斷的回顧、省思。

若兩年後你的團隊還在 run Scrum，這說明了你們的 Scrum 不 Scrum。

-- Daniel Teng

Scrum Master 在前期或許偏重 Scrum 引導，後期就要嘗試引入一些有趣的變革。變革適不適用根本不是重點，重點是嘗試過，有問題再來修正就好～。而我發現自己最常引入變革的是 Retrospective Meeting 的部份，往往需要增添更多滋味，才能引發出更多的反思及反饋。但這次要談的是 Review Meeting 的新滋味！

今天分享的是在《敏捷回顧：團隊從優秀到卓越之道》之中學到的「三個五」的活動。書中歸類在「收集數據」的章節，也就是 ORID 之中的 O（Objective ），但我覺得也很適合用在 brainstorming 的情境。

前一陣子閱讀了 Ed Catmull 的《創意電力公司 ― 我如何打造皮克斯動畫》，這本書讓我非常有共鳴，特別撰寫這篇文章，記錄並梳理我的心得，也同時分享給各位。

整本書裡頭，壓根沒有提到任何「敏捷（Agile）」的概念或字眼，但完全就是敏捷文化的形狀。這就是我內心敏捷的最高境界，叫什麼名字、跑什麼框架並不重要，重要的是團隊一同實現的文化內涵。除此之外，我們也熟悉迪士尼和皮克斯的一些作品，所以閱讀中就像穿插了一些小彩蛋一般，比起一般的商業管理書籍，又多增添了點趣味。

敏捷開發講求團隊合作，往往有很多事情需要大家共同決議，最常見的不外乎圓點貼紙（dot voting），用投票的方式快速找出共識。然而，在我閱讀《失控的多數決》後，對於簡單多數決，有了些微不同的看法。彙整記錄，提醒自己別輕易把多數決與共識劃上等號。

今天讓整個軟硬團隊練習需求切割的過程中，感受到一些有趣的現象，記錄下來與各位分享。這是一個真實存在的需求，但不是實際的時程，藉由這個需求讓團隊練習，也或者說趁此機會同步一下大家的想法。

實行敏捷開發以來，慢慢體悟到很多文化、思維與傳統模式（瀑布）上的差異。逐漸感受到這不只是一種方法論，而是一種文化及信仰的力量。一個失敗的產品，可能的原因很多。先不論外在資源、環境等因素，單單就團隊內部能量是否能夠完全展現，就是一個很值得討論的問題。

最近突然靈光一閃，運用 LEGO® SERIOUS PLAY® （LSP）引導了一場團隊的 Retrospective 會議。我們使用的是探索包（Window Exploration Bag），每包的組合都相同，含有 52 塊各式各樣的 LEGO® 積木。運用這樣的工具，展開了這次的 Retrospective～

（圖片來源：https://shop.lego.com/en-US/LEGO-SERIOUS-PLAY-Window-Exploration-Bag-2000409）

在敏捷的團隊中，理論上至多只能擁有團隊績效，沒有個人成績

敏捷團隊重視的團體大過於個人，鼓勵所有成員能夠相互幫助、相互支援

將一切都透明化，一起成長、一起進步。

但現實生活中卻不是這樣，多數的公司的文化制度，仍保有個人 KPI 的規範

那基於敏捷模式下的團隊，該如何去訂定個人 KPI 呢？