iT邦幫忙

2023 iThome 鐵人賽

DAY 11
1

接下來我們來介紹一種組織團隊的方法, 這個作法是呂毅大師兄在華為進行的方式. 你可以在這邊找到全文: https://less.works/case-studies/huawei. 組成團隊的方法不只這種, 但是一開始有個方法參考也是不錯.

(1) 決定分團隊的條件

首先要先決定分組的條件. 基本上就是要符合 LeSS 規則中團隊的條件:a. 自管理的, b. 跨職能的, c. 同在一地, d. 長期存在的.

這些條件通常是由管理者先行討論決定, 大膽一點的是可以由團隊群們自行討論出條件來, 畢竟要自組織, 是可以考慮交由團隊群們自己去負責.

一般起手式, 可能會包含以下幾點. 後面就會再根據組織實際狀況再增加, 例如:團隊人數, 男女比例, 技術精通程度等等.

a. 在同一地點 (不要遠端協作)
b. 跨職能和跨元件, 讓他們單獨可以交付需求

有些狀況下, 他們最後會加一條:如果最後團隊自己無法決定, 由經理們幫大家來決定. 我想大家為了不想把命運交給管理者, 應該會在前面就會協商搞定.

但是有可能會遇到某些角色很稀缺, 例如:UX 設計人員, 自動化測試開發人員, 運維人員, 或是精通某個特殊元件的人員. 這時候是可以他們不屬於任何團隊, 日後開發時視狀況支援不同的團隊. 不過這裡 LeSS 通常會做一些事情, 就是讓團隊成員跟這些人員搭擋工作, 在幾次或是幾個迭代後, 將這些知識傳播給共多人會, 這樣就比較不會工作只是集中少數人身上.

下面是一組可能分組條件:

a. 在同一地點 (不要遠端協作)
b. 跨職能和跨元件, 讓他們單獨可以交付需求
c. 每個團隊至多 9 人, 至少 5 人
d. 每個團隊至多一個 UX 設計人員
e. 關鍵元件 (例如: XXX 元件) 至少有 1 個人員熟悉
f. 每個團隊至少要懂 3 個元件

(2) 分團隊的流程

在分團隊時可能的流程如下:

a. 開場

由主辦人介紹今天活動的流程, 以及最終想要達成的目標. 讓大家知道為什麼我們要有這個工作坊.

b. 選舉ScrumMaster

一開始就先看看有沒有人志願想要當 ScrumMaster, 最好能夠每個團隊都能有一位.

這是一個非常挑戰的步驟, 因為如果公司才剛導入 Scrum, 或者文化上還是屬於命令與控制, 在這個步驟上可能就不容易有人會願意出來擔任這個角色.

在傳統組織是沒有 ScrumMaster 這個角色, 當初呂毅在華為時, 是先用組長 (lead) 來取代, 也就是傳統會為一個小團體績效負責的人. 但是希望責任是團隊和組長一起承擔, 而不是都是落在組長身上. 但是之後會加強組長輔導的能力, 讓他們更懂 Scrum, 以及引導和教練的技能. 讓他們可以漸漸轉型到 ScrumMaster 這個角色.

c. 自組織第一回合

這個步驟我們會先請每個人, 根據每條分組條件, 寫出自己相對應能提供的內容. 例如上面的分組條件, 某個人在這些條件上所能提供的內容

a. 在同一地點 (不要遠端協作):高雄辦公室
b. 跨職能和跨元件, 讓他們單獨可以交付需求
c. 每個團隊至多 9 人, 至少 5 人
d. 每個團隊至多一個 UX 設計人員:RD
e. 關鍵元件 (例如: XXX 元件) 至少有 1 個人員熟悉:
f. 每個團隊至少要懂 3 個元件:目前會 ABC 和 YYY

在每個人寫出自己能提供的內容後, 大家就開始找尋想要變成同一個 Feature Team 的夥伴, 看著對方寫出的內容, 大家可以隨意交談, 盡量在時間限制內找到你志同道合的隊友.

等到時間到了以後, 主持人會檢查每個 Feature Team, 看看是否符合當初的分組條件. 如果有不符合的地方, 就給這個 Feature Team 一個 bug 單. 所以有可能檢視完畢後, 有些 Feature Team 拿了好幾個 bug. 只要有 bug 單, 就代表這個 Feature Team 是不合格的.

d. 自組織第二回合

重複第一回合的流程. 如果每個 Feature Team 都滿足當初的分組條件. 就可以跳到 (3). 否則就進行 e.

不滿足條件的 Feature Team, 需要思考如何解決 bug 單上的問題. 它可能跟別的 Feature Team 求助和討論, 所以有可能會造成已經滿足條件的 Feature Team 成員發生變動. 也就是說這時候一些都是可以改變的. 最終是要達成所有 Feature Team 都滿足條件.

e. 自組織第三回合

重複第一回合的流程. 如果每個 Feature Team 都滿足當初的分組條件. 就可以跳到 (3). 否則就進行 f.

f. 自組織第四回合 (非必要)

如果這時候所有 Feature Team還無法分組條件, 或許可以由管理者介入, 讓他來做後決定或仲裁. 有可能最後的結果還是非所有 Feature Team 都滿足分組條件, 但是這時候定了就是定了, 也許之後一段時間來再來檢討和調整.

(3) 團隊建立 (Team Building)

當團隊分組完畢之後, 這是一個很好的時機點, 讓團隊的成員, 進行團隊建立的活動, 讓彼此開始互相了解.

a. 自我介紹

進行的方式可以設計一下, 不用只是很單純的自我介紹. 可以藉由一些小遊戲, 讓彼此看到之前沒看過的一面.

b. 建立工作協議 (Working Agreement) 

這是一個很重要的活動. 工作協議描述了大家要如何一起工作. 例如:

有狀況時請及時尋求幫助
保持透明和誠實
積極提供建設性反饋
準時參加會議

為什麼需要工作協議呢? 因為大家一起做事, 總是有些習慣或是期待, 希望大家可以一致, 避免雙方落差太大. 事先把這些期待講清楚, 讓日後工作起來可以更愉快更和諧.

此外, 工作協議並非訂了之後就不能改變, 團隊可以一段時間之後再來檢視和調整. 這樣也符合敏捷的精神.


上一篇
Day 10 Large Scale Scrum 適合的組織結構
下一篇
Day 12 LeSS 框架的角色 – 產品負責人 (Product Owner)
系列文
多團隊如何協作進行敏捷開發的利器 - Large Scale Scrum (LeSS)30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言