敏捷宣言第四條:持續學習

我認爲敏捷式管理的最終目的就是建立學習型組織,除了在 Scrum 的活動外,我們還可以經由結對編程,也就是兩個人同時一起處理一件事情,來讓彼此在工作中學習各自的專長。另外企業内外各種技術與學習的分享,比如建立企業中的實踐社區(Community of Practice,簡稱COP),參與產業中的社區活動,都是讓企業保持學習文化的具體方法。

『這個採購案不能進行,因爲去年預算沒有編列。』

聼到類似這種説明因爲去年沒有計劃到,所以今年不能做的説辭,我都會想這個計劃到底是幫助公司,還是限制了公司的成長。

敏捷宣言第四條中說到:回應變化 重於 遵循計劃。

這句話聽起來很簡單,就是如果現實環境改變了,我們應該要更改原本的計劃去適應新的情況,而不是一廂情願的按照原定計劃往下走。但我認爲是最難做的的一條,因爲不管是人還是組織都是由慣性的,人們會習慣跟著過去的計劃往下走,直到走不下去爲止。

在敏捷的各種方法論中,Scrum 是最專注在工作模式上的,所以 Scrum 中的各種活動,都是專注在檢視現狀,然後做出相對應的調整。

在 Scrum 短衝中,每日站會、回顧會議(Review meeting)、與自省會議(Retrospective meeting),都是爲了讓團隊慢下來,停止工作,看看目前的情況是否符合預期,只是檢視和調整的目標對象不同。

在每日站會中,團隊成員檢視的是在短衝中每天的工作情況,比如說工作進度是否有遇到阻礙,團隊成員是否有需要協助的地方,然後團隊成員進行協助或是尋求其他人的協助。

每個短衝結束前回顧會議的重點在於產品本身,藉由邀請利害關係人一同來看看這個短衝所做的成果,是否符合他們的預期,有沒有功能需要修改,或是其他可以讓產品更好的點子。除了這個短衝的成品,過去產品的功能績效也應該被追蹤與討論。產品負責人在會議上搜集這些反饋後,會在產品待辦清單上反應出來,比如新增、修改、或是刪除使用者故事。換句話説,有效的回顧會議應有的影響,就是讓產品代辦清單是活的,代表經常性的變動。如果產品代辦清單上的事項長期沒有改變優先級或是内容,這是一個需要注意的警訊,代表我們可能沒有取得反饋,或反饋沒有被接納並反應出來。

自省會議我認爲是 Scrum 的精華所在,也是讓團隊工作效能提升最重要的會議。在自省會議中團隊檢視的是該短衝中的工作情況,然後決定下個短衝中所需要改善的事情。自省會議最重要,也是最難開好的會議,如果處理的不好會流於形式,大家閑聊一會就散會了。所以在實務上,Scrum Master 需要找各種方法讓團隊願意坦誠面對問題、説出建設性的建議、并且還要保持新鮮感,真的是很有挑戰。自省會議中常見的方法包含時間軸回顧、+ – = (多做、少做、維持)、肯定與感謝、慶祝等等,在 Google 上搜尋 Retrospective games 也可以找到許多自省會議的點子。自省會議中最重要的產出是改善事項,即使只有一件再小的事情都好,只要我們每個短衝都比上一個跟好一點,經過一年團隊就會脫胎換骨了。

在原來你才是絆脚石一書中提到,敏捷宣言第四條:回應變化 重於 遵循計劃,背後的價值觀是持續學習,就如同上文在 Scrum 中的活動,都是觀察現況、做出改變、檢視成效的不斷循環,這就反應到團隊的能力是在持續提升的。

我認爲敏捷式管理的最終目的就是建立學習型組織,除了在 Scrum 的活動外,我們還可以經由結對編程,也就是兩個人同時一起處理一件事情,來讓彼此在工作中學習各自的專長。另外企業内外各種技術與學習的分享,比如建立企業中的實踐社區(Community of Practice,簡稱COP),參與產業中的社區活動,都是讓企業保持學習文化的具體方法。

敏捷宣言第二條:透明化

在『在原來你才是絆脚石』中提到,敏捷宣言中第二條:可用的軟體 重於 詳盡的文件,背後代表的價值觀是透明性。對顧客和利害關係人來說,透明性就是在每個迭代都看到團隊做好的產品,然後給意見。如果我們做的符合顧客需求,那很棒我們可以繼續做其他需求。萬一做的不是顧客要的,那我們最多也是損失一個短衝的時間,而不會像傳統的開發方法,都花了好幾個月的時間開發,顧客一句話就被打掉重練。

敏捷宣言第二條提到:可用的軟體 重於 詳盡的文件,為什麽要特別把文件與軟體做比較呢?

