首頁 敏捷
如何判斷Agile Bullshit,你能怎麼應對解決?
2021/10/1 作家:彭奕婷, PMP
268
作者/彭奕婷, PMP

Sybil任職某科技公司產品經理,平日使用C工具管理團隊的任務。最近公司新進一位技術主管Rick,恰巧曾販售該工具,又由於他非常喜歡敏捷,所以時常與人談論敏捷與C工具的用法。今天Rick找上Sybil詢問某些技術團隊的近況:

Rick問:「我覺得你帶領的A、B團隊的產品研發動作太慢了,不太敏捷。」

Sybil回答:「怎麼說呢?依照我的觀察,兩團隊還在磨合中,難免會慢一點,我們可先觀察一陣子。」

Rick接著說:「因為我看C工具上有張任務過大,應拆單卻未拆,而另一張則是動工了,但卻未改變任務狀態,這如何知道進度?我懷疑如何敏捷?」

Sybil回應:「這張大任務單曾多次引導要Break down成多個小任務,但由於團隊平常溝通緊密,也已有一套運作方式,所以經由討論後,決定用那張任務來處理;至於沒改狀態的任務,我也曾困擾,但與團隊討論後,得出的共識是『直接與團隊詢問來了解狀況』。」

Rick挑眉接著問:「另外,我看到某任務的規格很精簡,不該由PM寫出詳細的系統規格,再由團隊研發嗎?」

Sybil確認完該任務的內容後,回應:「這方式是與團隊討論出的對我們客戶最適合的方式,我們透過頻繁溝通,來確定內容和方向,只寫最必要的規則,其他時間均花在研發和討論上。」

何謂敏捷BS(Agile Bullshit)?
看完上述故事,你覺得熟悉嗎?先別下定論,我們先來了解敏捷BS(Agile Bullshit)的定義。關於敏捷BS ,目前尚未有專門解釋的定義,但通常用來指稱「非正確、非真實的敏捷行為、言詞、思想和心態」,簡而言之,可認為是「錯誤的敏捷觀念與行為」。談到敏捷觀念的正確與否,最基本且最容易用於判斷的根據,來自敏捷的原始核心思想「Agile Manifesto」。

Agile Manifesto做為創始敏捷的起源,在其四項價值和十二項原則內,清楚明瞭地重複強調:「敏捷重視透過團隊與客戶(目標使用者)的合作,因應各種即時變化,做出相對應的調整,並配合減少不必要的浪費,有效率且頻繁地交付最大價值。」以此觀念延伸,即可得知敏捷BS是「違反Agile Manifesto的事項」。開頭故事的Rick強調口頭敏捷、重視流程與工具使用、希望以嚴謹紀律與繁複的規則文件來交付成果,這與敏捷核心思想有相當程度的出入,即是敏捷BS的簡易範本。

五項判斷標準來面對快速變化的作戰環境
更深入探討下,可首先採用專門面對快速變化的作戰環境,以提供美國政府有效可行建議方案的美國國防創新委員會(Defense Innovation Board,簡稱DIB)提出的五項判斷標準,來協助辨識不屬於敏捷的事物:開發團隊中沒人談論或觀察真實使用者(實際使用者,非組織內部使用者);沒有持續來自真實使用者的回饋;符合需求規劃,比做出對真實使用者有用的產品來的更重要;與產品開發的所有利害關係人(如:開發團隊、測試、真實使用者……等)只存在或多或少有自治(非完全自治);在有足以實現DevSecOps(視軟體安全為交付產品的核心的概念)的環境下,仍缺乏DevSecOps的觀念

至於成功判別出非敏捷的下一步,該如何確定為敏捷BS?DIB從組織、管理與團隊提出6項決策基準:

1. 每次迭代,團隊都能對真實使用者交付可行的成品並取得回饋?
2. 組織備有描寫產品戰略目標的文件?且團隊成員都知道如何發揮貢獻?
3. 使用者回饋能在一個月內成為團隊具體工作內容?
4. 組織具備敏捷能力?(原文:專案整體生態系統是否都能敏捷?)
5. 團隊能根據使用者回饋來調整需求?
6. 團隊能照他們所學(所經歷的事物),去調整相關工作流程?

