只有產品開發使用敏捷法，仍不算敏捷組織

過去，「敏捷工作法」（agile）可能只出現在軟體開發領域，但現在，無論你提供的是什麼服務或產品，所有公司都正變成某種「軟體公司」，必須跟上敏捷的腳步，改變管理組織的方式。然而，大多數企業只注重讓產品開發團隊變敏捷，卻忘了一項重要事實：如果人資、財務和管理部門不敏捷，技術團隊也不可能真正敏捷。

軟體已經吞食整個世界。而且隨著軟體持續破壞許多不同的新產業，它也正在改變企業的經營方式。無論我們提供的是什麼產品或服務，全都身處於「軟體產業」中，這迫使我們重新檢視如何形塑與管理組織。

我每次詢問經理人，他們的組織是否有實施敏捷工作法（agile），得到的幾乎都是肯定的答案。如果更深入一點探詢就會發現，他們的敏捷做法多半僅限於產品開發團隊，特別是軟體工程團隊。很少有人提到「人資團隊的敏捷法」或「財務團隊的持續改善」。然而，敏捷法就是必須在這些基礎領域扎根，才能支持軟體驅動的業務。

隨著軟體開發持續朝「持續交付」（continuous delivery）的方向發展，我們得以創造一種與市場對話的新類型，那就是「持續對話」。我們現在能夠在幾小時內進行產品的部署、觀察、衡量、訪談、學習與最佳化，而不必花幾個月來做這些事。我們可以迅速做出決定，可以一夕轉變方向。為了支持業務快速、反覆優化，負責配置、資助、管理與獎勵員工的各個內部單位，也必須展現同樣程度的敏捷。「我們一向的做事方法」開始造成管理階層與那些執行團隊產生直接衝突。

讓我們先看看人資的情況。人資單位運作的核心目標，就是徵人。傳統的徵人做法，通常就是列出必須具備的一系列工具和能力，再搭配一些像是「態度主動」、「有團隊精神」之類的模糊說詞。職務說明的內容，是為了填補特定部門（例如軟體工程團隊或設計團隊）的某個職缺。招募人員為了儘快找人補上，會快速查閱所有履歷表，尋找列出的那些技能組合，確保進入下一輪徵選的人都「符合所有條件」。3年的Rails開發經驗？符合。GitHub經驗？符合。符合條件的人選名單會傳送給聘雇經理，接著聘雇經理必須儘快做出決定，確保人資團隊達成設定好的聘雇效率目標。