也許你需要的是多一點瀑布:敏捷的「八不」/黑手阿伊

在引進敏捷方法的初期,我們付出了許多時間、精神、和心力,也面對了許多亂象,直到一兩年後才慢慢步上正軌。回顧過去幾年的敏捷轉型史,如果可以重來,我們也許會改變一些做法;而本文的目的,就是讓你「早知道」,不必再走同樣的坎坷路。

在 2014 年我剛剛開始接觸敏捷(Agile)時,當時我的角色是新加坡商鈦坦科技的總經理,我覺得敏捷(包含敏捷開發敏捷專案敏捷管理)在描繪的是一幅理想中的世界。

就拿敏捷大家族中熱門的Scrum方法舉例來說,在Scrum團隊中沒有主管發號司令,工作由大家一起分工合作完成,也沒有主管指派工作,每個人自行選擇工作事項。團隊成員不會偷懶,會盡力把事情做好,最後的工作成果則是由團隊共享。

至於產品待辦事項是由產品負責人(Product Owner)決定,但如何完成工作是由團隊決定。

簡單的說,就是「各盡所能、各取所需」,這也是共產主義中理想社會的呈現。

各盡所能、各取所需。

──馬克思《哥達綱領批判》

然而,等到真的把頭洗下去,才發現完完全全不是這樣一回事!

團隊沒有主管之後,就陷入了決策困境;在專案進行中,一個小小的決定可以討論個三四天。

少了主管擔任訊息傳遞的角色,團隊的方向和部門、公司總是無法同步;團隊成員各做各的事,站立會議只是好看、過過場。

資深的成員覺得要教資淺的浪費時間,資淺的覺得資深的都不務正業,只做自己喜歡做的事;更別提在這段陣痛期,有些伙伴不習慣新的模式就離開了。

這種種的亂象,直到我們導入敏捷一兩年後,大家掌握了敏捷的精神,才慢慢消失;但也花費了難以想像的時間精神和心力。

回顧過去五年的公司敏捷轉型史,如果一切可以重來,我們也許會改變一些做法,而不會讓過程那麼的曲折。例如:

1. 不是消滅主管,而是要主管做好主管該做的事

鈦坦科技導入敏捷的時候,我們就把團隊的管理職:組長(Team Leader)取消了,這當然要感謝當時擔任組長的伙伴理解和支持,讓我們順利過渡轉型;但其實這是一招險棋,在大部分組織中,也許會遭遇到很大的阻力、和難以承擔的後果。

如果一切可以重來,我們也許並不會取消全部的組長職務,而是讓所有組員都有輪流擔任組長的機會、讓擔任組長的人做主管該做的事情;而有了組長的領導經驗,成員就能夠更理解公司的營運情況,這也是訓練部門級主管接班梯隊的機會。

什麼是主管該做的事?

對齊公司目標和價值觀、發掘人才、爭取資源、幫助團隊內部和跨團隊溝通、協助團隊成員成長、針對組織系統性的問題做出高品質的決策,這些才是主管該做的事。

2. 不是十項全能,而是當團隊需要的時候「我願意」

在剛剛開始導入的時候,我們希望團隊中的成員都可以是全端工程師:前端、後端、測試都包到完成,所以取消了前端工程師、後端工程師、測試工程師等等職稱,一律改稱為產品開發師(Product Developer)。

這樣做的好處,當然是打破了職務的藩籬,但也造成大家認為每個人樣樣都要會、事事都要精的誤解。

如果一切可以重來,我們還是會取消個別的職稱,但會把焦點放在貢獻自己的專長、學習別人的專長上、在需要的時候原因跳下來幫忙,而不是什麼技能都要學。

我們需要的是團隊整體的技能端到端,而不是每個人的技能都端到端。

3. 不是顧客第一,而是緊緊抓住市場變化的脈動

敏捷宣言第三條說到:「與客戶合作,重於合約協商」,強調與客戶協作的重要性,而我們做的是B2B的生意,所以往往客戶說什麼,我們就做什麼;但我們忘記的是,跟客戶協作只是手段,目的是為了讓生產出來的產品貼近市場需求、有價值、賣得出去。

如果一切可以重來,我們會更關注在交付需求後產生的價值,和客戶檢討每個需求的成效,甚至走到市場上面對真實的消費者,而不是只接收客戶轉來的第二手資訊。

顧客不是第一,賺錢活下去才是。

4. 不是一切透明,而是容易取得幫助工作的資訊

在推行透明化的部分,我們做了薪資透明化的嘗試,80%工程師的薪資都是公開的;當然在實踐上會有很多細節,如基層、中層公開,同一職級同一薪資,獎金不公開等等。

而帶來的影響整體而言,我覺得持平,不好不壞;沒有太大的幫助、也沒有什麼太差的反應,但節省了很多主管煩惱薪資和私底下八卦的時間。除了這個,我們還有許多資訊透明化的嘗試。

如果一切可以重來,我們會更注重的資訊的整合,而不只是單純的公開資訊。每個人的時間有限,資訊量太多的結果就是資訊過載,不知道什麼是重點;這也是我認為主管必須做的工作之一:幫助團隊處理資訊的過濾、整理和翻譯。