我認爲這一條的背景是在傳統的軟體開發模式中,因爲比較像流水綫形式的分工,比如專案經理跟客戶訪談拿需求,專案經理訪談後要整理需求並撰寫需求文件,然後把需求文件交給軟體開發單位的主管,開發單位的主管再依據需求寫出技術設計文件,最後把技術開發文件交給開發人員進行程式開發,而這邊還沒有提到與其他單位所需要的文件,比如說給品質保證部門的測試案例,或是之後程式上綫前的發佈文件。

如果你能充滿耐心的看完上面的流程,就會發現依照傳統的瀑布式開發流程,在開始寫軟體之前,就會需要寫出一堆文件。而且在之後任何的需求變更或設計變更,都需要把文件更新,萬一沒有更新到,後續接手的人就會像是看天書一般,有看沒有懂。而在軟體業界混久的人,都會知道開發文件的作用不大,這主要有三個原因。

第一個原因是軟體專案時程都很急迫,在壓縮專案時程的同時,第一個被放棄掉的都是寫文件,然後把時間留給寫軟體。反正寫文件是爲了讓之後接手的人看懂,現在我顧自己都來不及了,哪有時間考慮未來的事情呢。好一點的就是寫個大概,差一點的就直接把以前的文件複製貼上,當作文件完成了。

第二個原因是軟體是相對抽象的概念,不像是蓋大樓,把藍圖畫好後看圖的人可以視覺化的看到完成的具體形狀。所以顧客只能大略的描述他想象中的情況,也許可以加上圖示 Mock up 幫助顧客想象使用的流程,但許多問題還是在實際使用的時候才會被發現。所以當專案經理在寫需求文件的時候,也沒辦法照顧到太多細節。

最後一個原因也是最根本的原因,更新軟體太容易了,改一行程式碼,也許就需要更新到好幾份文件。更新軟體的速度遠遠快過更新文件的速度,工程師就會想那我等更新程式碼多幾次後再來更新文件,省的麻煩,最後連更新文件都省了。造成很多的文件不如説是歷史記錄。

因爲以上的這些原因,在敏捷開發中提倡的做法是讓程式碼本身就是文件(Code as documentation),就是讓後續接手的人,可以光從程式碼與測試案例就知道大部分的資訊,並可以開始維護與更新程式碼。當然這是個理想中的狀態,所以宣言中説的是『詳盡的文件』而不是說『文件』。能被及時更新的關鍵文件,還是有需要的。

而爲什麽說『可用的軟體』而不直接說『軟體』呢?在傳統專案管理中,客戶大都是接近結案的時候才會看到產品的狀況,而如上面所說的軟體是個抽象的概念,客戶期待的都會跟實際做出來的差很多,然後團隊就會進入不斷修改需求的無間地獄。

俗話說:醜媳婦總得要見公婆。

所以敏捷開發中認爲與其早晚都要見公婆,不然早一點見,讓公婆給些意見和反饋,好讓我們可以儘快改善讓以後的生活更幸福。

在『在原來你才是絆脚石』中提到,敏捷宣言中第二條:可用的軟體 重於 詳盡的文件,背後代表的價值觀是透明性。對顧客和利害關係人來說,透明性就是在每個迭代都看到團隊做好的產品,然後給意見。如果我們做的符合顧客需求,那很棒我們可以繼續做其他需求。萬一做的不是顧客要的,那我們最多也是損失一個短衝的時間,而不會像傳統的開發方法,都花了好幾個月的時間開發,顧客一句話就被打掉重練。

而透明化這個價值觀的體現,在 Scrum 中則是團隊成員都彼此互相理解工作的情況。在企業中的透明化則包含對流程和制度的透明化,和可以方便地取得完成工作所需要的文件。比方説知道什麽職務可以決定交際預算的使用,或是產品的營運狀況如使用人數等等資訊。

透明化的目的是爲了讓大家工作更順暢,所以過度透明會造成資訊爆炸,比如過度會議,反而使得工作的效益降低,所以透明化拿捏要以工作為核心出發,而不是所有事情或資訊都要透明化。

看歷史學敏捷 – 從人性出發

【一千年前的敏捷宣言】

很久很久以前,唐太宗李世民放了三百多個死刑犯回家,說明年秋天時回來報到再殺他們頭。到第二年時,没想到神奇的事情發生了,死刑犯竟然一個没少的回來送死。

在那個時代,没有半個人在路上病死、老死、或被野獸吃掉,真的是老天保佑。唐太宗龍心大悦,認為在自己用心良苦的教化下,連死刑犯都變好人講信用,就把三百多個犯人都大赦放生,傳為千古佳話。

直到宋朝反骨的歐陽修把這事件批評說這是從上到下串通演出的撒狗血劇情(上下交相賊),從一開始就劇透了。皇帝要聖名,放走了就算不回來也没損失。萬一真的有人跑了,長眼的官員也知道要抓幾個替死鬼充數。囚犯也不是白痴,知道皇帝要耍仁慈,回來的一定不會死,打個折大不了去邊彊種菜。

歐陽修在《縱囚論》說:『不可爲常者,其聖人之法乎?是以堯、舜、三王之治,必本於人情,不立異以爲高,不逆情以幹譽。』

超譯:『有智慧的人不會笨到去設計不能普遍適用的規定。規定要從人性出發,不是跟大家不一樣就是厲害,也不要挑戰人性來刷版面。』

簡單的說,就是敏捷宣言第一條所說的:

【個人與互動 重於 流程與工具】

只要是有權限可以制定規定的主管,都應該好好思索這句話。

 

圖片來源:https://memesuper.com/categories/view/37ee3d0030e724c6a90cd001224b8d7fa07d1569/human-nature-meme.html

Agile Tour Taichung 2017『空手、緊握、到放手 – 敏捷路上學到的5件事』台中敏捷旅程分享心得

收到 Max Lai 關於敏捷旅程台中的 Keynote 分享邀請時,我真的蠻高興的。第一因為出生於台中,對台中總是有一份特殊的情感。第二是分享的主題是組織轉型,剛剛好跟十月在新加坡敏捷年會分享的主軸相同,只要英翻中就好,順便一魚多吃

根據我在新加坡年會的經驗,原本預計講個40分鐘,但30分鐘就說完了,幸好因為談的是大家都會有的痛點和共同經歷,所以發問很熱烈,十多個提問把時間完美的佔到45分準時結束,大家都以為我是故意留很多時間提問的XD。比預期時間快的原因是上臺後的緊張語速加快,而且每次準備的故事都會東漏西漏,時間一定會快一些。而台中的分享時間是一個小時,讓我有點傷腦筋,要如何補足剩下的20分鐘又可以彌補我口條不好的缺點呢。 閱讀全文〈Agile Tour Taichung 2017『空手、緊握、到放手 – 敏捷路上學到的5件事』台中敏捷旅程分享心得〉

找出組織無法變敏捷的阻礙 – 團隊共創法實做

14441077_10154328911255751_5785789802293353355_n當敏捷遇上引導的談話發生後,David, Abraham 和 Vicky 就進入了籌備模式,花了不少時間研究如何設計流程,才能讓參與的夥伴可以在表訂時間2.5個小時內得出共識。

當場 Vicky 的引導創造了讓大家安全說話的環境,我自己感覺到大家發言到欲罷不能,如沒有受限於時間因素,命名出來的群組名字有機會更直指核心。由於參加的夥伴來自個個不同組織,有開發團隊、ScrumMaster、Product Owner、主管等等角色,產出的結果應該蠻有代表性。

結論是推行敏捷會遇到以下的阻礙:

1. 現在好好的幹嘛改變
2. 團隊不知道如何建立信任
3. 對敏捷的導入沒有共識
4. (主管/ScrumMaster) 的引導技巧不夠
5. 團隊溝通不夠有效
6. 高層的信任和支持不夠
7. 傳統的績效管理不適用
8. 不知道如何用 Agile 處理(範圍時程)硬梆梆的專案
9. 工程和領域的技能不夠
10. (因資源有限)角色重疊混淆
11. (不知道如何)讓member 感受到結果的價值
12. 缺乏跨界交流的機會 閱讀全文〈找出組織無法變敏捷的阻礙 – 團隊共創法實做〉

敏捷X引導 – 讓Scrum團隊自組織的具體方法

在開始時跑 Scrum 時就自己腦補,所謂引導就是『引誘+誤導』團隊乖乖按照自己的既定方向走 XD。所以去讀了些心理暗示與影響力的書,在會議前先設想期待的結果,設下陷阱讓團隊講出自己的答案。

大多數時候過程都可以按照自己的劇本發生,而當自己預期的答案沒有出來時,就用誘導式問題(Leading Questions)讓團隊就範,讓自己的答案從團隊成員的嘴巴中說出來。如果爭議太大的議題,就先埋好暗樁,適時的跳出來帶一下風向。

(English version published on T.8ytes 英文版發表於 T.8ytes)

在我2014年剛剛開始接觸 Scrum 的時候,覺得 ScrumMaster 是個神一般的存在,不但要幫助團隊了解 Scrum 架構與敏捷精神、支持團隊提升技術能力 、教導團隊如何自組織、移除團隊成長的障礙、協助 Product Owner 產出價值最大的化的 Product Backlog、解決組織中影響團隊運行的阻礙,更扯的是他跟團隊是平行單位,完全沒有叫人做事的權力,乾脆找超人還比較容易 XD

以上職責要一個人全部做到非常挑戰,但一個個分開個別來看,至少都還看得懂要做些什麼。但其中最令我困惑的是提到 ScrumMaster 要引導團隊的部分,而且還特別強調這部分的重要性,但引導(Facilitate)到底是什麼意思呢? 閱讀全文〈敏捷X引導 – 讓Scrum團隊自組織的具體方法〉

