本文出自

打造跨世代不老企業

打造跨世代不老企業

2019年2月號

以敏捷為名,卻變得更不敏捷》敏捷法不出錯的六大關鍵

Why Agile Goes Awry - and How to Fix It
琳姬.麥奎格 Lindsay McGregor , 尼爾.都西 Neel Doshi
瀏覽人數:4431
  • "以敏捷為名,卻變得更不敏捷》敏捷法不出錯的六大關鍵"

  • 字放大
  • 多人授課購買
    購買〈以敏捷為名,卻變得更不敏捷》敏捷法不出錯的六大關鍵〉文章
  • 個人收藏購買
    購買〈以敏捷為名,卻變得更不敏捷》敏捷法不出錯的六大關鍵〉PDF檔
    下載點數 10
吸引、激勵、留住數位產品人才的能力,已經逐漸成為攸關組織成敗的任務。大多數組織只是把敏捷法當成儀式來實施,結果當然不會變得更好。唯有回歸「動機」和「順應力績效」的基本要素,才能建立一個真正敏捷的組織。

企業組織基於想要變得更有順應力的精神,紛紛運用敏捷法(Agile)來開發軟體。但許多公司的做法,實際上卻讓自己變得更不敏捷。這些公司只是名義上變得敏捷,因為他們實施的流程,最後往往損害了工程人員的動機和生產力。

敏捷軟體開發

敏捷法之類的順應式軟體開發架構,已存在很長一段時間,並呈現多種形式。但其中大多數模式的核心是兩件事:形成假設(例如,應該完成的功能特性是什麼),以及多個領域協作進行實驗;而所有這些都秉持「推動學習」的精神,而不是衝向事實證明並不正確的道路。

敏捷軟體開發法在2001年誕生時,提出一套共四個關鍵原則,以提升軟體開發的技能,並提高工程和產品經理的工作動機。

1. 個人與互動重於流程與工具

2. 可用的軟體重於詳盡的文件

3. 與顧客合作重於合約談判

4. 回應變化重於遵循計畫

在過去三年中,我們對人類動機進行研究,結合使用以意見調查為主的方法和實驗方法,分析了五百多個不同組織中工程師的實務做法。我們發現,實務上的情況,遠遠偏離上述的敏捷原則。

例如,在一般的做法中,「流程與工具」已成為工作的推動力,而不是由「個人與互動」來推動。在一家名列《財星》一百大公司的大型企業中,數位產品主管對我們說:「公司不准我們質疑敏捷流程。」在另一家躋身《財星》五百大的組織中,產品經理和工程師只透過他們的工具來溝通,這些工具主要是讓產品經理向工程師發號施令。

同樣地,文件通常勝過可用的軟體。一家大型科技公司的產品團隊,把重要的前期時間用來編寫小型需求(稱為「用戶故事」)。這些需求被放入一個需求單佇列(ticket queue),讓下一個有空的工程師可以開始著手處理這項任務。讓佇列持續移動的文件門檻變得很高。最後,這個流程成為許多小型「瀑布」之一,所謂的「瀑布」是指工作從產品部門交給設計師,再由設計師交給工程部門。這個流程正是敏捷法要消除的。難怪這家公司的技術長說:「我的工程師感覺就像在餐館後面工作的快餐廚師。」

至於「回應變化重於遵循計畫」,這常被誤解為「沒有計畫」。例如,在一家快速發展的科技公司中,敏捷團隊並沒有試著了解組織更廣泛的策略。因此,他們反覆進行任務(iterate)時,往往聚焦在低價值或策略上不重要的功能特性。如果沒有計畫,團隊就不會知道如何確定行動的優先順序,也不知道如何負責任地投入這些行動。這項原則甚至讓工程師認為,運用時間箱(timebox)或共同的階段性目標是不適當的(編按:「時間箱」是指工作的每項活動都有時間範圍限制)。

如果這些誤用做法,實際上改善了工程人員動機和績效,那就無妨,但我們發現,實務上的情況正好相反。如果按照上述方式實施敏捷法,會降低工程師的總體動機。因為公司不允許他們進行實驗、管理自己的工作、與顧客連結,所以他們不太能感覺到遊戲、潛力和目的等感受;相反地,他們感受到必須要成功的情緒和經濟壓力,或者說他們感受到慣性。他們不再順應調整、學習,也沒有盡全力工作。

