跨職能團隊是否真的有效?- 『原來你才是絆腳石』書摘

在傳統組織中跨功能的團隊通常在危機時才會出現,他們會組建了一個瞭解危機的特別工作小組,並由小組成員全權負責解決該問題。

敏捷開發或 Scrum 中,我們常常強調團隊是要跨功能的成員組成。在傳統的企業,會按照功能來分部門或團隊,團隊成員的技能相對單一,像是QA部門與開發部門獨立分開。

而在敏捷式的組織,強調的是希望一個團隊可以自行從頭到尾交付給顧客價值(提供產品或服務),減少跨團隊溝通造成的延遲或資訊落差,所以成員的組成需要跨職能。

有一個蠻好的具象化比喻是不丹的傳說故事,和諧四友:大象、猴子、兔子和小鳥組成的團隊

雖然大象又巨大又強壯,還是需要敏捷的猴子才能摘下果實。但如果當初小鳥沒有吃下種子,讓種子跟著排泄到土壤中,就不會有樹的出現。而如果沒有兔子在土中挖洞,讓土壤通氣與保留水分,樹也不會長的又高又好。

以下是在『原來你才是絆腳石:企業敏捷轉型失敗都是因為領導者,你做對了嗎?』一書中,可以用來探索『跨功能團隊是否真的有效』的一個實驗。


探索12:跨功能團隊是否真的有效?

背景:在傳統組織中跨功能的團隊通常在危機時才會出現,他們會組建了一個瞭解危機的特別工作小組,並由小組成員全權負責解決該問題。 繼續閱讀 “跨職能團隊是否真的有效?- 『原來你才是絆腳石』書摘”

團隊自省是否能提高顧客滿意度?- 『原來你才是絆腳石』書摘

在某些情況下,工作可能是以「個案」為主(例如零售商店,醫生診所或諮詢櫃檯)而不是專注於專案,因此沒有明確的開始與結束時間,也就沒有工作節奏。因此,定期反思和學習就有些強人所難,且太過死板,員工很容易會有「我們在浪費時間」或「在你們這些蛋頭顧問後,我們決不會做這些蠢事」之類的想法。

敏捷開發或 Scrum 中強調的是持續改善,而持續改善的發生主要是靠團隊的反思或自省。

這一篇哈佛商業評論『再討厭,也要安排自省時間』也提到自省的重要性。Scrum 中甚至規定團隊在每個短衝結束時,要舉辦自省會議(Retrospective)以找出在下個短衝可以改善的工作流程。

但自省會議所花的時間真的值得嗎?要如何衡量它所帶來的效應呢?

以下是在『原來你才是絆腳石:企業敏捷轉型失敗都是因為領導者,你做對了嗎?』一書中,可以用來探索『團隊自省是否能提高顧客滿意度』的一個實驗。


探索22:團隊在規律的節奏中學習和反思,是否能提高顧客滿意度?

背景:在使用敏捷開發的軟體部門,定期舉辦自省會議是很常見的做法。在自省會議中,團隊成員會討論在過去兩三周內,他們從已交付軟體所獲得的成果學到了什麼。他們也從彼此間、與公司其他部門、或與顧客的互動中學習。根據筆者自己的觀察,從事其他工作的部門很少採取這種做法。

在某些情況下,工作可能是以「個案」為主(例如零售商店,醫生診所或諮詢櫃檯)而不是專注於專案,因此沒有明確的開始與結束時間,也就沒有工作節奏。因此,定期反思和學習就有些強人所難,且太過死板,員工很容易會有「我們在浪費時間」或「在你們這些蛋頭顧問後,我們決不會做這些蠢事」之類的想法。 繼續閱讀 “團隊自省是否能提高顧客滿意度?- 『原來你才是絆腳石』書摘”

信任是否可以幫助降低企業成本?- 『原來你才是絆腳石』書摘

差旅費用的申報耗人心神,也傳送出矛盾和另人不舒服的訊息:「雖然我們相信你可以做出許多重要的決定,但我們也認為你可能會欺騙我們。」收到這種訊息令人灰心,而且這樣的流程比起可能節省的成本,花費了更多的金錢和時間來防弊。

人性本善?還是人性本惡?

這個是永遠討論不完的問題,而這觀點也會影響企業中的政策和規定。

與其空口討論,不如直接來做個實驗吧!

以下是在『原來你才是絆腳石:企業敏捷轉型失敗都是因為領導者,你做對了嗎?』一書中,可以用來探索『是否可以利用信任來減少成本』的實驗。


探索2: 信任是否可以減少成本?

背景:另一個過度官僚例子是複雜的差旅費用管控,這個管控是假設員工會企圖欺瞞公司,所以就規定只能住哪類型的旅館,只能吃多少錢的食物等等。 繼續閱讀 “信任是否可以幫助降低企業成本?- 『原來你才是絆腳石』書摘”

原來你才是絆腳石 – 一本給變革領導者的企業敏捷轉型指南

