# LINE TODAY的大規模敏捷之路 - 陳岳澤 Derek Chen

> 從這開始共筆，您可以分享任何聽到、學到的事物

> Scrum Master @ LINE Taiwan

# Agenda
- Why
- The origin of story
- How
- Self-Designing team
- LeSS adopation
- What
- 5 experiments in our process

# LINE TODAY Background
- Product Team
- 40+ People
- 1 PO team
- 3 Dev teams
- Process
- Multiple product backlogs
- Six-week Sprint
- Small waterfall
- Team lead assign work
## Six week Sprint Schedule
- Week 1 : planning week.
- Week 2 : Development
- Week 3 : Feature Testing
- Week 4 : Development
- Week 5 : Feature Testing
- Week 6: Regression Testing

## After one year 2019
- Challenges with Scale
- 大象會亂走不會往同一個方向前進
## Challenges
- Trust:Stakeholder's requests take longer to deliver, so we lost their trust
- Priority:我自己的需求是最重要的．有多個不同的PO，都認為自己的需求是重要的．需要搶優先序．
- Complexity:越來越多的人加入後溝通成本上升
- Adapation:SM要保護團隊不受外界影響
- 一個小小的需求可能要 6+6 week後才能完成

### Goals
- Increase customer value
-　以使用者為中心價值導向
- 一個 product backlog 的方式建立優先序

- Reduce waste and lead time
- Form feature team
- Reduce social conflict

## Self-Design team workshop

- Trainings 教育訓練
- Forming 組建團隊
- 各各技能的熟練程度,寫在技能卡上
- 伙伴不是我想要一起工作的
- Reviewing
- 每組 7-8人, Senior和 Junior要差不多
- 沒滿足要修正
- 約花三回合組成 feature team
- Voting for Scrum Master

Result:
- 左邊是產品交付團隊
- 右邊是 PO team

## Large Scrum Scale adoption
- LeSS Framework
- PO 排 product backlog 優先順序
- LeSS 有一個重要的特性,把 sprint 拉齊
- Sprint Planning 1 做團隊 Level的分工合作
- Sprint Planning 2 由團隊內的組員討論
- Sprint Review 由所有團隊一請進行
- 之後會有 Retro,overall retro
- Cross-team Coordination
- Align the Development pace 對齊開發節奏．在 Sprint Planning, DailyScrum, Sprint Review, Retro 都對齊．
- Demo togather 做整體產品的具焦
- Hold overall retrospective
- Send scouts to other teams
參加別的團隊的 Daily看看有什麼可以帶回來
- Inter-team Coordination
- 開發人員做 Coding
- 測試人員寫測試案例
- 開發和測試是在一起做平行開發

- LeSS Principles
- More with LeSS 少即是多
- 組織人越來越多會做什麼?
- 需要更多階層?會有副作用,團隊成員溝通不順暢
- 需要更多角色?每個人對自己的責任感會更薄弱
- 需要更多流程?團隊會對所有權更薄弱
- 導入 LeSS 會更少交接
- Whole Product Focus
- 整個產品能帶給客戶的好處和價值
- 唯一的PO(產品負責人)對產品做排序
- Focus on High-Value Work (因為排序的效果，可以讓PO發現有些事情根本不用進行)
- Project: A Project -> B Project -> C Project -> D Project
- Agile: A1->B1->C1->D1->A2...
- System Thinking
整體動態的思考問題,做全局優化非局部優化

### Backlog 數量和 e2e cycle time 的關聯性

## 5 experiments in our process
### one space vs more space
#### Meeting in an open space
- 一個白板討論很辛苦
- 會有干擾吵雜
- 但是會有別的團隊的專家一起討論

#### Meeting in separate room

#### How does the team select stories?
- Select by priorities and the same epics
- 團隊會根據之前的經驗和story的順序進行挑選

### How do we deal with online issues?（Experiment3）
- From a maintence team
- 每個團隊在一定時間內輪流進行維護工作
- 人員分兩半,一部份 maintance 另一部份開發
- 利用修復 Bug 的機會,讓每個人增加知識的廣度

### 想下一代的產品需要做一些調整
- Have a Leading team and add new teams in area
慢慢的加入新團隊開發
### Do we really need full time Scrum Master
- 具焦的面向不同
Half time SM 兼職的
主要會在開發和SM的角色間快速切換
Full-time SM 全職的
主要會聚焦在教育訓練和組織的狀況

## Summary
- Why
- increase customer value
- Reduce waste and lead time
- Form feature team
- Reduce social cinflicts
- How
- Self-Desgning workshop
- LeSS

- What
- 參考 ## 5 experiments in our process

# Q&A
- 重新組隊時，抵死不從的人後來怎麼了（不認同或不接受該重組或流程的）
- 團隊是否符合遊戲規則
- 下一回改善
- 大家都是成年人
- 重新組團隊後，遇到了哪些混亂與技術上的挑戰？
- 大家對流程不熟悉
- 大家要有開放的心願意試試看
- 多個團隊都是接同一個產品的功能，那各團隊的開發語言、框架、Know how，是否相同？如果是不同的情況下，要如何解決？
- 開發語言基本上是一致的
- 橫向團隊會自己分享幫助他人
- 加強知識的廣度和深度
- 好奇的問，你們在跑LESS, 一開始分完團隊，這個團隊的陣型就固定下來？還是你們多久會切換一次團隊成員？
- 第一次自由組隊
- 接下來讓 team lead 做分配
- 依據您的介紹，LINE的設計師(UI/UX Designer)歸屬於PO team而非Dev. Team。請問貴公司的設計師都是如何與 Dev. Team 合作的？是以waterfall 方式預先設計好產品規格後才交給Dev Teams 以多個 Sprints開發嗎？或是有其他合作方式？
- Designer 會領先半個到一個 sprint.
- 請問老師，有沒有什麼型態的團隊不適用less,例如傳產？
- 適用 LeSS的領域非常稀有
- 產品屬於一百多人或更多人
- 團隊一開始要小不要大,成長後才考慮 LeSS
- planning 從一開始的一週, 變成一天, 這樣的設計會完整嗎？ 不周詳的plannig, 會不會造成開發中, 才發現有問題, 導致打掉重做
- 邊做邊學