雖然「敏捷創新」跨出了資訊科技領域，廣泛應用在行銷、轉型、管理等領域，但在企業裡實施仍有嚴重阻礙，高階主管常有一些做法破壞了敏捷法的效果。本文因此提出幾個解決方案，像是了解哪些情況適合採用敏捷法、從小規模著手、由高層開始採用等。
「敏捷創新」的各種方法已徹底改變了資訊科技業，過去25 至30 年間，大幅提升軟體開發的成功率，改善品質和上市速度，提升資訊科技團隊的動力和生產力。
敏捷法涉及新的價值觀、原則、實務和效益，是與命令及控制型管理大不相同的另類選擇，如今敏捷法廣泛應用在各行各業及多種職能中，甚至傳到了最高層級主管。美國的全國公共廣播電台（National Public Radio）採用敏捷法來規畫新節目；約翰迪爾公司（John Deere）使用敏捷法開發新機具；紳寶（Saab）用它來製作新的噴射戰鬥機；雲端備份服務業的領導廠商Intronis 用它來行銷；全球第三方物流商羅賓昇國際聯運公司（C.H. Robinson）把它應用在人力資源上；教堂鐘聲酒莊（Mission Bell Winery）把它應用在所有流程上，從釀酒到倉儲，再到資深管理團隊的運作，都採用敏捷法；奇異（GE）使用敏捷法加速轉型，要從20 世紀的綜合集團，變成21 世紀的「數位工業公司」。敏捷法讓人脫離獨立運作的部門，組成自我管理、顧客導向的跨領域團隊，不僅加速了有獲利的成長，也幫忙培養出新一代的全方位經理人。
敏捷法的普遍運用，讓人不禁聯想到多種有趣的可能性。也許公司推出的新產品增加50％就可創造正報酬，也許行銷方案可讓顧客詢問度提升40％，也許人力資源部招募到的最優先目標人選可增加60％，也許認真工作的員工會是現在的兩倍。敏捷法已為資訊科技界帶來這種程度的大幅改善效果，它為其他領域帶來的改善機會也很龐大。
但應用在企業裡仍有嚴重的阻礙。我們問經理人對敏捷法的了解時，他們常露出尷尬的微笑，只說他們「略知皮毛」。他們可能會不時提及敏捷法的相關用語，像是「衝刺週期」（sprint）、「時間盒」（time box）等，宣稱他們的公司變得愈來愈靈活了，但其實他們沒有受過訓練，因此並不真的了解敏捷法。所以，他們不知不覺仍以違背敏捷原則和實務的方式來管理，破壞了屬下那些敏捷團隊的成效。
這些高階主管推出無數個行動方案，訂下緊迫的期限，而不是指定兩、三個優先任務。他們讓自己及底下的優秀人才一次投入太多專案，找敏捷團隊成員開會的頻率太高，成員不得不擱下工作或派代表去開會。很多高階主管過度介入個別團隊的工作，講得太多、聆聽不夠。他們執意推動底下團隊早就考慮過、但暫時擱置的不重要構想。他們經常推翻團隊的決定，又疊床架屋，增設層層的審核和控制機制，以確保錯誤不再發生。他們雖然立意良善，但那些做法都破壞了敏捷創新可帶來的效益。
敏捷就是為了要創新，雖然敏捷法應用在例行的運作和流程上不是那麼有效，但如今企業大多是在高度變動的環境中營運，不只需要新的產品和服務，還需要職能流程的創新，尤其是現在新的軟體工具又那麼迅速普及。公司如果營造出適合敏捷法發揮的環境，團隊在推出新產品和新服務方面，以及職能流程方面，都能更快創新。
我們擔任這些公司的顧問，並研究這些公司，結果發現領導人若想要善用敏捷法的潛力，應採取以下六種關鍵做法。
1. 學習敏捷法如何運作
有些高階主管似乎把敏捷聯想到混亂無序（每個人做自己想做的事），有些人則以為敏捷是指「照我的話做，但要做快一點」，可是這兩者都不是敏捷法（見邊欄：「敏捷法的價值觀和原則」）。敏捷法有很多種，它們大同小異，但強調的重點稍微不同。敏捷法包括scrum、精實開發（lean development）、看板管理（kanban）。scrum 強調以創意和應變式的團隊合作，來解決複雜的問題；精實開發的重點，在於持續消除浪費；看板管理則是把焦點放在減少前置時間，以及在製品（work in process）的數量。本文作者之一（薩瑟蘭）幫忙開發了scrum 法，他的靈感有部分是來自1986 年《哈佛商業評論》的〈新產品開發的新局〉（The New New Product Development Game，該文是由筆者之一的竹內弘高與人合撰）。業界採用scrum 及相關方法的數量，至少是其他方法的五倍，因此本文就以scrum 為例，來說明敏捷實務。
scrum 的基本原則比較簡單。組織為了把握某個機會，找三到九人組成小團隊（他們大多是全職加入團隊），並授權給他們執行任務。這是一個跨部門的團隊，成員具備完成任務所需的一切技能。團隊自主管理，並全權負起任務的完整責任。
有些高階主管似乎把敏捷和混亂聯想在一起。
團隊的「計畫負責人」又稱「產品主人」，要負責為顧客（包括內部顧客及未來使用者）和事業提供價值。這個人通常來自事業單位，他有部分時間和團隊合作，部分時間則協調重要的利害關係人，包括顧客、資深經理人、業務經理。計畫負責人可運用設計思維或群眾外包之類的技巧，把看來前景不錯的機會，建立成一份詳盡的「組合清單」（portfolio backlog）。接著，他必須根據對內部或外部顧客的估計價值，以及對公司的最新估計價值，不斷更新那份清單的順序。
計畫負責人不會告訴團隊誰該做什麼，或是任務時間多長，而是由整個團隊規畫一份簡單的藍圖，只有那些在執行前不會改變的活動，才會有詳細的計畫。團隊成員把排序最高的任務分成一些小模組，決定團隊要做多少、如何完成，並為「完成」做出清楚的定義，接著就開始在很短的週期內（通常不到一個月），也就是所謂的「衝刺週期」，為產品打造出可行的版本。「流程引導者」通常是訓練有素的scrum 專家，會負責指引流程，避免團隊受到干擾，讓大家更能集思廣益。
對每個人來說，這個流程都是透明的。團隊成員每天都會開短暫的「站立」會議，以檢討進度及找出阻礙。他們透過實驗和回饋意見來化解歧見，而不是透過無止境的辯論或訴諸權威。他們找少數幾位顧客來，在短期內測試部分或全部的產品原型。如果顧客反應熱烈，即使高層不喜歡原型，或是其他人覺得原型需要更多附加特色，他們還是會馬上發布原型。接著，團隊開始腦力激盪，思考改善未來週期的方法，並準備處理下一個優先任務。
相較於傳統的管理方式，敏捷法有幾個主要優點。那些優點都經過研究證實，也有文獻紀錄。敏捷法可提升團隊生產力及員工滿意度。多餘的會議、重複的規畫、過度的紀錄、品質缺陷、價值不高的產品特色，全都會造成浪費，敏捷法可以把這些浪費降至最少。敏捷法藉由提升能見度，以及持續隨著顧客的優先要務改變而作調整，來改善顧客的參與度和滿意度，使有價值的產品和功能更快上市，也更容易預期，並降低風險。敏捷法把來自多元領域的團隊成員變成協作伙伴，藉此拓展組織經驗，以及培養互信互重。敏捷法幫助高層大幅縮減他們浪費在仔細管理各部門專案的時間，使他們更專注在只有他們才能做的高價值工作，例如，建立與調整企業願景、設定策略性計畫的優先順序、簡化與聚焦工作、指派適合的人才去執行任務、增加跨部門協同工作、移除阻礙進步的障礙。
2. 了解敏捷法何時可行，何時不可行
敏捷法不是萬靈丹，它最容易應用在軟體創新的常見情況，而且效果最好：需要解決的問題很複雜，一開始不知道解決方案，產品規格很可能改變，工作可以模組化，可和最終使用者密切合作，從他們那邊迅速獲得回饋意見，創意團隊通常表現優於命令與控制型團隊。
根據我們的經驗，很多產品開發部門、行銷專案、策略規畫活動、供應鏈挑戰、資源配置決策，都有上述那些情況。但這類情況較少見於日常營運單位中，像是工廠維護、採購、業務拜訪、會計（見表：「適合敏捷法的情況」）。敏捷法需要訓練、改變行為，而且通常需要新的資訊科技，因此高層必須判斷預期的效益，是否值得大家投入心力和費用。
敏捷創新也需要一組積極參與的核心成員。
敏捷法的核心原則之一，是「以積極認真的員工為核心來打造專案，提供他們需要的環境和支援，相信他們會完成任務」。當公司、部門或團隊中的多數人都選擇採用敏捷法，領導人也許應該逼仍在抗拒的人也跟進採用，或甚至換掉那些人。不過，比較好的做法是號召熱情自願參加的人，而不是逼迫抗拒的人。
OpenView 創投公司就是採用這種方式。OpenView 投資了約三十家公司，公司創辦人史考特． 麥克斯韋（Scott Maxwell）從投資組合裡的幾家公司學到敏捷法，於是開始在自家公司實施這種方法。他發現敏捷法較適合某些活動，但有些活動不見得適合。例如，策略規畫和行銷上很適合採用敏捷法，因為這兩個領域裡的複雜問題通常可以分成一些模組，由跨領域的創意小組解決。但應用在銷售上就行不通了，每次銷售人員進行業務拜訪時，可能當場就會需要改變待辦清單。每個小時都重組業務團隊、改變組合清單、重新分配客戶，實在太複雜，也太費時了。
敏捷創新需要一組積極參與的核心成員。麥克斯韋為OpenView 投資組合裡的公司，提供敏捷原則與實務的訓練，讓他們自己決定要不要採用敏捷法。有些公司欣然採用，有些公司因優先要務不同而決定暫緩實施。例如，Intronis 公司就是愛用者，它的行銷部門原本採用一套年度計畫，主要是鎖定商展做行銷。業務部門抱怨行銷太保守了，沒有效果，所以公司聘請原是網路開發人員的行銷人員理查．德拉哈耶（Richard Delahaye）來實施敏捷法。在德拉哈耶指導下，行銷團隊學會不需要幾個星期，而只要幾天，就能推出主題式網路研討會（他們迅速開了一場探討勒索軟體CryptoLocker 的研討會，吸引六百人來註冊，創下公司紀錄）。如今，團隊成員持續為數位行銷部門規畫行事曆和預算，但對偶然的開發工作，則很少詳列細節，容許較大的彈性。現在，銷售團隊比以前滿意多了。
3. 從小規模做起，讓口碑傳開
大公司常把變革計畫當成重大的活動推出，但推動敏捷法的最有效方式，通常是從小規模做起。一般是從資訊科技部門開始，因為軟體開發人員可能較熟悉這些原則。接著，敏捷法可能傳播到其他部門，由已熟悉敏捷法的人擔任教練。每次採用敏捷法出現效果時，就會產生一群熱中的推廣人，他們都等不及想讓公司其他同事知道敏捷法有多好用。
農機公司約翰迪爾採用及推廣敏捷法的方式，就是很好的例子。軟體工程師喬治．托梅（George Tome）在約翰迪爾的企業資訊科技部門擔任專案經理，2004 年，他開始低調地採用敏捷原則。後續幾年內，約翰迪爾公司內其他部門的軟體開發單位也逐漸跟進採用。隨著大家對敏捷法愈來愈感興趣，就比較容易把敏捷法導入公司的事業發展和行銷單位。
2012 年，托梅在研發部門的企業進階行銷單位擔任經理，那個單位負責發掘可能徹底改變約翰迪爾產品的技術。傑森．布蘭特利（Jason Brantley）是該行銷單位的領導人，他擔心傳統的專案管理技巧拖慢了創新，於是與托梅兩人決定改用敏捷法，看能不能加快創新速度。托梅邀另外兩個單位的經理人來上敏捷訓練課程，但敏捷法的所有術語和例子，都來自軟體領域，其中一位經理人欠缺軟體背景，因此完全聽不懂。托梅明白其他人可能也有同樣的反應，於是找來一位敏捷法教練，那位教練知道如何訓練沒有軟體背景的人。過去幾年，托梅和那位教練一起訓練研發部門內五個中心的所有團隊。托梅也開始每週發表一頁談敏捷原則和實務的文章，並以電子郵件寄給有興趣的人，後來那些文章也貼上約翰迪爾的Yammer網站，有數百位約翰迪爾員工加入討論群組。「我想為約翰迪爾建立一套專屬的敏捷法知識庫，讓公司裡的人都能了解。」托梅說：「這樣做可以打好基礎，以便更容易把敏捷法推廣到公司的任何一個單位。」
企業進階行銷單位使用敏捷技術，大幅壓縮了創新專案的週期，有些專案的壓縮幅度甚至超過75％。例如，他們花了約八個月開發出一款新機型的原型，目前約翰迪爾尚未公開那款新機型。布蘭特利指出：「傳統流程如果一切順利，最快需要一年半的時間才做得到，一般可能要拖兩年半或三年。」敏捷法也帶來其他改進效果，那個行銷單位的團隊參與度和滿意度，從原本分數落在全公司倒數三分之一，迅速提升至前面三分之一。工作品質改善了，速度平均快了兩倍以上（速度的算法，是衡量每次衝刺週期完成的工作量），有些團隊的速度甚至快了四倍，還有一個團隊快了八倍。
像這樣的成效，吸引了大家的關注。托梅指出，現在，約翰迪爾內幾乎每個領域都有人開始使用敏捷法，或是思考如何運用敏捷法。
4. 讓熟練的團隊自行設計做法
日本武術的學生，尤其是學習合氣道的人，常學習一種叫「守－破－離」的流程。在「守」的狀態，他們研究既有法則。熟悉法則之後，就進入「破」的狀態，開始另闢蹊徑，修改傳統形式。最後他們晉升到「離」的狀態，徹底融會貫通各項法則，因此能夠隨心所欲地即興發揮。
熟悉敏捷創新的過程也很類似。個人或團隊先練習數千家公司普遍使用的方式，從中受惠，之後才開始修改或自訂敏捷法。例如，避免一開始就指派兼職任務給團隊，或是避免輪調成員。實證資料顯示，在生產力及因應顧客意見的能力方面，穩定的團隊都比輪調成員團隊高出60％。
長期運用敏捷法之後，應讓熟練的團隊根據自己的情況來設計敏捷法實務。例如，敏捷法有一項原則規定，團隊應該讓進度和障礙都維持清晰可見。一般最常見的做法，是使用大型白板，也就是「看板」，把彩色便利貼從「待辦事項欄」轉貼到「正在執行欄」，接著再轉貼到「完成欄」。許多團隊仍維持這種做法，也樂於讓非成員來團隊辦公室裡觀看與討論進度。但有些團隊改用軟體程式和電腦螢幕，以盡量減少輸入時間，且讓資訊可同時分享給位於不同地點的人。
像這樣按當下情況隨時作改變，有一個重要的指導原則是：如果團隊想更改特定做法，應實驗及追蹤結果，確定這些改變確實改善了顧客滿意度、工作速度和團隊士氣，而不是愈改愈差。
音樂串流公司Spotify 就是熟練敏捷法後，自行設計實務做法的典範。Spotify在2006 年成立，從一開始就採用敏捷法。他們從產品開發到行銷與一般管理，整個商業模式都是透過敏捷創新，提供更好的顧客體驗。但資深領導人不再規定具體做法，而是鼓勵大家實驗和靈活調整，只要改變後的做法仍符合敏捷原理，且能顯現改善結果。所以，Spotify 內部的七十個「小隊」（Spotify 對敏捷創新團隊的稱法）和「支部」（Spotify 對職能單位的稱法，像是使用者介面開發部、品質測試部），各單位的做法幾乎都不一樣。雖然每個小隊大多是由小型的跨部門團隊組成，並使用某種形式的視覺進度追蹤、排列優先順位、調適型規畫、召開腦力激盪會議討論如何改善工作流程，但許多團隊省略了敏捷團隊常用的「燃盡圖」（burndown chart），或稱為「待執行工作圖」，顯示已完成的工作，以及剩下仍待完成的工作。此外，他們也不常衡量速度、做進度
報告，也不使用同樣的技術去估計某項任務所需時間。這些小隊都測試了自己修改的做法，結果發現新做法能改善成果。
5. 高層也採用敏捷法
最高層級主管的一些活動不適合採用敏捷法，例行工作和可預測的任務大多屬於這類，例如，績效評估、媒體採訪、巡視工廠、拜會顧客和供應商等，都不宜採用敏捷法。但很多也許算是最重要的活動，適合採用敏捷法，例如，策略規畫和資源配置、培育突破性的創新、改善組織協同工作。資深高階主管組成敏捷團隊，並學習把敏捷原則應用在這些活動，可獲得深遠的效益。他們自己的生產力和士氣都會提升。他們和自己授權的團隊，使用同樣的語言，經歷共同的挑戰，並學習如何克服挑戰。他們更容易發現會妨礙敏捷團隊的行為，並阻止那些行為。他們學習簡化及專注工作。工作成果因而改善了，整個組織的信心和參與度也有提升。
有些公司挑選了幾位領導人，重新配置他們的時間，讓他們把25％或更多時間，從獨立運作的部門改用在敏捷領導團隊。這些領導團隊負責排定整體企業組合清單的優先順序，建立和協調組織中其他地方的敏捷團隊，以處理最優先的任務，系統化地消除有礙成功的障礙。以下是最高層級主管採用敏捷法的三個例子：
1. 跟上團隊的腳步
Systematic 是一家525 人的軟體公司，從2005 年開始採用敏捷法。隨著敏捷法普及到所有的軟體開發團隊，公司執行長兼共同創辦人麥可．霍姆（Michael Holm）開始擔心自己的領導團隊阻礙了進步。「我感覺自己好像在說：『跟我來，我就在你後面。』」他告訴我們，「開發團隊使用scrum，以不同的方式做事，但管理團隊還是以傳統方式做事。」管理團隊的行動太慢，太依賴書面報告，而報告的內容看來總是已過時。所以在2010 年，霍姆決定讓他領導的九人管理團隊用敏捷法來運作。
管理團隊重新排列管理活動的優先順序，取消一半以上的例行報告，把其餘的報告改成即時系統，同時更加關注攸關業務的關鍵項目，像是銷售提案和顧客滿意度。領導團隊一開始原本決定每星期一開會一、兩個小時，但後來發現決策的步調太慢，於是改成每天早上8 點40 站著開會二十分鐘，討論前一天每個成員做了什麼、當天打算做什麼、他們有哪些地方需要協助。最近，管理團隊開始使用實體的白板，追蹤各個成員的行動及各事業單位的改善情況。現在，包括人力資源、法律、財務、業務部等其他部門，也以類似的方式運作。
2. 加速企業轉型
2015 年，奇異改變公司定位為「數位工業公司」， 把焦點放在數位賦能（digitally enabled）產品。轉型的一部分是設立「奇異數位」（GE Digital）單位，其中包含公司內兩萬多位與軟體有關的員工。布瑞德．蘇拉克（Brad Surak）原是軟體工程師，現在是奇異數位的營運長，他非常熟悉敏捷法。他先以負責開發產業網路應用程式的領導團隊來實驗scrum，最近，他開始把scrum 應用在本身單位的管理流程上，像是營運檢討。蘇拉克是計畫負責人，另一位工程高階主管是scrum 專家，他們一起排列高階主管團隊應處理事務的優先順序，包括簡化各團隊取得硬體的行政流程，以及解決需要多個奇異事業單位提供意見、棘手的產品定價議題。
scrum 讓大家洞悉高階主管每天在忙什麼。
scrum 團隊成員的每個衝刺週期為兩星期，每星期站著開會三次，他們把進度畫在開放會議室的白板上，任何員工都看得見。蘇拉克表示：「這讓大家知道高層每天在忙什麼，員工想知道我們和他們重視的東西是否一樣。」領導團隊也收集員工的滿意度調查，並針對阻礙有效運作的障礙，進行根本原因分析，再向整個組織的員工報告。這等於是告訴全體員工，高層已聽到大家的意見，並提出改進做法。蘇拉克認為，這樣做可讓組織了解「高階主管和工程師用同樣的方式工作」，提升員工對敏捷做法的採用動機和實際投入。
3. 使部門和職能有共同願景
艾瑞克．瑪泰拉（Erik Martella）在星座公司（Constellation Brands）旗下的教堂鐘聲酒莊擔任副總裁暨總經理，他在公司裡推動敏捷法，使這個方法普及到整個組織。各部門領導人擔任自家部門內各個敏捷團隊的計畫負責人。那些團隊都創造了驚人的成效，但瑪泰拉擔心他們的時間不夠用，也擔心部門的優先要務和企業的要務不見得一致。因此，他決定召集各部門領導人組成一個高層敏捷團隊，專注處理對跨部門協作最有價值及機會最大的、全公司層級的計畫，像是改善倉儲流程。
該團隊負責建立及持續改進企業的優先要務清單，以確保敏捷團隊處理該處理的問題，以及擁有充足的資源。團隊成員也避免組織投入不值得優先處理的主管個人偏好專案，例如，瑪泰拉採用敏捷法不久，就收到星座公司總部某位高階主管來信，希望教堂鐘聲酒莊去研究了解他熱中的一項東西。以前瑪泰拉接獲這種要求時，可能會回應：「沒問題，我們馬上去看。」現在他則回應酒莊會依循敏捷原則來處理這件事，也就是把那項建議納入潛在機會清單，排列優先順位。結果，那位高階主管很喜歡這種做法，當他得知他的建議在優先順位中排名不高時，也欣然接受。
在如今這種過度專業分工的組織裡，職能部門經理極少脫離獨立運作的部門。參與敏捷團隊可幫部門經理勝任全方位的管理工作，讓他們接觸其他領域的人，教他們協同工作的實務，凸顯出與顧客密切合作的重要，這些都是對未來的領導人很重要的能力。
6. 消除阻擋敏捷行為的障礙
Scrum 聯盟（Scrum Alliance）這個四十幾萬名會員組成的非營利獨立組織研究發現，70％以上採用敏捷法的人表示，他們的團隊和組織內其他單位曾出現關係緊繃。這並不令人驚訝，畢竟他們採用的是不同的藍圖，而且以不同的速度運作。
以下是一個顯著的例子：我們研究的某家大型金融服務公司進行試辦計畫，打算使用敏捷法打造下一個行動應用程式。當然，第一步是組成團隊，那需要先申請預算審核，以取得推動專案的經費。那項預算申請被納入下個年度的規畫流程中，和一堆提案一起爭取審核通過。經過幾個月的審核，公司最後批准了經費。試辦結果設計出一個有效的應用程式，受到顧客好評，團隊都為本身的成果感到自豪。但那個應用程式正式上市之前，必須先經過傳統「瀑布」式流程的潛在弱點測試，那個流程相當冗長，電腦程式需要測試文件紀錄、功能、效率、標準化，而且等待進行那個流程的計畫很多。接著，應用程式還必須整合到核心的資訊科技系統中，那又需要進入另一個瀑布流程，又要拖六到九個月的時間。最後，從設計到發布的總時間，其實並沒有快多少。
以下是消除敏捷障礙的技巧：
讓每個人都清楚事情的進展
即使不是所有負責公司優先要務的團隊都使用敏捷流程，但只鎖定一小部分複雜問題的個別團隊，還是需要了解整個企業的優先要務，跟大家從同樣的優先要務著手。如果新的行動應用程式是軟體開發的最優先要務，就必須也是預算編列、潛在弱點測試、軟體整合的最優先要務，否則敏捷創新很難落實。本身也採用敏捷法的管理團隊，這就是他們應該擔負的主要責任。
別馬上改變架構，應先改變角色
許多高階主管認為，建立更多跨部門團隊，就一定能促進組織架構的重大改變，其實不然。高度授權的跨部門團隊，顧名思義，確實需要某種矩陣式管理。但他們最需要的，是讓不同領域學習如何同時合作，而不是陸續地分別運作。
每個決定只指派一位上司負責
一般人可能有好幾位上司，但不能由多位上司來負責作決定。在敏捷作業模式中，必須清楚確立誰負責帶領跨部門團隊，由他挑選與更換團隊成員、任命團隊領導人、批准團隊的決策。敏捷式的領導團隊常授權一位高階主管負責找出關鍵問題，設計流程來解決那些問題，並為每個創新計畫指派單一負責人。其他資深領導人必須避免事後評論，也不應推翻計畫負責人的決定。你可以提供指引和協助，萬一你不喜歡計畫的結果，可以改變計畫負責人，但不要把他批評得一文不值。
專注在團隊，而不是個人
麻省理工學院集體智慧中心（MIT Center for Collective Intelligence）和其他單位的研究顯示，雖然個人的智慧會影響團隊績效，但團隊的集體智慧會更重要，而且較容易改變。敏捷團隊透過流程引導者來持續改進集體智慧，例如，釐清角色、傳授化解衝突的技巧、確保團隊成員做出均等的貢獻。另一個有幫助的做法，是把衡量指標從產出和利用率（大家忙碌的程度），改成商業結果和團隊滿意度（大家的價值和投入程度）。另外，肯定與獎勵制度賦予團隊成果的權重，高於個人成果的權重，也是有幫助的。
以問題領導大家，而不是發號施令
巴頓將軍（George S. Patton Jr.）曾為領導人提出一個知名的建議：不要告訴下面的人該怎麼做，「告訴他們做什麼就好，他們的巧思會令你耳目一新。」所以，敏捷組的領導人不該發號施令，應該學習以問題指引大家，例如，詢問：「你有什麼建議？」「我們怎麼測試那點？」這種管理風格可幫職能領域的專家變成通才型經理人，也幫企業的策略人員和組織從爭奪權力和資源的獨立壁壘，變成協同工作的跨部門團隊。
高層能載舟，也能覆舟
過去三十年來，軟體業經歷的改變，無疑比其他商業領域還要迅速及深遠，而敏捷創新徹底改革了軟體業。現在，敏捷創新也將改變各行各業的幾乎各種職能。在這個時點，最大的阻礙不在欠缺更好的方法，或是效果顯著的實證，也不缺敏捷法可在資訊科技以外領域有效運作的證據，最大的阻礙，其實是高階主管的行為。高階主管若能學習把敏捷法延伸運用到更廣泛領域的商業活動，就能加速有獲利的成長。
Embracing Agile
戴瑞．里格比 Darrell K. Rigby , 傑夫．薩瑟蘭 Jeff Sutherland , 竹內弘高 Hirotaka Takeuchi
洪慧芳譯自“Embracing Agile,”HBR , May 2016: https://www.hbrtaiwan.com/article_content_AR0003465.html