在一年前審閱英文原版時我心中是非常激動的,邊看邊想:『如果能早幾年看到,就可以少走好多冤枉路』。要是本書能翻成中文版,對華文世界的企業一定大有幫助,因為敏捷只是心法,而本書就是補足理論和實踐之間差異的那片拼圖!

從 2014 年在公司內開始導入 Scrum 和敏捷Agile,然後接下來在組織面的種種演變,如建立跨功能的團隊裁撤QA部門、推動自省會議的發生、在團隊中不設組長、薪資公開化、推行團隊自組織、推動雙連結等等,我們的敏捷轉型可以說是摸著石頭過河。一方面是因為大部分的資料都是針對 Scrum 在開發團隊中的應用,偏向技術面或產品面,談企業組織面的資料很少。二來敏捷式組織也是相對新的概念,別說中文了,連英文的資訊都非常有限。

所以在一年前有幸被邀請審閱 Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on Disruption 一書,在閱讀時我心中是非常激動的,邊看我就邊想:『如果能早幾年看到,就可以少走好多冤枉路』。要是本書能翻成中文版,對華文世界的企業一定大有幫助,因為敏捷只是心法,而本書就是補足理論和實踐之間差異的那片拼圖!

而我的心願終於實現了!!!

『原來你才是絆腳石』一書已經在天瓏網路書店博客來讀冊生活新絲路和各大實體書店與大家見面!

9789864343140_bc1

繼續閱讀 “原來你才是絆腳石 – 一本給變革領導者的企業敏捷轉型指南”

團隊決定的跟我想的不一樣!- 談參與式決策的技巧

在敏捷組織中,參與式決策被大量的使用,因為現在的環境變動太快,有成員的買單和真心認同,在執行時決策的意圖才能被真正落實。參與式決策的重點,在於讓大家覺得自己的觀點和想法都有被聽到,所以流程的設計是一門學問。

最近看到一則議題是總統擔任主席時,不認同投票表決的結果要求重新表決。

先聲明非關政治,我也沒有研究此會議的流程所以沒辦法判斷對錯。但這是很好的案例,來探討一個所有主管都會遇到的問題:『團隊決定的和我想要的不一樣怎麼辦?』

繼續閱讀 “團隊決定的跟我想的不一樣!- 談參與式決策的技巧”

薩提爾成長工作坊參與心得(Satir Growth Workshop)

薩提爾理論的核心在於把日常生活中複雜的互動,簡化成三個面向:自我、他人、和情境(Self, Others, and Context)。然後依照對這三個面向的考量多寡,分成了五種應對的姿態。分別是討好、指責、超理智、打岔和一致。

「問題本身不是問題;如何應對才是問題。」
維琴尼亞‧薩提爾

“Problem is not the problem; coping is the problem.”
Virginia Satir

第一次接觸到薩提爾的概念是 2014 年開始導入敏捷,Odd-e 的 Stanly 推薦了溫伯格的軟體管理學這一套書籍中,第三冊提到的關照全局的管理作為(Congruent Action)。原本我想的是軟體管理跟心理學有什麼關係,後來慢慢接觸多了,也去參加溫伯格的問題解決領導者工作坊(Problem Solving Leadership),才了解到溫伯格認為軟體開發就是靠團隊的溝通和互動,所以沒有關注人的組織,是做不出有品質的軟體的。

近年來台灣敏捷社群的學習主軸也從方法論(Scrum、Kanban)引導技巧、走向心靈路線 XD(當然還有硬工夫 DevOps)。去年參加陳茂雄老師的薩提爾冰山模式課程後,對薩提爾的理論有更一步的認識,但一直沒有真實面對自己的足夠勇氣去上薩提爾的工作坊。

直到今年 Odd-e 邀請 Jean McLendonHugh Gratz 在新加坡引導薩提爾成長工作坊,因為機會難得不用飛美國,我就豁出去參加了。他們兩位在薩提爾的身旁學習了二十多年,直到薩提爾於 1988 年去世。也因為這次在新加坡難得的經驗,讓我有機會把過去三年從不同的書上、工作坊裏學到的各種薩提爾理論與技巧,統整在一起而有了整體性的了解。 繼續閱讀 “薩提爾成長工作坊參與心得(Satir Growth Workshop)”

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

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

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

一回生、兩回熟 – 公司內開放空間會議第二彈

今年中內部討論要不要辦開放空間會議Open Space Technology)時,就決定今年至少要辦兩次,讓參與者可以比較兩次的差異性。所以在六月第一次舉辦後就接著安排九月的開放空間,第一次的主題是:『What can we do to support each other grow? / 我們要做那些事情來相互支持成長?』,而這次的主題定為:

我們要如何在接下來的三個月創造最大的影響?  
How can we create the most impact in the next 3 months?  

稍作改變的活動規劃

跟第一次的主題相比,第二次的主題刻意訂的範圍小一點,比較聚焦。有兩個原因,一是因為組織文化比較行動導向,太發散或天馬行空的發想怕大家覺得浪費時間。二是也是為了讓大家了解其實主題或討論結果可以實踐在工作上面。 繼續閱讀 “一回生、兩回熟 – 公司內開放空間會議第二彈”

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

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團隊自組織的具體方法”