若在審視自身組織、管理與團隊時,發現上述任一項答案為「否」時,就會落入敏捷BS的解決範圍。

而當面對敏捷BS時,該如何有效解決呢?
經驗法則告訴我們最好與最佳的解法,即為踏實的「逐項應對」:
1. 當發現團隊無法在每次迭代中,針對真實使用者交付可行的產品與蒐集回饋時,就需對團隊明確說明問題,促使團隊藉由有效溝通,產生後續調整的共識,並同時增加對使用者的認識、朝著對期望的方向前進。其中需特別注意團隊是否「有能力」交付可行的產品,其原因為交付產品的「可行」與否牽涉到多面向,如:
● 交付前,是否清楚了解誰是真實使用者?(以便交付「對」的產品)
● 交付前,是否能有效率的測試?(能以最小力氣創造最佳價值)
● 產品的交付品質是否良好?(功能正常且能順暢使用)
● 交付週期是否能滿足真實使用者?(不讓使用者等太久)
● 交付後,是否能與真實使用者良好溝通?(以取得後續持續的回饋)
2. 當發現組織內缺少團隊任務的戰略目標時,就需準備這份文件,並明確清楚的撰寫,且陳放在團隊能隨時觸及的地方,可配合頻繁、有意無意的溝通,讓團隊在潛移默化中體認了解共同目標,並運用各種機會,時常刺激團隊思考創造有意義貢獻的方法。
3. 當發現組織整體生態無法敏捷時,則需先審視組織或專案敏捷的必要性註1,若評估後發覺確實有其必要,則可透過各種影響力來促使組織落實或轉型敏捷。特別提醒此時需留意:
● 組織是否能承擔落實或轉型敏捷的風險?(敏捷需要長時間培養,組織是否具備足夠的資源來等待敏捷落地)
● 組織需交付的產品是否適合採用敏捷?(並非所有產品均適合敏捷)
● 組織內是否有其他不容忽視的力量阻止敏捷產生?(掌握利害關係人的溝通,能有效幫助敏捷落地)
4. 當發現團隊無法被賦權於調整需求時,則需考量以下幾點,再依照團隊狀況,逐步調整授權的幅度,直到能完全授權:
● 管理者是否接受下放權力?
● 團隊的敏捷成熟度是否足夠?
● 團隊對使用者的了解程度是否夠深入?
5. 當發現團隊無法被賦權於調整流程時,除了同樣需考量團隊的敏捷成熟度外,更要反思團隊合作的密切程度,以便有效率的逐步開放團隊自主調整流程,經由不斷反思與調整的過程,透過團隊合作,讓彼此運作的流程更順暢與有效率。

保持客觀判斷與理性思考,做出正確判斷
加拿大裔的美國心理學家Paul Bloom研究發現人類會因為經驗、個人認知能力等,對事物產生偏好,此時容易被主觀因素引導而產生偏見。當敏捷盛行於世、廣受喜愛時,無法否認的,甚至於偏見也並存其中。客觀判斷與理性思考,是人們做出正確判斷的主要利器之一,如何在面對敏捷BS時能理性思考、客觀評價,保持敏捷核心思想,是身為敏捷人所應理解與實際運用的事。

綠專案X運作X成功關鍵

本期採訪到與人們生活息息相關的綠色產業及近期具代表性的綠色專案,如:綠色餐飲指南Green Dining Guide(GDG)201...
綠專案X運作X成功關鍵
彭奕婷, PMP
Kaitlyn Peng(KK) 有逾8年產品管理經驗(Agile經驗逾5年),擅長商業策略、數據分析、使用者經驗……等,目前有近10張管理相關國際證照,且現任台灣第一個Product Owner社群社長(AG7_PO社群),以及為KKtalks.tw(職場雜談)的創辦人。
您可能也喜歡這些文章