- 什麼是 Scrum ?
- Scrum 的理想 ?
- Scrum 怎麼導入 ?
- 現實的殘酷
- 仍然存在的疑惑 ?
什麼是 Scrum
「什麼是 Scrum？」，在這之前我們先問一下「為什麼要 Scrum ？」
「Scrum 之前我們怎麼進行專案的？」、「Scrum 之前我們怎麼管理團隊的？」
層層的組織架構、層層的管理人員、層層規劃設計開發…
本來都好好的，為什麼現在不 work 了？
時代正在改變，軟體、網路、行動裝置等…各種技術的成熟，使得整個社會，
不論工業、商業已經往下一個階段邁進，
這是一個VUCA(多變(Volatile)、不確定(Uncertain)、複雜(Complex) 與混沌不明(Ambiguous))的時代，
新的科技帶來新的生活習慣與消費行為，同時機會也再此產生，
不論是巨象還是螞蟻都必須想辦法求生存，而快速適應與改變的能力，成為這個時代必備的能力。
不論是 Agile 或是 Scrum 都是要讓你適應變化，並且活下去。
而 Scrum 是一個框架，三個大原則，透明(Transparency)、檢驗(Inspection)、調適性(Adaptation)
簡單易學，卻難以精通，這句話說得明白一點，就是很容易畫虎不成反類犬。
而 Scrum Guide 用了一句簡單帶過，
「Scrum’s roles, events, artifacts, and rules are immutable and although
implementing only parts of Scrum is possible, the result is not Scrum.
Scrum exists only in its entirety and functions well as a container
for other techniques, methodologies, and practices.」
常見的「Scrum 自助餐」其實不是 Scrum 。
透明(Transparency)
透明的目的是什麼？避免殼倉？曝露風險？取得共識？
CMS 課程帶給我一個很重要的學習，是個很簡單的老故事就說過的道理。
「盲人摸象」，大家應該都聽過這個故事吧，
有的人摸到了扇子(耳朵)、有人摸到牆壁(身體)、有人摸到柱子(腿)、有人摸到水管(鼻子)…
如果大象是你的產品、你的商業模式、你的生存武器，
那麼展現「雅量」就不是一件很好的事了，
當你的 DBA 說了扇子、RD 說了牆壁，PO 說了柱子而 QA 說了水管，
那麼這些的加總就是你的大象(產品)了嗎 ?
「所有人說都是對，排列組合也是對的，但結果是錯的。」，
怎麼解決這個問題？
- 讓盲人看見
- 讓盲人摸得到別人的區塊
透明的目的是為了看見目標、取得共識，
還記得多少浪費生命的會議，有多少會前會？有多少會後討論嗎？
又或是大家都說好，作出來卻是半成品、廢品嗎 ？
取得共識 是困難的，Scrum 提供的機制，
讓回饋在不同的活動(會議)中由不同的角色中產生，
但是如果成員不願意講，這些會議就一點意義也沒有了。
要如何讓成員願意發言？
信任、信賴、安全感，但是這需要時間去打造這樣的文化與環境。
事實上不會喊完口號，成員就彼此互相信任，生產力大爆發。
如何打造一個這樣的環境？是管理職真正的責任所在。
但這種無法立竿見影的工作，喊口號的很多，作的人很少。
檢驗(Inspection)與調適性(Adaptation)
透明在檢驗與調適性之前，是有重要的意義的。
也只有透明，才能讓事實擺在眼前，
不是基於事實的檢驗與修正，只是自慰而已。
無奈的是這個世界是如此的複雜，你幾乎不可能真的看見大象(全貌)，
曾經有個創業的朋友說了一個「敏捷無用論」，
沒錯，他說得對。
Agile 與 Scrum 從來不是銀子彈 ，如果要迷信「敏捷」不如迷信「沒有銀彈」吧。
你必需依賴你的情境(Context)來決定使用什麼方法，
在他的情境當中，他們要作得項目已經很明確了，而資金是不足的，所以每分每秒對他們都非常重要，
如果要照表操課這些會議，恐怕會佔據大部份的時間。
但是這些會議都有其背後的意義與目的，如果團隊能與商業目標緊密結合，
甚至是一體同心(比如說:你就是老闆又是開發人員)，那麼梳理需求是不是能快速的在幾分鐘內完成 ？
如果你們每個人每時每刻都在一起工作，分享彼此的工作內容，那麼需不需要「每天」開個例會同步資訊呢 ？
反過來說，他說得也不對。
在每個會議與每個會議的產出物的背後都有一個目的與意義，
如果不能讓梳理需求、衝刺開發、展現結果與收取回饋時時發生，
那麼這些會議是最好的機會，更重要的事是 Scrum 給團隊自主權，決定進行的方式，
如果有進行這些活動，卻沒有帶來相對的效益，這背後是不是對 Scrum 沒有深刻理解所造成的呢 ？
這種都對都錯的「盲人摸象」時時發生，
重點是怎麼作「取捨」、怎麼作「選擇」。
也是「Adaptation」的意義，你要欠一些債，爭取提早上市的時間？
你要將一個團隊當作棄子，為了作出一個 POC？
這都是選擇，你是有意識的選擇，還是無意識的呢？
如果你是屬於身不由已的那方，被選擇得對象，那麼你要作出什麼選擇？
讓自已的生存機會提高呢？
Scrum 的理想
Scrum 本身僅僅是個框架，它給了整個團隊非常彈性的空間，
但是仍然有著一些限制。
角色的定位
Scrum Master 要作什麼
Scrum Master 的這個角色，不存在一般的組織架構之中，
這個導致 Scrum Master 的養成非常不易，
偏偏「Master」這個名詞，使得人們對 Scrum Master 有不切實際的期待與依賴
「Scrum Master」本身是個教練型的角色，需要旁觀者的客觀心態，
需要觀察記錄個人、團隊乃至於整間公司文化，
(「記錄與側錄」是重要的，這能讓你從另一個旁觀者角度看事情，不要只有一個視角。)
同時又需要各種方法去教導、引導團隊，這包含「對 Scrum 的理解與實踐」與「工程實踐」
有太多 Scrum Master 常常會犯的錯如下:
- 淪為安排會議的助理角色
- 過度將焦點放在 Scrum Master 本身
- 照表操課的帶四大會議，而不是觀注在團隊的成長與過程
- 缺乏工程實踐的能力與經驗，導致在引入實踐時淪為空話
- 身兼不同的角色，造成角色錯亂
- 無法存活導致被炒，即使有冒出新芽的改變也隨之消失
- 只顧著存活而無法帶來實踐改變，純粹變成招覽「人材」用的蜜糖(HR:我們有屎逛，很潮喔;進去後才發現是小瀑布，真的很潮)
PM 可以轉型 PO 嗎
簡單的說，當然可以。
你想改變的是你的 Title 還是你的作事方法 ？
你想改變的是你的 Title 還是你的作事方法 ？
你想改變的是你的 Title 還是你的作事方法 ？
理想的 PO 應該更觀注在產品上面，我們希望你會產品有想法、有願景甚至有策略，
如果沒有策略，只是想作一些嘗試也是可以的。
第二點，排序，「我全都要」是不負責任的說法，是大頭症而且偏離事實的中二病
如果團隊也承諾「我全都給」，就要小心整個組織是不是落入「國王的新衣」，集體自我欺騙的困境了
Walking Skeleton 是一個非常好用的手法，在探索出你的商業策略之後，
要找出關鍵的支柱，儘可能快速的推出你的 MVP ，
實際上如果你要你的產品有 Value，你是很難在一個衝刺中完成一個可發佈的產品的
(Demo 或概念介紹影片是有可能的，如果你也走記者會趨動開發的話…)。
我們理想上不要有半成品，或是讓半成品儘可能的少，存在時間儘可能的短，
我還蠻推崇 User Story Mapping 在排序上的作法，
「二分法」少了它就不行的功能、基礎建設就作，其它就不作。
讓 Walking Skeleton 儘早的串通，拿掉所有不必要的功能，儘可能的輕薄。
端看你的 DoD，要達成 End to End 的 Walking Skeleton。
但是有時候即使你拿掉所有非必要的東西，也需要多個衝刺才能完成 Walking Skeleton，
當你完成之後，你的每個開發就可以在這基礎上進行增量開發，而且每次都可以作端到端的完整測試，
持續的開發增量，直到滿足 PO 對 MVP 定義，才有 Release 的可能。
相同的手法在團隊拆解 Task 也是可行的。
MVP 很大，遠比你的想得大很多
MVP 很大，遠比你的想得大很多
MVP 很大，遠比你的想得大很多
歸納一下重點:
- 想清楚產品現在最重要的策略
- 由策略 Break Down 出 Product Backlog Items (User Story)
- 只有作與不作的優先權
- 只觀注要作 PBI 與 DoD
- 找到 Walking Skeleton，在一開始儘可能的薄(這個手法適用 PBI 與 Task)
- 事實上 MVP 仍然很大，大到你不一定能在一個衝刺中完成
- 問兩個問題，什麼讓我們變慢？什麼能讓我們更快？
- 增量不等於 Release
- PO 要觀注產品的價值，與市場的變化
- 不要 Management 不要 Dispatch，只要排序並約定最上面的最先完成
- 進入衝刺後就不要異動排序
- 保留插件泳道可以帶來一些彈性，但是也是有代價的，請確保放入泳道的 Task 比衝刺的 PBI 更有價值
導入
這幾年 Scrum 或是 Agile 在台灣各地相當盛行，
這是個好事，但同時也意味著各種妖魔鬼怪的出現，
認証單位的出現，品質低下的 WorkShop 出現，
同溫層自 high 喊口號的出現，這些都是一些壞味道，
敏捷是很科學的作法， Scrum 的經驗主義也是有其理論基礎。
在這之上如果變成直銷或是宗教化的宣傳，
我個人認是非常不好的，甚至會成為導入的反動力，
我常常在想，滿牆的便利貼與宗教崇拜這樣不是與彊屍道長沒有兩異嗎 ？
我的建議的導入方法
- 先觀察找到瓶頸或關鍵人物
- 爭取組織關鍵人物的支持，如果有老闆的支持更好
- 帶來變化與作法，更勝於帶來新名詞
- 一直講一直講，通常講到對方不耐煩才只是開始(小心自已先不耐煩)
現實的殘酷 與 仍然存在的疑惑
最後，記錄一些現在遇到不解的問題
團隊的不穩定
不論是個人的生涯規劃，或是內部的組織調動，
都會讓團隊的成員組成變得不穩定，而基於經驗主義的 Scrum，
如果每個衝刺的團隊組成都不一致，會不會帶來太多的變數 ？
甚至團隊成員是抱著打工的心態，而 Scrum Master 也當作這些成員是別人家的孩子，
而不關心其成長。這樣總體的團隊能成長嗎 ？
過多的變數
承上題，在實驗的過程中，我們會希望儘可能的控制變因，
但是實務上，包含人員、工作內容（可能過度偏向某個 Skill Set）、假期、Deadline 與項目的複雜度/範圍等…
都會帶來很大的變因，這樣的估點是否仍然有意義 ？
規模化
理想的 Scrum 想達到有效溝通，建議人數要在 5~9 人，實際上整個組織一定會遠超這個人數，
雖然現在有 Less 等 solution，但是我仍沒有理解與體會到其帶來的價值，
因此仍然有所疑惑。
跨職能與自組織
本身產品的覆蓋範圍就很大，團隊人數限制在 5~9 之時，
要完成 End to End 變得有些不切實際與困難。
一方面現有的產品欠了相當大的技術債，而團隊欠了相當大的學習債，
團隊成員在開發上已經有點捉襟見肘，還要跨領域的學習，又要深入鑽研某項技能。
如何讓團隊認知到清還債務能讓我們變快，並且在工程實踐上達到要求也是需要時間，
而成員確在職涯規劃上，2~3 年就換個工作，而花了時間培養的戰力瞬間飛滅。
更甚是組織內部寧可換用便宜的人材，
而不珍惜自已花時間養成的人才。
對此我深感無力，
跨職能與自組織最後也是淪為口號。
以上，我仍在觀察、記錄…
並且尋找機會，「Change Your Company」。
做正確的事，然後等著被炒
(fin)