# 「重拾初心」- 全球敏捷轉型的反思 - Evelyn Tian

:::info
「重拾初心」- 全球敏捷轉型的反思
敏捷宣言已經誕生20多年，全球都在如火如荼地展開敏捷轉型。反思你自己的敏捷之旅，你是否有 “吾日三省吾身“？你是否“知而不用乎？用而不任乎？任而不省乎？省而不行乎”？

通過這個主題演講，我和大家分享我已經成功教練國際大、中型企業與輔導全球75個國家的敏捷實踐者們的經驗。通過組織、產品和團隊的實例，聚集於「重拾初心」的策略以達到持續改善的目的。
:::

:::warning
今天的內容不代表 Scrum Alliance 也不代表 Scrum Alliance 董事會
:::

* 教授的學生橫跨76個國家

## Agenda - 晏子和秦景公的故事
* 知而不用
* 用而不任
* 任而不思
* 思而不行
* 知而不知

### 知而不用
* 情境一:常會聽到「我們在用Scrum框架」，但是...
* Scrum-But (Scrum-但是)
* story 都做不完...
* 沒有 product backlog refinement
* 情境二:我們用了一段時間,發現沒什麼幫助,我們試看看看板,但看板用用,發現也不適合我們
* 看板-But (看板-但是)
* 我們的產品啊,我們的文化啊...有多特殊,所以...
* 延遲的專案再加人力，只會讓專案更加延遲
* 不是所有教條都要遵守
* 例如一個醫療的營銷團隊
* 沒有每個team都要一個醫生或一個法顧
> 無論是Scrum/Kanban ,都是非常強而有力的框架
> 但是在用對的條件下
> 注意，請不要教條，要考慮自己的場景

### 用而不任
* 情境:在敏捷輔導課時:一個英國學生,分享平常都在家裡剪髮,紮個馬尾,一刀剪下去即可.聽了之後,我也自己試一下(紮馬尾,老公剪一刀)
* 結果:正面看是ok的...但背面很慘...很恐慌,慘了,明天的研討會...
* 紮馬尾是有技巧的: 英國學生的老公已經練很久了
> 思考一下,在敏捷的環境裡,有多少一樣的狀況?
> 用了但是沒有發揮到原本的價值
* Product Owner
* 沒有跟真實的客戶有接觸,只跟業務接觸
* 大故事變小故事,寫驗收標準
* 變成:Product Backlog 專業撰寫者
* 沒有接觸客戶、Roadmap...
* PO 很多，看不到整個產品
* 換湯不換藥
* 只是換個名詞,把工作變成User Story,但其實根本沒有User
* 沒有時間和團隊互動
* 產品的卓越與否，和產品的定義，產品負責人的角色選擇，息息相關
> 產品負責人的角色是需要深度思考的
* 但大多公司不這樣想
* 無論多成功的實踐還是需要思考的
* 思考如何把好的實踐用到自己的組織裡面
> 不夠痛苦，不夠快速的收到回饋，所以很容易犯[用而不任]的錯誤

* Agile Coach
* 看一下job description,其實...
* manager不知道 Agile Coach 需要什麼樣的技能,怎麼合作
* Agile Coach 也不知道要發展什麼樣的技能
* 領導團隊、技術實踐、組織結構...
* 

### 任而不思
* Jira 工具
* 滿足客戶(Scrum Team)需求 -> 但客戶不一定有敏捷思維。
* 把創新的時間都花在 工具 上了:
* 每天都在玩 ticket，減少了人的互動
* 剛好跟敏捷宣言講的相反
* 是用了工具就敏捷了嗎? "用了幾年Jira" 不代表敏捷
* 常聽老闆要求:能不能教我們用工具 (哭笑不得...)
* 工具是為了幫助我們達到"我們的目的"
* 工具要為我們服務
* 工具是個好產品
* 工具不一定可以幫助你更敏捷
* 不要每天想著怎麼工具裡面工作,而忘記初衷

### 思而不行
* 依賴性/耦合性/相依性 - dependency
* 切除相依性高於管理相依性
* 通過相依性的管理找到切除相依性的幫助
* 相依性，是一個在開始決定 改善工作時 就要策略思考的問題
* 回顧很好,落地到行動,有持續改善才是目的

### 知而不知
* 管理層
* 看到價值,才會慢慢往前進
* 組織是一個複雜自適應系統 (we are special)
* 管理層:我知道啦
* 改善組織及敏捷轉型是個複雜的問題
* 起步時,每個公司的複雜自適應系統都不一樣
* 管理層:頭痛醫頭,腳痛醫腳
* 組織轉型不能直接套用一個框架
* 不存在的spotify模型
* 自相矛盾
* We are special vs 那個看起來不錯,我們來用吧
* 領導者要有成長型的思考,面對VUCA環境
* 作為個人要真正的學習

> 重拾初心來推進敏捷轉型，以實現你最初希望的結果 - Evelyn Tian
> 往後退一步，可能會有更好的前進
>

# Q&A
- （繁中）產品負責人和業務的權責要如何劃分？在我的經驗中，業務和PO對產品的方向往往有截然不同的想像，然後開始爭執到底誰有主導權。
- Evelyn:最重要的是你對 產品 的定義，例如 Spotify
- 分成小產品:列出"訊息"，把相關stakeholder都列進來,這樣業務就會被列進來,FAE,法務也都會列進來，再依照"訊息"來切割

- Product Owners usually have more insight about Product Domain, but have less domain knowhow in tech enhancement part, so how might we balance both?
- Evelyn: 如果你的產品不是技術導向, What & How 是可以分開的，PO 只要關注 What，具體實作細節倒還好。但有些 What&How 的分割要想一想，例如 bluetooth 連線 or NFC 連線，到底是 What 還是 How?
- Evelyn: 團隊要做架構 refactoring，也是可以把價值(效果)及需要的時間(成本)告訴PO，再讓 PO 放進 backlog 做優先序的排序

- （繁中）切除相依性是否有具體的例子呢?
- Evelyn: 以生命週期為例。架構改善，對你划算嗎?

- 想问老师的经验中，如果是内部辅助团队，例如hr、learning development团队，想尝试导入敏捷，那客户应该就是公司同仁，想了解团队交付的价值，在定义上，有没有什么方向上的建议？
- Evelyn: 先問"改善後,有什麼影響?"
- 沒影響? 你只是跟隨潮流為了敏捷而敏捷