總結

當團隊缺乏凝聚力與信任感時，敏捷常會變成「例行儀式」：照開 Daily/Review/Retro，但重點放在報告、究責與自保，導致行動緩慢、資訊不透明、風險延後爆炸。要讓敏捷重新跑起來，關鍵不是先增加更多會議或流程，而是先建立「能讓人安心行動」的環境：用小勝利累積信任、降低管理成本、讓資訊流動，並在需要時創造破局點。

背景

• 情境：公司全面導入 Scrum，但形式上敏捷、實質上仍是 command & control（例如 Review 在看工時/燃盡圖、以控制取代協作），團隊成員感受「被強迫」。
• 痛點：信任感低、凝聚力差，尤其常見在中高階之間缺乏互信，連帶讓基層也難以協作。
• 問題核心：當人們相信「出事就背鍋、做錯就被打」，就會避免承諾與決策，資訊開始被藏起來，敏捷只剩外衣。

主要內容

1) 低信任／低凝聚力的典型樣貌

• 高離職率或內轉（turnover 高）。
• 溝通斷層與資訊漏接：常發生「最後才知道」。
• 小圈圈多、互不尊重，討論聚焦在「誰的責任」。
• 決策極慢：關鍵決定都在等主管指令，大家為了不背鍋而不敢承諾。
• 風險延後揭露：通常到「爆的那一刻」才說，導致無法挽回。

2) 高信任／高凝聚力的對比樣貌

• 共同目標清楚，知道「現在這球該投」而不需要層層授權。
• 資訊通透、互相支援與接球（有人卡住會立刻拉人一起看）。
• 開玩笑也不會被解讀成攻擊（心理安全感更高）。
• 願意提早說風險：在爆之前就先求援，影響可控。

3) 沒有信任感時，敏捷會怎麼「跑歪」

• Daily 變成向主管報告，而不是資訊交流與協調。
• 主管不在時更容易看出「真/假敏捷」：若只是例行報告，主管不在就失去交流動力。
• 會議內容充滿防禦與推責：「需求不清」「我不能做」「你當初不是這樣說」。
• 會議變多但成果沒有變好，最後大家更抗拒敏捷活動。

4) 先做什麼：從「小勝利」與「可感的改善」開始

• 先打勝仗（Small win）：先讓交付結果變好，信任與權限才容易上升。
• 先解痛點：用引導把痛點梳理出來，挑 1–2 個「能快速改善、團隊有感」的先做。
• 先降低負擔：Backlog 爆量時，先做優先順序與聚焦（每人先挑 1 件本週必完成），讓團隊重新感受到「做得到」。

5) 讓信任感可被累積：具體感謝與儀式感

• 在 Sprint 結束做 check-out：
  • 這段期間學到什麼？
  • 最想感謝誰？為什麼？（要具體到行為：例如「快速 code review 讓我能順利往下做」）
• 先感謝自己、肯定自己：讓人恢復信心與行動力，才更願意相信他人。

6) 主管視角 vs 基層視角：策略差異

• 主管視角：
  • 先確認公司是否真的賦予「帶人」的權限（不只管事）。若主管沒有足夠的人事/決策權，組織結構與制度需要被檢視。
  • 需要破局點：例如組織調整、新任主管帶來新做法，否則舊的信任破洞很難快速修復。
  • 先從分工合作與資訊透明做起，再談高度協作（對低信任團隊而言，協作門檻太高）。
• 基層視角：
  • 評估自己是否想「change company」或「change the company」。
  • 若沒有足夠動力/空間，換到更健康的環境可能更能保護身心與成長。
  • 若選擇留下，先把焦點拉回自己：建立讓自己穩定、能量充足的方法，才撐得久、等得到局勢改變。

實際應用

1. 診斷現況：列出最明顯的 3 個症狀（資訊不透明/推責/決策慢/離職高…）。
2. 找 1 個可快速改善的痛點：例如「Backlog 太多」或「交付常延遲」。
3. 設計一個 Small win：本週只聚焦少量、可完成、可驗收的目標。
4. 建立透明機制：讓資訊不再「最後才知道」（看板、同步節奏、決策紀錄）。
5. 固定做具體感謝：每次迭代至少一次，建立「被看見」與「心理安全感」。

結論

• 敏捷跑不動時，常不是框架問題，而是信任與心理安全感不足。
• 先用小勝利與可感改善重建信任，再逐步把敏捷活動變得有用。
• 主管需要制度與破局點；基層需要評估去留與自我照顧，才能走得長久。