透明公開是為了讓工作更有效的手段,而不是目的。

5. 不是共識決,而是搜集意見後做出高品質的決定

ZapposMorning Star這些普遍認為高度敏捷、開放的公司,在團隊和部門中還是有做營運決策的角色。

而敏捷式組織的制度如合弄制(Holacracy)和全員參與制(Sociocracy)中,每個團隊也都有一位角色專職做營運面的決策,在合弄制稱為領導鏈(Lead Link),在全員參與制中稱為營運領導(Operational Lead)。

我們在導入敏捷後取消組長職位,然後跟團隊說:「現在開始你們就自己組織、自己做決定」;結果想當然耳就是慘不忍睹,不是花很多時間討論沒有共識,就是沒有人要帶頭做決定,或是出事了就推說「這是團隊決定的」。

如果一切可以重來,我們會先跟團隊介紹認可決(Consent)的概念,在制度上分成治理和營運;治理面(如制定遊戲規則)的事情就使用認可決,而營運面(如同按照規則玩遊戲)的決策,則是由主管(或是組長、領導鏈、營運領導)參考大家意見之後拍板決定。

絕對不要使用共識決,畢竟不是每個人對工作都有相同的投入和風險承受度;所以跟組織的命運越高度相關的人,決策權力應該越大。

就算沒辦法使用認可決,寧可獨裁專制由主管決定,也不要用共識決。

6. 不是反官僚,而是由做事的人設計流程解決問題

我接觸敏捷之後,想像的是一個超扁平、無層級的烏托邦世界。

但回到現實面,當組織長大、人數多了之後,為了整體營運的有效性,需要有抽象的層級出現,來整合和調度資源。越接近顧客的層級,處理的事務越具象;越遠離顧客的層級,處理的事務就越抽象。

如果一切可以重來,我們的重點不會放在如何消滅官僚科層系統,而是放在如何讓科層系統運作得更有效,讓資源更有效的整合、讓資訊可以更暢通,讓第一線的人有更大的權限服務顧客。

官僚系統沒有錯,官僚心態才是錯。

7. 不是花大錢教育訓練,而是在工作中反思和成長

我認為,敏捷轉型就是為了變成學習型組織;而公司也花了很多資源和時間,讓伙伴上課和參加教育訓練,甚至產生了過度學習的症狀:上很多課、看很多書、聽很多分享,但來不及消化和吸收。

如果一切可以重來,我們會更注重在如何解決工作上的問題,著重在日常工作上的學習和成長,而不是只關注在提供教育訓練的機會。

能帶來組織改變的才算真的學習,要不然就是自爽自嗨。

8. 不是心靈成長夏令營,而是學習面對殘酷的現實

在導入敏捷後,發現敏捷非常需要有效的溝通,所以我也參與了一系列的溝通課程,包含焦點討論法ORID人格特質分析DISC教練引導薩提爾等等;其中DISC和ORID的課程也引入公司,成為每年固定開放的基礎內訓課程。

當然,這些對我個人的成長都有很大的幫助;但在商言商,從成本效益來看,除了基礎的溝通課程之外,我並沒有特別感受到「趨近心靈層面的課程」對組織的效益。

更糟糕的是,這會讓大家有「你要重視我的感受」的期待;但這些課程是用來要求自己,並不是拿來要求別人的。

如果一切可以重來,我們會更著重在如何面對衝突、甚至製造健康的衝突,以建立就事論事的文化。

當然並不是說不要重視別人的感受,而是我們在工作上討論事情、看數據,本來就是「白刀子進紅刀子出」血淋淋的現實。表達方法當然可以調整,但現實不會因為我們感受不好就不存在的。

活著才有輸出,活著才有明天,活著才能談心靈成長。

步步血淚的「敏捷八不」

這是從我自身心酸血淚的經驗中體悟的「敏捷八不」,希望能幫助想在組織內導入敏捷的朋友,少跌坑、也少走一些冤枉路:

  1. 不是消滅主管,而是要主管做好主管該做的事;

  2. 不是十項全能,而是當團隊需要的時候我願意;

  3. 不是顧客第一,而是緊緊抓住市場變化的脈動;

  4. 不是一切透明,而是容易取得幫助工作的資訊;

  5. 不是共識決,而是搜集意見後做出高品質的決定;

  6. 不是反官僚,而是由做事的人設計流程解決問題;

  7. 不是花大錢教育訓練,而是在工作中反思和成長;

  8. 不是心靈成長夏令營,而是學習面對殘酷的現實。

本文改編自作者於2021年7月出版的《敏捷管理生存指南:不是快,而是適者生存》一書。

發源於矽谷的敏捷式開發,在軟體產業如 Google、Facebook 臉書實證成功後,敏捷管理也開始影響各個不同的產業。

透過書中的實例和做法,無論老闆、主管或員工,科技業、服務業、傳產、學界或政府,都能運用敏捷讓自身工作更順心,團隊合作更順暢,企業成長更順利。

A guest post by