4/4 可免費閱讀文章篇數免費閱讀

本文出自

提升「失敗報酬率」

提升「失敗報酬率」

2016年5月號

延伸閱讀

變身敏捷企業

Embracing Agile
戴瑞.里格比 Darrell K. Rigby , 傑夫.薩瑟蘭 Jeff Sutherland , 竹內弘高 Hirotaka Takeuchi
瀏覽人數:15189

  • 文章摘要
  • "變身敏捷企業"


  • 字放大
  • 文章授權
    購買〈變身敏捷企業〉文章授權
  • 購買文章
    購買〈變身敏捷企業〉PDF檔
    下載點數 10
變身敏捷企業
TODD ST. JOHN
雖然「敏捷創新」跨出了資訊科技領域,廣泛應用在行銷、轉型、管理等領域,但在企業裡實施仍有嚴重阻礙,高階主管常有一些做法破壞了敏捷法的效果。本文因此提出幾個解決方案,像是了解哪些情況適合採用敏捷法、從小規模著手、由高層開始採用等。

「敏捷創新」的各種方法已徹底改變了資訊科技業,過去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,”HBR , May 2016)



戴瑞.里格比 Darrell K. Rigby

貝恩公司(Bain &Company)波士頓辦事處合夥人,擔任全球創新和零售實務主管。


傑夫.薩瑟蘭 Jeff Sutherland

與人共同創立了敏捷創新方法當中的Scrum 法,現任Scrum 公司執行長,提供Scrum 法的顧問諮詢和訓練。


竹內弘高 Hirotaka Takeuchi

哈佛商學院策略組教授。


本篇文章主題創新

你可能還會想看