August 19, 2026企業為什麼要推動敏捷？從打造團隊、擴大敏捷，到運用敏捷創新與保持工作樂趣，真正重要的不是做了多少敏捷實踐，而是能否更有效地創造價值。 敏捷是工具，不是策略 企業開始推動敏捷時，很容易先討論方法：要不要採用 Scrum？ Sprint 要跑一週還是兩週？每天是不是都要開站立會議？應該使用哪一套管理工具？ 這些問題都很實際，卻不該成為最先回答的問題。 《打造敏捷企業》第八章提醒，企業應該先確定想達成的策略目標，再判斷哪些地方適合使用敏捷。 敏捷可以協助組織加快學習、降低創新的風險，也能讓團隊更快回應顧客需求，但它無法取代企業對方向的選擇。 如果組織沒有清楚的目標，再快的迭代也可能只是更快地繞路。 如果團隊不知道想解決什麼問題，再完整的敏捷儀式，也可能只剩下一套固定行程。 因此，真正的起點不是「公司要怎麼導入敏捷」，而是： 我們希望透過敏捷，改善什麼？ 回頭看前幾篇「鈦編讀好書」介紹過的鈦坦實務，不論是用小規模實驗驗證顧客需求、以看板呈現 IT 部門的工作瓶頸，或重新調整產品開發團隊的責任分工，都不是為了證明某一套敏捷方法有效。 每一次改變，都先從真實問題出發。方法只是幫助團隊解題的工具，而不是最後要抵達的地方。 我們以「Fail Fast、Fail Cheap、Fail Often」為原則，從這個基礎小步試錯、持續快跑、擁抱改變。…
August 17, 2026敏捷轉型為什麼推不動？先判斷人們處於哪個變革階段 文章內文 從兩次轉型經驗，談業務問題、關鍵角色與 Rick Maurer 的變革循環 高層已經宣布轉型，團隊也接受了培訓，新的流程甚至已經上線，為什麼大家還是不願意改變？ 問題可能不在方法，而在於推動者與組織成員根本不在同一個變革階段：高層已經準備全面推行，第一線成員卻還沒有看見改變的必要；轉型小組忙著設計流程，部門主管仍在懷疑這件事能否解決自己的問題。 這時候，繼續宣傳 Scrum、增加培訓或要求大家遵守流程，通常只會帶來更多抗拒。 我曾參與數位化轉型、流程改進與敏捷轉型。回頭看這些經驗，我逐漸形成一個判斷： 敏捷轉型不是導入一套框架，而是圍繞真實的業務問題，集結組織內可用的力量，並根據人們所處的不同變革階段採取行動。 因此，在討論如何推動變革之前，我們需要先回答兩個問題。 第一個問題：這次轉型要解決什麼業務問題？ 我第一次深刻體會這件事，是在一家銷售型企業導入 Scrum 的時候。 這家公司的主要業務是辦公家具與影印機的銷售和租賃。產品使用與租賃週期很長，如果業務人員與客戶往來的頻率太低，很容易在下一次採購時失去客戶。公司因此決定發展辦公用品採購服務，希望透過更高頻的交易維持客戶關係。 當時，新的業務模式還沒有成形，客戶究竟需要什麼也不清楚。我們沒有先要求其他部門「配合 Scrum」，而是由開發團隊先建立兩週一次的交付節奏，持續與業務端核對需求，再根據回饋調整產品。…
