敏捷開發被遺忘的事 – 敏捷管理

.

我們常常說到敏捷轉型要由上往下才會成功,為什麼呢?

.

敏捷開發沒有教主管們如何敏捷起來才是主要原因

敏捷教練們經常用同一套教材在教團隊與主管,但這樣做對嗎?是不是應該教導主管們如何來管理敏捷團隊才對呢?! 其實有關這個問題,在早2005 年時就已經有一群卓越的敏捷人士,發現了這樣的需求,就已經在努力的起草有別於敏捷宣言,專門指向專案管理面的宣言,目的是用來協助主管們跨過敏捷管理的門檻,就稱之為相互依賴宣言(Declaration of Interdependence, DOI),用它來做為進行敏捷管理時的指導原則。你只要在Google搜尋畫面下,輸入”DOI agile” 就能找到下面的結果:

.

do agile

Google 一下:「DOI  Agile」

.

選擇 PM Declaration of Interdependence: 就能看見了,它所強調的是雖然敏捷宣言已有涉及軟體開發,但敏捷專案管理的《相互依賴聲明》則更關注專案的管理領域”

這個協會初期稱為 Agile Project Leadership Network,APLN,後來又更名為 Agile Leadership Network, ALN(把Project 拿掉了),但由於未能引起專案經理人社群的青睐(註1),形成了這個一樣是由一群卓越人士所推廣的運動,卻很少人知道而遲遲沒有發揮應有的效應。也就間接的造成了今天在實行敏捷化時專案經理人遇到問題時經常會有無所適從的局面。這裡就簡單地描述一下它的六大宣言:

.

6 principles

DOI的六大宣言(APLN並沒有提供中文的版本,因此我自行翻譯了一下,歡迎修正)

每句的特色是目標放在前一句,後面的句子則是作法的描述。後面刮號是我加上的主題.

.

起草 DOI 宣言的卓越人士:

David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki worked to see what management principles might be required in order to achieve an Agile Mindset in product and project management, In 2005.

.

我們常常說這是一個 VUCA的時代(註2.),要尋找任何問題的解答,只要隨意的Google一下,獲得的訊息便會多到我們不知道要如何來取捨的情境,要如何來抉擇呢?恐怕只有依靠類似敏捷宣言這類核心原則才足以拿來協助我們過濾這些個龐大的資料訊息,因此許多新的理論就紛紛以原則的方式提供我們做為行動的準則,如著名的敏捷宣言是在2001年所訂下的。

.

宣言.png

2001的敏捷宣言

.

囉說一下:

 

  • 敏捷價值Agile value

敏捷開發注重價值的交付,並不斷詢問有關範圍的不同表現是否值得他們提供的價值的問題,因此才能擁抱變化。上面這二個宣言正是在說明這一點。拿來對應到DOI的第一項原則「我們通過專注的持續產出價值流,來增加投資報酬率。」大家可以參考Ron Jeffries 所撰寫的《軟件開發本質論—追求簡約、體現價值、逐步構建》一書中所提到: 敏捷即是以價值為導向,也說明了為什麼我們要依照價值來排列需求開發的優先順序的原因。(這是一本從頭到尾都在強調如何務實地體現價值的書,淺顯易讀是敏捷主管的必讀手冊) 

.

Ron.png

價值才是我們的開始,才是我們的工作重點。

.

簡單來說,價值就是我們想要的東西”   

–       Ron Jeffries.

.

※    團隊與任務

「如何管理自組織團隊?」是現代的領導者所遭遇到的最大挑戰之一,你經常要面對到的是應該選擇以具體、明確的方式來交付任務呢? 還是要授權團隊但不做具體說明如何來完成它,讓團隊自行去進行任務拆解的方式。這二者的差異,正是所有的Scrum Master 都會要求主管在遇到問題時,也就是所謂的: 主管要盡量的「後退一步」讓團隊透過討論的方式來解決問題,其實就是希望主管能夠,讓團隊多做自組織的抉擇少下指導棋的意思。許多時候主管會有所疑惑,當我退了那麼多步之後又怎能幫的上團隊呢?說來話長,其實這叫作「賦能」,要讓團隊知道你遇到這樣的問題時會怎麼作,當他們碰到時自然會依照你的思維方式去作,也就跟你在現場沒二樣了。當然, 前題是要先做到「授權」, 否則他們也不敢去作。

.

敏捷領導者領導團隊,非敏捷領導團隊則負責管理任務。

Agile leaders lead teams, non-agile ones manage tasks.

– Jim Highsmith

.

如果再將 OKR 的準則融入後(註3),便成了主管授權時的二個原則:

  1. 授權給團隊去完成任務,但不做具體的執行說明。
  2. 為目標設定完成時的驗證關鍵結果,並讓團隊能夠明確知道是否做到了。

.

  • 遵循計劃不如適應變化

傳統的專案經理總是專注於以最小的變化來遵循計劃,而敏捷的領導者則專注於成功地適應那些不可避免的變化。時時選擇以將顧客的價值放在第一位的前提下,自然的將客戶價值視為專案成功的主要目標。正所謂的,當我們曉得為客戶產生價值和質量為目標時,此時的「計劃」本身就成為了實現這些目標的手段,而不是目標本身了。這便是所謂的敏捷了。

.

【 補述 】

敏捷管理 : 主管需要學會行動學習 Action Learning

何謂「行動學習?

行動學習(Action Learning)是一個團隊在解決實際問題中邊做邊學的組織發展技術及流程

– AACTP 美國培訓認証協會

行動學習的目的

行動學習是為了解決管理者和人們所面臨的真實的複雜性挑戰和難題,同時它也是個人發展的源泉。此外,有一點是敏捷變革要成功的基礎,那就是變革成功的前提是: 主管要先行改變自己」,依據不充分授權原則認為,除非我們可以改變自己,否則就不能改變周圍的任何事情。 

– Revans ,2011

.

註1. 未能推廣開來的原由是,未獲得專案經理社群的青睐。

這裡有較詳盡的說明: http://itsadeliverything.com/declaration-of-interdependence

 

註2. VUCA (是這四個字的縮寫,不穩定 Volatility,不確定 Uncertain,複雜 Complex 和 模糊 Ambiguous,霧卡 )

參考: 《原來你才是絆腳石》

VUCA.png

.

註3. 實施 OKR 其實是極端敏捷的,它只有二個規範,就是設定目標,然後再設定如何驗證它,下面這張圖是借自《硝烟中的Scrum 和XP》作者〔瑞典〕Henrik Kniberg在描述各個敏捷方法的規範數時所畫的圖示。

0001

 

 

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s