例如,一家創投伙伴告訴我們一個故事,有一家電子遊戲開發公司打造某個產品,即使每一位工程師都覺得這個遊戲不值得玩,公司仍持續打造了一年。公司後來發現浪費了大量的時間和金錢。

敏捷流程出錯,因為隨著公司追求卓越績效,它們若不是變得過度強調戰術(過分聚焦在流程和微觀管理),就是過於順應情況而調整(避開長期目標、時間表,或是跨職能部門協作)。

關鍵是要平衡戰術性和順應性的績效。無論你是工程師還是產品經理,應考慮做一些改變,以找到這種平衡,才能改善你的工程團隊(或任何團隊)的動機和績效。

1.軟體開發應是一種無需交接工作的協作流程

在軟體開發流程中,並不是一個人撰寫需求(即使是小需求),另一個人執行需求,所有工作都沒有一個指引方向的固定策略目標。相反的,努力實施真正的敏捷法的團隊,應該要有一個「無工作交接」的流程,而不是一個人撰寫需求,交由另一個人執行需求的流程。在無交接流程中,產品經理和工程師(以及任何其他利害關係人),在設計功能特性時,從頭到尾都是合作伙伴。

首先,這個團隊(包括高階主管),應該闡明團隊的策略「挑戰」。用「問題」的形式來呈現這個挑戰,始終聚焦在改善某種顧客成果或影響。把這些挑戰視為團隊以問題形式來表達的詳細任務使命,以觸發廣泛的思考。那些挑戰本身是由整個團隊來制定和反覆處理的,包括團隊的高階主管贊助者(以及顧客)。這個團隊(或者任何團隊)中的每一個人,都被要求隨時針對每一項挑戰提供想法。

例如,某家銀行的一個挑戰是「我們可以如何協助顧客為可能發生的金融衝擊,作更好的準備?」另一個挑戰是「我們可以如何讓顧客把保持健康的財務習慣,變得更有趣和更輕鬆?」這些挑戰,催生出許多人提出的數十個構想。

接著,這些團隊不是由某個人編寫需求,另一個人執行需求,而是從粗略的草案,到可測試的假設,都用協作的方式發展某個構想,讓構想變得更成熟。

2.團隊的交付單位,應該是最低可行性的實驗

團隊經常發現,他們太過度順應調整,因而浪費時間。為避免這種情況,不僅應針對策略挑戰來形成構想,也應透過快速實驗來執行那些構想,而這些實驗的目標是要有足夠的學習,以了解哪些構想對顧客有用。換句話說,團隊應盡量提高他們「發現事實的速度」(speed to truth)。

為減少白費工夫的情況,並增加團隊的決策權,實驗在本質上應該是簡短的。如果可能的話,實驗不應超過一週。

若要做到這一點,有時候團隊必須盡量縮減某項功能特性,縮減到測試它最弱假設時絕對需要的那個程度。有時候,這表示團隊沒有編寫程式碼,而是透過研究來完成一項「離線」實驗。

3.團隊所用的方法應以顧客為中心

打造軟體(甚至是內部使用的軟體)的流程,應該完全以顧客為中心。

最起碼應達到以下這些原則:

● 總是以「顧客受到的影響」為核心來架構「挑戰」。

● 解決問題的會議,總是從更新顧客狀況開始進行,而且經常有來自第一線的員工代表參與這些討論。

● 每一項實驗都是根據一個以顧客為中心的假設來建立。如此一來,團隊就可以對實驗預測會出現的結果負責。

但更重要的是,要讓工程師親眼看到顧客如何使用他們的產品。這需要第一線員工和工程師合作,以觀察產品是否造成顧客影響。

4.使用時間箱來聚焦實驗,並避免浪費

有趣的是,順應式軟體開發鼓勵使用時間箱,來確保實驗得到合理的投資,並顯示正在開發的功能特性是否達到可接受的品質水準。另一方面,典型的敏捷法使用者,避免使用時間箱或截止期限,因為擔心截止期限會被用來製造情緒壓力。軟體開發人員最糟糕的感受之一,是花費幾個月處理的工作,最終是無用的。這會讓你感受到情緒壓力(「我讓每個人失望」),以及感受到慣性(「我究竟為什麼要做這件事?」)。

為避免這種結果,你應清楚說明,工程師在工作進行到什麼程度時,就應與你確認一下方向是否仍然正確。團隊建立的假設若是不確定性愈大,風險就愈大,那段該確認的工作也應該愈短。考慮到這一點,時間箱就不算是截止期限,而是一種限制,可以在實際測試之前,指導實驗應採取什麼水準的深度和品質。透過這種方式,時間箱可以提高工程人員總體動機。

