標籤: 組織轉型

也許你需要的是多一點瀑布 – 敏捷八不

（English version published on T.8YTES 本篇文章為 Agile Me 2018 與 2019 台灣敏捷高峰會準備講稿，請按此觀看『敏捷八不』投影片）

大道之行也，天下為公，選賢與能，講信修睦，故人不獨親其親，不獨子其子，使老有所終，壯有所用，幼有所長，鰥寡孤獨廢疾者皆有所養；男有分，女有歸，貨惡其棄於地也不必藏於己，力惡其不出於身也不必為己，是故謀閉而不興，盜竊亂賊而不作，故外戶而不閉，是謂大同。

– 《禮運大同篇》

在 2014 年我剛剛開始接觸敏捷（Agile）時，當時我的角色是新加坡商鈦坦科技的總經理，我覺得敏捷（包含敏捷開發、敏捷專案、敏捷管理）在描繪的是一幅理想中的世界。就拿敏捷大家族中熱門的 Scrum方法 舉例來說，在 Scrum 團隊中沒有主管發號司令，工作由大家一起分工合作完成，也沒有主管指派工作，每個人自行選擇工作事項。團隊成員不會偷懶，會盡力把事情做好，最後的工作成果則是由團隊共享。（註：產品待辦事項是由產品負責人 Product Owner 決定，但如何完成工作是由團隊決定）

簡單的說，就是『各盡所能、各取所需』，這也是共產主義中理想社會的呈現。

各盡所能、各取所需

– 馬克思《哥達綱領批判》

但等到真的把頭洗下去，才發現完完全全不是這樣一回事！ 閱讀全文〈也許你需要的是多一點瀑布 – 敏捷八不〉

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

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

在敏捷開發或 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

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

小心定律就在你身邊 – 五個系統設計常用的定律

讀到每个程序员都该知道的五大定理（5 laws every developer should know），感覺這些可以應用在系統設計上的定律，應用在社會和人生上也没有違和感。

文中提到的五個定律分别是

  1. 墨菲定律 Murphy’s law
  2. 高德納定律 Knuth’s law
  3. 諾斯定律 North’s law
  4. 康威定律 Conway’s law
  5. 帕金森瑣事定律 Parkinson’s law of triviality

1. 【墨菲定律 Murphy’s law】

“只要有可能出錯，就一定會出錯。”
“Anything that can go wrong will go wrong.”

如果殺人祭天有用，就殺吧。但如果換另一個人還是有可能出錯，這時獵女巫是没有用的，系統性問題要用備源、防呆、容錯、再確認等等機制處理。

舉例：從 815 大停電談「系統的崩壞」 閱讀全文〈小心定律就在你身邊 – 五個系統設計常用的定律〉

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

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

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

%d 位部落客按了讚：