iT邦幫忙

2021 iThome 鐵人賽

DAY 11
1
IT管理

我們與敏捷團隊的成長系列 第 11

Scrum 也自然嗎

前言

昨天談到敏捷的重點是其背後的精神,而 Scrum 也不例外,但為什麼 Scrum 的導入還是這麼艱辛,有這麼多辛酸史呢?

Scrum 導入有障礙

上一篇文章「自然而然的敏捷導入」,那真的跑 Scrum 時還自然得起來嗎?可能有人會說:「Scrum 導入明明很有障礙!」

作為預備知識,這邊非常簡略提一下 Scrum。

Scrum 描繪了:

  • 三個角色:Developers、Product Owner、Scrum Master
  • 五個事件:Sprint、Planning、Daily、Review、Retrospective
  • 三個產出:Product Backlog、Sprint Backlog、Increment

這是 Scrum 的基礎,也是第一眼看上去最容易捕促到的,更是許多團隊跨入的一步,之所以說它易學難精,也可以從這些名詞略知一二,通常只要花一些時間了解定義,跟著活動大綱執行,那就概就有幾分像了,但是每個角色、每場活動是否可以發揮的活靈活現,體現出它真正的價值,那就得看功夫了。

這些活動就像是一種捷徑,一種被精心設計過,認為可以取得成果的方法,團隊若沒有了解這些角色與活動背後的「深意」,那麼執行起來就只是在模仿,自然陷入各種困境。

什麼深意呢?就是所謂 Scrum 的 3 大支柱與 5 大價值觀。

  • Scrum 的 3 大支柱:「透明」、「檢視」與「調適」
  • Scrum 的 5 大價值觀:「承諾」、「勇氣」、「專注」、「開放」與「尊重」

再說回 “Scrum” 這個詞,引用「Scrum 精髓」一書的說明:

Scrum 不是縮寫,它借用的是敢欖球運動術語。在敢欖球運動中,這個述語指的是在意外犯規或球出界後重新開始比賽。就算你不是球迷,也該見過爭球,兩個隊的前鋒在球前面圍成一圈,彼此的胳膞架在一起,低頭爭奪球權。

雖然這個出自橄欖球的名詞常常讓人第一次看到時產生疑惑,但背後暗喻的「球隊(團隊)」、「合作」、「創造價值」的概念仍然精妙。

那麼,導入 Scrum 會有哪些障礙?常見的可能有高層是否支持、成員是否接納、原本組織的行事作為是什麼、團隊技能(能力)高低、團隊實現自我管理前有多大的距離等,這些多少都可以在書籍或各場次的演講議程中聽到分享,但我想就另一個角度談談,就是我們對 Scrum 認知是否有什麼誤會?

Scrum 誤會

這邊跟大家分享我觀察到 3 個的誤會,它可能發生在導入前與導入中。

速度

兵貴神速,速度一直是大家在意的,也是搶攻市場的重要利器,好在「敏捷不等於快」的這個概念也已經由無數大神們多次澄清,相信這個誤會不會持續太久。

「但我現在最想做的事情就是讓交付變快啊!」
「導入之後沒感覺變快啊!」

哎呀!這可真是道理我都懂啊!但我導 Scrum 就是要快啊!

https://ithelp.ithome.com.tw/upload/images/20210925/20141971QttMHcyU3l.png
(不知道讀者有沒有看過這個梗,沒有的話如上 Google 即可)

嗯… 我的看法是,也許會變快,但這個快是這樣來的:

  1. 來自團隊回應變化而來,在整個專案過程中巧妙應對、頻繁調整而來。
  2. 來自團隊有良好的互動與溝通,作為技能精進的後盾。
  3. 來自團隊有效率的協作,並減少浪費。
  4. 來自團隊高度自主與同心,擠心打拼,避免無謂紛爭。
  5. 來自利害關係人的開誠佈公,讓大家走在對的道路上。

而這些都是間接的,還得是團隊內外都要養成這些基本能力,才能慢慢展現出來。

但是有什麼東西可以讓我們慢下來?可多了!而且即時又直接,一踩到就慢,隨意列舉幾個:

  1. 領城知識不足
  2. 技能不足
  3. 技術債
  4. 需求變更
  5. 需求傳達有誤
  6. 多頭馬車
  7. 外務插斷
  8. 基礎設施異常,如網路、開發環境、CI/CD Runner 等

與其對於 Scrum 抱有高度期望,不如先看看目前「慢」在哪裡?而這些問題,在我們決定執行 Scrum 前又存在了多久呢?

只剩下 Scrum

過度強化導入 Scrum 這件事之後,一時之間團隊心中只剩下 Scrum 了,忘了 Scrum 本身是留下一些空白的。團隊還是有許多 Scrum Guide 之外需要努力的事情,這也呼應前一小節談「速度」時,我提到的那些造成團隊交付緩慢的原因,團隊本身對於工程方面的著墨有多少呢?

以軟體團隊為例

  1. 是否有能力寫出足夠有彈性的程式架構,好來回應變化呢?
  2. 是否有足夠的自動化測試,好隨時把守品質呢?
  3. 是否有 Pair 或 Mob 的經驗或打算,好讓實作、學習,甚至品質能夠繼續提升?

不明究理的「守」

源自日本武術的「守破離」概念,讀者可能在談論敏捷的書籍看見過。它描述學習的過程中從按部就班的「守」,到了融合各方與自己見解的「破」,最終產出自己的一套方法「離」。把這個觀念放到 Scrum 來,可以知道一開始的「守」是要我們循規蹈矩,熟練每個基本功。

如果成員只把 Scrum 相關活動看成一種規範、一種要遵守的制度、一種上司/公司的要求,而無法內化它,就很難在工作上展現其精神,這樣的導入即便流程再怎麼完美,也總有不到位的地方。

以下舉了一些問題,我們可以來練習回答,檢視一下自己是否知道每個問題背後對應到的用意:

  1. 為什麼要開 Daily Scrum?為什麼要限 15 分鐘以內?
  2. 為什麼要更新看板,我只要最後交得出來不就行了?
  3. 為什麼要用使用者故事 (User story) 來表達?
  4. 為什麼規劃會議要全團隊參加,這不是很浪費時間嗎?
  5. 為什麼要使用 Planning Poker (或 T-Shirt Size) 估計?
  6. 為什麼不要直接估計工時?
  7. 為什麼要團隊來想,這不是 PM 的工作嗎?
  8. 為什麼要自己認領工作,這不是主管該指派的嗎?
  9. 為什麼要開回顧會議,把時間拿來 Coding 不是比較好嗎?

團隊真的知道自己在「守」什麼嗎?

小結

都還沒談每一個 Scrum 活動究竟要怎麼進行,就可以發現在那之前存在不小的誤會,如果團隊或利害關係人沒有釐清,還是會走不少歪路。

Scrum 是個值得嘗試的框架,我們期待它可以為團隊來帶正向的循環,而不要讓已存在的問題成為否定它的原因。

回應標題「Scrum 也自然嗎?」,我認為是的,只是我們常常會不小心想太多,產生過多的幻想,讓 Scrum 披上一層魔法的外衣。


上一篇
自然而然的敏捷導入
下一篇
時間擠一下就有了,我們擠了沒?
系列文
我們與敏捷團隊的成長31

尚未有邦友留言

立即登入留言