想導入敏捷式方法,我該怎麼跟老闆溝通?


    有些組織在嘗試導入 Scrum(讀音:「思逛」)敏捷式方法的時候,老是遭遇到一些奇奇怪怪的現象,效益也常常不如當初想像地那般美好,為什麼會這樣呢?

    有人說,那是因為 Scrum 敏捷式方法太過於理想化,太過於不切實際!可是,我們又該如何解釋那些為數眾多的成功案例呢?

    任何的方法或理論之所以會被廣為流傳,就是因為它們大多都是一些領域專家們觀察、整理、歸納許多「最佳實務(Best Practice)」而來的。而這些最佳實務,都是實實在在的施行紀錄,並非憑空捏造出來的。當很多組織都能由此獲益之時,為什麼自己的組織卻無法適應呢?

    天底下沒有不勞而獲的事情,想要成功導入 Scrum 敏捷式方法,絕非僅靠工程師們看看書、Google 一些資料就做得到的。你在網路上找得到的資料,大都是在告訴你它的架構和流程有多麼地簡單,好處有多麼巨大,這些雖然都是不爭的事實。但是,鮮少有人會(或能)告訴你,要成功導入 Scrum 敏捷式方法,其實還需要不少的組織變革管理思維的改變。

    舉個例子來說,沒病的人不會沒事去看醫生(那些為了拿維他命的例外),會去看醫生,通常就是有毛病。組織若是沒有問題,也不會沒事想導入 Scrum 敏捷式方法(看醫生)。既然是要看醫生,醫生可能就會要你做些不舒服的檢查,要你吃些難以入口的藥,這樣你的病才有可能會好轉。如果病人不肯好好地配合,再好的醫生也治不好病人的問題。

    神醫(Scrum 敏捷式方法),是需要病人(組織)的配合(變革),才能夠成為神醫的!

    導入 Scrum 敏捷式方法,就像上述的療程一樣,絕對會有一定程度的痛苦,組織的病灶愈嚴重,感受就該要愈痛!如果組織對療程沒有感受到什麼痛苦,那麼,一定是在導入 Scrum 敏捷式方法的什麼地方出了錯!

    如果組織因為怕痛就偷雞摸狗地做半套(自己減藥量、不按時吃藥),效果肯定不會好(病沒醫好)。然後,組織就很容易會有藉口,怪罪都是這個方法不好(說醫生是庸醫,說處方沒有用)。

    如果只能說兩個導入 Scrum 敏捷式方法的重點,以下就是我的看法。

    高階管理層的支持

    Scrum 敏捷式方法建議讓全功能戰鬥團隊,對產品或服務專案的開發,負起全責。這個小團隊包含產品負責人(Product Owner)、敏捷大師(Scrum Master)、以及實做專案的開發團隊(Development Team)。這就像是一個特戰小組(有指揮官、醫官、通訊兵、戰鬥兵、爆破兵等),小組領到任務目標(專案目標)後,在戰場上就開始以「將在外,君命有所不受」的形式運作了。

    戰鬥小組會依據戰場上瞬息萬變的戰況(市場/客戶的需求變化),自行調整進攻的節奏和做出即時的決策,讓小組以最高昂的戰鬥士氣,用最快的速度,來攻克目標。不僅如此,隊長還必須讓大家都能夠全身而退(不能日夜加班,拖垮士氣和健康)。在這個過程當中,後方的高階將領們不應也不該介入指揮。因為,這些高階將領們不會比現場的戰鬥小組更了解戰況!

    這需要高階將領們對戰鬥小組有極大的信任和授權,還需對小組不斷地提供資訊和火力的支援,鼓舞小組的士氣!這樣才能夠讓小組的戰力極大化,有利於建立輝煌的戰果和濃烈的革命情感!

    擁有這樣能夠生死與共的戰鬥小組團隊,高階將領們才會是戰場上的常勝軍!

    如果組織內的中、高階主管們習慣於威權式的領導,那麼,這很有可能就會是導入 Scrum 敏捷式方法的最大障礙之一!威權式領導未必不好,端看組織所在的產業型態、規模,以及市場競爭態勢而定。許多組織在有遠見的威權式領導之下,其實比民主式的僕人領導更能展現出高績效!

    講到這裡,你是否已經認為,中高階管理層的支持才是成功導入 Scrum 敏捷式方法的唯一關鍵因素呢?其實不然!

    更高強度的個人紀律要求

    我們回過頭來想一想,想在組織中推動 Scrum 敏捷式方法的你和你的團隊,到底憑什麼讓中高階主管們對你和你的團隊放心?進而能授權,甚至是完全放手?

    Scrum 敏捷式方法其實老早就已經考慮到這點了。不是才說過,任何廣為流傳的方法或理論,通常都是業界「最佳管理實務」的歸納嗎?許多 Scrum 敏捷式方法導入失敗的原因,不外乎就是應用者將這些「最佳管理實務」東丟一點、西丟一點,變得殘缺不全,也因此才會讓效益大打折扣!

    Scrum 敏捷式方法建議了以下的作法,說穿了,其實很大一部分的原因,也就是要讓老闆們放心,這樣團隊才會獲得高階主管們更多的支持和更大的授權。
    1. 敏捷團隊所有的成員要在同一個辦公空間之內一起工作,這樣就會有同儕互相監督的壓力(也是高效率溝通的必要作法);
    2. 敏捷團隊每天都要在固定的時間、於固定的地點,開個15分鐘的立會,分享每個人的進度與障礙資訊,這樣不僅是種同儕監督,更是一種高頻率的監督(當然也是互相了解和互相協助的機會);
    3. 敏捷團隊所有的工作細節和進度,都要攤在陽光下,辦公空間牆面上密密麻麻的便利貼、設計圖和進度狀態圖表,任何人一眼就能夠看完專案的全貌,當然,還有每位成員的狀態和績效!這不僅需要所有敏捷團隊成員都具備開放的心胸,還需要具備「能讓他人檢視自己能力」的承受力;
    4. 敏捷團隊定期(衝刺 Sprint)得產出成果,還得在所有的利益相關人面前展示和操做成果,接受大家的建議和砲火(說好聽些叫做「回饋」);
    當然,Scrum 敏捷式方法不僅僅只有這幾點建議而已,但是,光憑這幾點,團隊想混、想摸魚?門兒都沒有!這應該是連窗戶都被封掉了吧(別誤會,我可不是在說導入敏捷是想要好混一點)!


    權力和義務是相對的,敏捷團隊想要有做產品的充分主導權力,充分透明化「團隊所有狀態資訊」就會是敏捷團隊的相對義務!然而,這需要極高的自我紀律要求!如果能試試這樣去跟組織的中、高階主管們溝通,也許就能增加不少導入 Scrum 敏捷式方法的成功機會,大幅增進組織的整體能力!