5.團隊的組織架構應強調協作

為確保這最終會是一個無交接流程,相關的各方利害關係人,應該像單一的跨職能部門團隊來運作,這種團隊又稱為「群」(pod)。群的目標是推動協作。每個群的成員,應包含提供絕佳產品所需的整組專家,其中可能包括高階主管。例如,有一個組織的產品群包括產品經理、前端工程師、後端工程師、設計師、品質工程師、顧客服務人員代表(部分時間參與),以及控制職能一名資深高階主管。

許多組織中都有「假群」(faux pod)的端倪,假群就是團隊自稱是群,但實際上並沒有像群一樣運作。假群的跡象包括:

● 專家分別隸屬於不同的「協調一致」的團隊,而不是納入同一個團隊。例如,某個產品團隊有一些專門的工程「衝刺週期(sprint)團隊」。這些不是群。

● 團隊使用了防止真正協作的工具。例如,我們詢問一個工程團隊為什麼選擇他們正在使用的敏捷軟體工具,他們說:「這些工具會防止高階主管參與我們的工作。」所有這些都會讓不信任的循環一直持續下去。

● 工程和產品職能部門實際上擁有來自高層的不同目標。這兩個部門的高階主管,都利用自身的階級權力,讓自家部門的員工把部門目標列為優先要務,勝於其他目標,包括他們的群目標。這些衝突,最終導致工作團隊內的衝突,阻礙了真正的團隊合作。

● 嚴格的階級人才流程,例如,績效評等、階級頭銜、升遷壓力,以及「不升遷就走人」的系統,破壞了讓群運作良好所需要的團隊合作。這些系統若不是讓團隊成員感覺對上司的責任,勝於對團隊的顧客的責任,就是會讓團隊成員相互競爭。無論是哪一種情況,他們都不會作為一個團隊來運作。

換句話說,組織各自為政的部門愈強大,人們就愈會為了自己部門的需求而解決問題,而不是為了團隊的需求。如此一來,若沒有持續升高處理層級,就很難進行協作和達成共識。

6.團隊應不斷質疑本身的流程

有個著名的工程設計格言稱為康威定律(Conway's Law)。它指出:任何設計出系統的組織,都會產生一種在結構上反映組織溝通(也就是流程)結構的設計。換句話說,如果你是單一化(monolithic)組織,會產生單一化的設計。如果你根據用戶區隔來規畫組織,你的產品就會針對這種結構進行優化。

如果想打敗康威定律,較好的做法,是不斷調整你的結構和流程,以配合手邊的問題。這麼做所需要的團隊,必須擁有單純、輕簡的流程和結構,而團隊成員不斷質疑和調整這些流程和結構。

因此,工程團隊應養成持續診斷和反覆調整自身團隊運作模式的習慣,而不是把「敏捷法」發展成一種不容許質疑的宗教。在我們看過的最佳範例中,團隊每個月會診斷本身的運作模式,並決定是否需要改變,以產出更好的產品。

敏捷法不是儀式

吸引、激勵和留住數位產品人才的能力,已逐漸成為對組織關係重大的任務。大多數組織已成為一項簡單訊息的犧牲品:把敏捷法當作一系列儀式來實施,一切就會變得更好。可惜,當中若是沒有放進人的因素,就達不到這種效果。回歸「動機」和「順應力績效」的基本要素,你就可以建立一個真正敏捷的組織。

(林麗冠譯自2018年10月1日HBR.org數位版文章)



琳姬.麥奎格 Lindsay McGregor

與人合著《紐約時報》暢銷書《引爆組織動能:》(Primed to Perform: How to Build the Highest Performing Cultures Through the Science of Total Motivation),她是新創公司Vega Factor執行長和共同創辦人,這家公司協助組織改變本身的文化。在此之前,她領導麥肯錫顧問公司(McKinsey & Company)的專案。她擁有哈佛商學院企管碩士學位和普林斯頓大學(Princeton)文學士學位。


尼爾.都西 Neel Doshi

與人合著《紐約時報》暢銷書《引爆組織動能》,他是新創公司Vega Factor的共同創辦人,這家公司協助組織改變本身的文化。在此之前,他是麥肯錫顧問公司的合夥人。他擁有華頓商學院(Wharton)企管碩士學位和麻省理工學院(MIT)理學士學位。


本篇文章主題領導之人員管理