引言
以下內容是基於公司目前使用 Scrum 管理所產生的心得。
皆為個人主觀感受、抱怨與現實。
並且沒有問題解決方案，就單純粹發牢騷。
如果有錯誤、不認同也歡迎在下方討論。
在網路上以敏捷為關鍵字搜尋，會發現充斥著必看、必學、強大、簡單、靈活、真敏捷等話術。或是XXX 公司都在使用的管理方法等術語吸引學習。
身為主管的你，怎麼能不學？
但事實成效不一定比較好，你目前團隊執行的是真正敏捷還是表面上的敏捷？
什麼是 Scrum?
Scrum 是一個敏捷項目管理系統，它「協助人們和團隊以合作的方式逐步提供價值。」
在 Scrum 管理所構成的團隊合作做模式下，最重要的團隊彼此間的信任（Trust）。
一旦沒有信任，Scrum 大師所闡述一大堆什麼自主性、高績效都是屁。因為團隊成員的執行都是被動且低效的。
Scrum 往往牽扯到公司的認知、團隊間的行為、態度與價值觀的問題。而不是找個顧問來，在管理軟體上弄弄看板、清單、執行每日的站立會議就當成是在 Scrum。
沒有能力點破當前團隊問題的人，往往執行的都是偽敏捷（fake agile）。
角色定義
敏捷中的角色定義
Scrum Master（SM）: 為 Scrum 的主持人，確保 Scrum 流程的順利進行，並促進團隊的自我組織和不斷改進。
Product Owner（PO）: 又為產品負責人，PO 的主要目標是確保開發團隊優先處理最有價值的工作，以滿足產品的需求和願景。為利害關係人與開發人員之間的橋樑。
Developers: 開發人員的主要目標是通過合作和創新，交付高品質的軟體。在 Scrum 框架中，開發人員被鼓勵自我組織，共同決策並確保團隊進展。
公司的角色定義
根據目前身處的團隊內所看到的角色定義。
Stakeholders: 利害關係人，通常會希望獲得產品資訊，或是參與其中。可能是最終用戶、其他團隊、上級領導，或是是另一家企業。
領導-A：整個技術部的領導者，管理多個團隊。需要面對整個公司部門的其他領導，並回報給董事長。對於產品技術不懂。
主管-B：團隊內的領導者，與團隊內的成員有密切接觸。目前擔任 PO 並與團隊成員有密切接觸，每兩週回報給領導-A。技術不熟悉但積極學習。
冗員-C：就是個冗員。
冗員的定義是對團隊沒什麼貢獻或是負生產，但又身為團隊一員的人。其中可能有以下特質：
- 講得出很多技術，但都不會做。
- 著重在耍嘴皮子，常常與事實認知有錯誤。
- 什麼事情都要管，最終自己份內的事情沒有完成。
- 團隊內的負情緒製造者。
- 執行不符合自己職位的事情。
成員-D：團隊內的成員，有實戰經驗好的與差的。
- 實戰經驗好的，往往能在時間內完成或超出預期的工作內容。其結果往往會被稱讚。
- 實戰經驗差的，做出來的東西被評估不足，需要額外訓練或有人合作進行。
現實職場
在現實職場中，尤其是在傳統產業或大型團隊中，常常面臨著各種人的問題因素，這些因素可能導致開發進度延遲、資源浪費所造成低效率。
- 技術負債：為了趕上進度或滿足某些要求，而採取先求有再求好的策略，最終導致技術負債累積。
- 重複工作：由於技術負債導致重新開發架構或軟體。
- 不平等待遇：你認真做事情，卻可能比資深不做事的錢少。
- 能力不足：由於缺乏關鍵的技能或知識，無法有效地完成分配的任務。
- 領導力不足：明明某成員執行方向偏離了，領導者未能判斷與指正，導致該成員自由發展，浪費時間。
- 缺乏溝通：團隊內部溝通不良，導致訊息傳遞不清晰，任務執行出現偏差。
- 倚老賣老：過於依賴過去的經驗，而不願意接受新的觀點或方法。
- 多一事不如少一事：害怕承擔風險或額外的負擔，而只選擇較簡單的工作執行。
- 混吃等死：僅僅為了生存而工作，在工作缺乏熱情和動力。
可能還有更多，也歡迎補充遺漏的。
這些問題只是凸顯現實職場中的情境，並不是要評斷或批評像是倚老賣老或是混吃等死這樣的行為。
在某些公職體系中，工作可能需要循序漸進，遵循前人的方法執行。這種方式可以確保穩定性和可靠性。
然而，在私人企業體系中，這些行為會導致 Scrum 的失敗。敏捷開發強調快速反饋、靈活適應和團隊合作，因此需要成員具備主動精神。
最終的執行結果受到團隊中人文、認知等種種因素的影響，這些因素會導致最終執行結果成效不彰。
✨ 案例 1:
公司準備設計某產品，外包給 A 廠商製作，他們有能力分析與完成工作內容，並給予回饋。
然而公司指派給一個沒有能力的冗員負責監督（亦或是冗員搶著說要負責）。
PO 無法判斷此工作是否適合該冗員。而冗員搶了 A 廠商該做的事情，並表現出這個工作需要他才可以進行。
最終變任由該冗員自由發展、自由設計。最終，長久下來的合作沒有任何產品產出。
實際上，該工作若由 A 廠商執行，他們能夠做完全執行、分析，並且，並進行全自動分析會更快（例如參數化設計變數，並執行最佳化分析）。
PS. 產品為一代名詞。
✨ 案例 2:
公司員工 A 曾獨立開發一款軟體，並獲得好評。
然而該同事已離職。雖然有留下原始碼，但因為技術負債而導致沒有人能夠接他的程式碼。
進而指派員工 B 使用全新的軟體架構來實現一樣的軟體。
以上兩個案例（或更多），只是凸顯出傳統團隊內的能力不足、技術負債與重複工作問題。
實際上的問題，如果更深層來看可能是缺乏溝通、多一事不如少一事或是領導力不足甚至是不平等待遇所導致。
有產出的團隊需要什麼？
專業的人
在一個團隊中，確保對的團隊成員在擅長領域發揮所長，避免浪費資源。
還包含像是團隊內要有
優秀的領導人，與對應知識的團隊成員。沒有專業的人在團隊內只會凸顯團隊的無能與無貢獻。
信任
主管講得天花亂墜，最終又因為許多事情而改變方向。造成成員內部互相矛盾而信任破裂。執行力也會大幅下降。
亦或是本身團隊內部成員已經有疙瘩了，不信任的情況下只會越來越多衝突。
足夠的薪水報酬
基於信任，相信薪水應該在某個水平。
一旦被得知薪酬給得不夠，信任也不用談了。
愛（❤️）
有了信任、錢給夠了，愛自然就產生了。
愛你自己的工作、在工作上獲得成就感，自然而然貢獻整個團隊，整個團隊有了更多資源，向心力也進而提升。
✨ 案例:
曾接觸到的公司制度自由，但缺少了 1, 2, 3。隨著時間的推移，對於工作的愛也就消逝了。
對於公司主管他們是站在資方面的，秉持著多一事不如少一事的態度，問題沒辦法從根本解決。
在不願意改善專業人才、信任與薪酬的情況下，Scrum 很難如預期正常運行。
目前執行的 Scrum
考慮到信任的不足，重新審視團隊在執行 Scrum 過程中，發現其中許多情境實在令人感到幽默。
Story Point
是用來衡量每一項任務的複雜程度，但最終常被成員來評估時間。
變相的是大家都盡可能的塞滿許多子任務藉此填高分數，塑造自己很忙、貢獻很多。
最終專注在個人任務而非交付功能。
此外，Story Point 會給人一種分數就是 KPI 的指標。或是讓人感覺做了很多重要的事情。
有人將工作拆成很多細小工作，然後給予最低的一分，但有人不是。例如：
- 重複工作拆細，並給 1 分，最後分數 20 分。
- 工作沒有拆細，但工作很難，給予的分數又不夠高，最後 9 分。
且一開始在規劃時，曾執行過 Scrum 的大濕又說不能高於 13 分等限制。
由於工作拆細而分數變高，但有人又限制自己的認知分數，最終結果給人一大堆認知上的錯覺與障礙。
Story Point 其實還有許多可以值得討論的，但局限於系統有些參數沒有被評估到。例如：
- 速度：Story Point / Number of days
- 任務執行速度：Tasks / Number of days
- 任務負載：Tasks / Story Point
Daily stand-up 會議與 Sprints
透過快速、短暫的時間內彼此交代昨天做了什麼、今天要做什麼，以及是否遇到任何問題，可以讓大家互相了解情況。
Scrum 大濕說：自己任務完成可以去看板上找任務來做的。
我想通常在一個團隊中，有愛才能夠持續下去吧？
畢竟，即使能夠快速完成任務，如果對團隊沒有信任了，執行的內容也會更偏向個人事務而非公司事務。
Sprint Review
在第一次的會議中，對於Sprint Review的部分並沒有太多共鳴。
團隊中會有冗員會讓自己看起來很忙。花了半小時講一堆不是他做的東西，但是卻又凸顯自己的貢獻程度。
討論到最後，我們花了大量時間在會議上討論細節。
例如：如何壓接頭、如何確認和探討等技術細節。
結果，第一次的成果展示變得冗長且無趣。
質問對方
某個冗員 C 跟成員 D 可能感情還不錯。
成員 D 說明內容時，C 提出了以下觀點：
- 有做這個工作嗎？
- 問一個很專業的問題____
- 也不知道你這樣對不對
- 應該有什麼其他方式來____
冗員 C 平常常常說些無意義的話，但實際上他也不知道該怎麼做。
最後，他只是為了表現自己而發表一些言辭，這讓人感到心累。
不斷更換軟體
從一開始的 Jira、Trello 如今到 Asana。
在上傳資料時，總是擔心資料外洩的問題。
然而，並且沒有邀請專業人員（例如 MIS）參與會議，以評估是否適合自行架設服務（self-hosting）。
實際上，這一切都歸結於公司是否願意投資於這種專案管理工具軟體。
我想，等 Asana 的試用版過期後，過一段時間可能又會考慮更換其他軟體。
結論
其實不管在哪個公司或團隊中，這些人、問題永遠都會存在著。
唯一能做的就是調整自己的心態，學會看開，並適應這種情況，甚至考慮轉換方向。
對於主管來說，有些事情是無法處理的。他們可能選擇消極的態度，或者過度友善地默許冗員的存在。
而在更高層的領導者眼中，則是被底下的 PO 矇著。還產不出實際產品與可能，陪著瞎忙繼續吃老本做代工。
而對於敏捷執行後的結論往往都是：
- 敏捷不會改變現況，只有團隊真正想要改變才能實現進步。
- 敏捷運作到最後都不敏捷。
- 敏捷只記得每天的站立會議。
試著想想
- 用看板等於敏捷？
- 每天站立會議等於敏捷？
- 有請顧問來講課就是敏捷？
許多潛在因素像是：
- 團隊之間是否彼此信任？
- SM 有沒有辦法得知開發團隊達成目標的潛在障礙？
- PO 有沒有辦法得知 Stakeholders 的需求？
- 團隊成員的專業技能是否能夠獨立完成份內工作？
- 團隊成員是否具有高度的自主性？
- Sprint Review 是否為有效會議？
- Daily stand-up 是否每天執行與是否為流水帳？
- Sprint 事項是否為了完成而隨便執行？
- 公司的組織文化是否支持敏捷開發方法？
- SM 有沒有因公司組織文化提供客製化敏捷？
也因為團隊內部太多人擅於找一堆理由來掩飾組織、團隊、個人的問題。
自主性不高的團隊成員，套用了敏捷也始終不會敏捷。
反倒是公司主管或領導可以問問自己：
- 公司養了多少冗員？
- 哪些員工是真正有付出價值與產出的？
- 冗員你要如何讓他做事？不干擾其他人？
- 沒有能力或能力較差的成員該如何安排？
- 公司沒人力，是否主動且積極尋找新員工？
- 真正遇到不合適的員工是資遣他還是安排更適合的位置？
- 有付出的員工，薪資是否對得起那些不做事的？
- 員工內部自我訓練與 SOP 有被建立起來嗎？
不過對於這些高層領導，公司又不是他們的。
誰又願意沒事找事做進行人事改革呢？
頂多把那些冗員的考績打差罷了。問題有因此而解決嗎？