自我管理就是我說了算? – 談自組織的不同階段

敏捷宣言的原則中有提到『最佳的架構、需求與設計皆來自於能自我組織的團隊。』所以自我組織(Self-Organizing),或簡稱自組織,在敏捷開放中是個常被提到的關鍵字。

可惜 Scrum Guide上也沒有針對自組織定義,只好參考維基百科對自組織的解釋是:

自我組織,也稱自組織,是一系統內部組織化的過程,通常是一開放系統,在沒有外部來源引導或管理之下會自行增加其複雜性。 自組織是從最初的無序系統中各部分之間的局部相互作用,產生某種全局有序或協調的形式的一種過程。這種過程是自發產生的,它不由任何中介或系統內部或外部的子系統所主導或控制。

參考以上,在敏捷式管理中,我對自組織的解讀是:為了達到群體的目標(以服務或產品的形式提供顧客價值),由每個團隊內部或個人發動,所產生的協調和行動。
閱讀全文〈自我管理就是我說了算? – 談自組織的不同階段〉

工作沒人想做怎麼辦? – Scrum中的工作分派與分工

 

在傳統的專案開發中,都有一個角色負責分配工作,常常是由PM(專案經理)或是Team Lead(組長)來擔任。分配工作這回事非常吃力不討好,既要了解每件工作的急迫性和複雜度,還要考量每個人的能力,平衡每個人的工作量。

這角色常常會成為團隊的瓶頸,因為每件事情都要經過他來分析、排程、驗收、忙著開會,常發生團隊成員空等他來分派工作。更別提如果工作項目比既定時程提早做完、或延遲完成所需要的協調工作。這也是最容易被上下壓力夾殺,很快Burnout陣亡的苦主。

敏捷開發Scrum如何解決這個角色的問題呢? 閱讀全文〈工作沒人想做怎麼辦? – Scrum中的工作分派與分工〉

敏捷界的禁語 – 敏捷組織中需要管理者嗎?

img_1359-e1410852924599

有一則叫【看蜜蜂】的笑話是這樣嘲笑管理的:

話說很久很久以前,有個養蜂人養了一群蜜蜂,每幾天就採些蜂蜜來賣,日子過的也還算輕鬆愜意。

有一天,不幸有個管理顧問經過,他看了看蜜蜂飛來飛去,轉頭就問養蜂人:
『你怎麼知道蜜蜂都有在努力工作,沒有偷懶呢?』

養蜂人傻住了,回答:
「我沒有想過這個問題,」養蜂人有點心虛
「那要怎麼知道蜜蜂有努力工作呢?」

『這還不簡單,』管理顧問自信滿滿得說到
『你就請一個人來看蜜蜂,由他來管理蜜蜂,蜜蜂就不敢偷懶了。我們在企業都是這麼做的,非常有效,有個專門的職稱叫 Team Lead 組長。』

「說得有道理,」養蜂人低頭沉思了一會
「那如果看蜜蜂的人偷懶,我要怎麼辦?」

『沒想到你還蠻有管理的 Sense 的嘛!』管理顧問用充滿激賞的眼神看著養蜂人
『你就再請一個人,看著“看蜜蜂的人”有沒有專心看蜜蜂啊。這工作也有個專有名詞,叫做經理,英文叫做 Manager。』

「這樣就夠了嗎?」養蜂人露出恍然大悟的表情 閱讀全文〈敏捷界的禁語 – 敏捷組織中需要管理者嗎?〉

今天拜飛機了沒? – 談敏捷開發中的貨物崇拜

18ybvedkdg508jpg

如果世世代代都住在一個被大洋環繞的小島上的村落,靠著採集和捕魚為生,村子中最先進的科技是獨木舟,當有天突然看到飛機飛過頭頂時,心裏的OS是什麼呢?

在二次世界大戰時,美日兩國為了爭奪太平洋的制海權和制空權,紛紛在汪汪大洋中、既偏遠又與世隔絕的島嶼駐軍。當軍隊開到時,島上的村民眼看著海上的超級大箱子(軍艦)靠岸,大鳥(飛機)從從頭頂飛嘯而過,還有神仙(士兵)從大箱子和大鳥走出來,下巴都掉到合不起來。

如果換成我的話一定覺得神仙降臨來處罰世人,世界末日要到了!幸好這群神仙不但沒有處罰世人,還賞了不少寶物給村民,如生病時吃了就痊癒的仙丹、會變出食物的盒子等等。當世界大戰打的如火如荼時,這是村民世代以來過的最好的日子,根本就是身在天堂啊。 閱讀全文〈今天拜飛機了沒? – 談敏捷開發中的貨物崇拜〉