別高談敏捷式管理說說如何落地(2) – 企業敏捷轉型工具箱

企業使用敏捷式管理的目標是讓企業可以快速反應市場的變化。讓產品或服務儘快推出面對市場,並依據取得的反饋來改善企業所提供的產品或服務,使其在市場上更有競爭力。具體的做法包含從大批量生產的思維,改為小批量生產試賣。

『面對敏捷轉型的浪潮,你準備好了嗎?』一文中我們介紹了敏捷轉型(Agile Transformation)的由來和精神,這一切聽起來都無限美好,但具體要如何落實敏捷式管理呢?

上一篇我們談了如何讓團隊敏捷化,現在我們來看看如何讓企業敏捷轉型。

如果你可以預測未來,你並不需要敏捷

但變革不是重點,重點是為什麼要變革。同樣的,在讓企業敏捷化之前,我們要先知道為什麼企業需要敏捷化。 閱讀全文〈別高談敏捷式管理說說如何落地(2) – 企業敏捷轉型工具箱〉

別高談敏捷式管理說說如何落地(1) – 手把手打造敏捷團隊

為了更好的應對變化和增加企業的可持續性,敏捷式管理以團隊為核心來運作,並希望團隊可以:
擁有共同的目標、自行交付端到端的產品或服務、跨職能的團隊成員、穩定的團隊組成、依照 Scrum 或看板的方式來運作

『面對敏捷轉型的浪潮,你準備好了嗎?』一文中我們介紹了敏捷轉型(Agile Transformation)的由來和精神,這一切聽起來都無限美好,但具體要如何落實呢?

我們接下來分別來看看針對團隊和企業的敏捷方法,這篇文章的重點在於如何讓團隊敏捷化。

以團隊為核心的敏捷工作方法

敏捷式管理是以團隊為運作的核心,對主管的要求是成爲僕人式領導,也就是支持團隊的成功與成長,而對團隊的組成有下面幾個要求:

團隊需要有共同目標

團隊成員要有個共同的目標,通常是提供給顧客某一種產品或服務。如果團隊沒有共同的目標,那就只是一群人,不能稱之為團隊。 閱讀全文〈別高談敏捷式管理說說如何落地(1) – 手把手打造敏捷團隊〉

面對敏捷轉型的浪潮,你準備好了嗎?

『你今天敏捷了嗎?』

近期『敏捷』兩字開始在商業企業的書籍雜誌上出現,而到底敏捷是什麼意思呢?導入敏捷對企業組織的好處是什麼?會帶來什麼影響?有什麼缺點呢?

源於軟體開發的敏捷

敏捷(Agile)一詞是在 2001 年由一群軟體輕量型開發的實踐者在美國猶他州的聚會上提出的,以他們十多年的實踐經驗為基礎,他們提出了敏捷開發的四大價值觀:

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃

也就是說,雖然右側項目有其價值,但我們更重視左側項目。

在過去的十多年,敏捷開發的各種方法論,如 Scrum看板方法極限編程(Extreme Programming, XP)在軟體和新創圈引起了一股旋風,也改變了如何軟體開發與製造產品的傳統觀念,大家耳熟能詳的許多公司如 Google、Facebook、Netflix 都已大量運用敏捷的方法在他們的日常營運中。在國外的資訊產業,大家在談論的已經是如何更好的使用敏捷,而不是要不要使用敏捷。 閱讀全文〈面對敏捷轉型的浪潮,你準備好了嗎?〉

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

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

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

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

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

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

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

先聲明非關政治,我也沒有研究此會議的流程所以沒辦法判斷對錯。但這是很好的案例,來探討一個所有主管都會遇到的問題:『團隊決定的和我想要的不一樣怎麼辦?』 閱讀全文〈團隊決定的跟我想的不一樣!- 談參與式決策的技巧〉

欸對準一點 – 談校準的重要性(不服從的領導學心得)

關於校準這個概念我是從 The Art of Action (不服從的領導學)一書中學來的,我認為這是影響我蠻大的一個管理概念,之中的許多想法也暗合敏捷精神,如響應變化 重於 遵循計畫 (Responding to change over following a plan)。

不管在工作中還是敏捷開發,都有強調做價值的事,『有效』重要過『效率』(Effectiveness over Efficiency)。剛剛好在臉書上看到什麼是『有價值的工作』的討論,我覺得價值本來就是主觀的東西,沒有對錯,所以校準(Alignment)會比價值本身是什麼更重要。組織的方向是節約成本、研發為主、創意開放、流程至上,具體的做法都會不一樣。如果每個部門往公司的方向對準,每個團隊往部門方面對準,每個成員往團隊方向對準,那整體就超強啦。

關於校準這個概念我是多年前從 The Art of Action (不服從的領導學)一書中學來的,我認為這是影響我蠻大的一個管理概念,書中的許多想法也暗合敏捷精神,如響應變化 重於 遵循計畫 (Responding to change over following a plan)。(順帶一提,我覺得很多中文書名都跟內容不符,也許可以增加看書皮購買的興趣,但買了發現跟想像不同不是讓讀者感受更糟嗎?還是其實因為買書有看內容的是少數?越想越可怕 XD)

阻力無所不在

在組織中其實很多政策都是為了校準,確保下級單位有把上級的目標放在心裡,比如說 KPI 就是用胡蘿蔔與棒子的思維來校準。但為什麼我們花了很多心力在校準,但結果往往跟我們想的不一樣呢? 閱讀全文〈欸對準一點 – 談校準的重要性(不服從的領導學心得)〉

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

讀到每个程序员都该知道的五大定理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 大停電談「系統的崩壞」 閱讀全文〈小心定律就在你身邊 – 五個系統設計常用的定律〉

%d 位部落客按了讚: