組織設計的Star Model（2）：Strategy與Structure

Oct. 23 12:30~14:00

▲【圖1】節錄自〈The Star Model〉文章

 

上一集介紹Star Model的五個分類，接下來幾篇文章參考《Scaling Lean & Agile Development，簡稱［SLAD］》把Scrum放到Star Model來討論，看看在組織中拓展Scrum（以及敏捷開發）需要考量哪些因素。

依據戴明（Deming）的看法：「公司需要建立朝向產品與服務改善的一致性目標，其目的在於讓公司具備競爭力並可持續留在業界。」這句話剛好和《Management 3.0》書中對於敏捷的定義有異曲同工之妙：

敏捷就是關於如何在不斷變化的環境中保持成功。

因為討論敏捷拓展，所以直接把企業的strategy指定為：敏捷力（agility）也是很自然的一件事XD。在讓企業具備敏捷力的這個策略之下，企業組織要如何跟隨著調整？

***

Scrum本來就建議組成「跨職能」、「自組織」、「持續產品開發模式」的5~9人小團隊，將這個基本架構拓展到整個組織：［SLAD］建議組織產品群組結構（product group structure），如圖2所示。

▲【圖2】節錄自［SLAD］

 

以產品作為組織結構的分群單位，在同一個產品之下，再區分為：

• Requirement Area：如果產品規模很大，需要數十、數百甚至千人以上一起共同開發，第一步拓展Scrum的方式就是將開發人員切分為若干個Scrum Team（圖2中的Scrum Feature Team）。接下來會面臨一個問題：「這麼多團隊怎麼同時開發一個產品？而且Product Owner有辦法一個人應付這麼多團隊嗎？」［SLAD］建議先將產品依據requirement area（需求領域，簡稱RA）切割，然後把Scrum Team分派到各個RA裡面。針對每一個RA，指派一位Area Product Owner（APO）。一個RA最大不要超過10個Scrum Team，也就是90人左右。

舉個例子，一個超大型電子商務系統可能有產品管理、客戶關係管理、購物、物流等RA，每個RA有若干個Scrum Team來同時開發不同的end-to-end需求。

• Undone Organization：理想上，每個sprint結束Scrum團隊需要產生一個「潛在可交付產品增量（potentially shippable product increment）」，但實際上依據產品規模不同，要做到這種程度可能需要數年到十數年以上的持續改善努力。因此很多團隊在sprint結束之後還有許多undone work（未完成的工作）—產品釋出或是佈署到production環境所需要做的事情。例如處理不屬於單一Scrum團隊的測試工作、客戶要求的文件、軟體架構文件等。這些工作可以暫時交給Undone Organization（UO）來處理，但是Scrum拓展的目標是希望藉由增強團隊的Definition of Done，有一天可以達到每個sprint都可以產出「潛在可交付產品增量」的能力，減少UO的工作，甚至消除UO。
• Service & Support：一個跨職能的Scrum團隊自己要負責產生「潛在可交付產品增量」，但有時候組織會想要把支援工做獨立成一個Service & Support（SS）單位，讓它來服務多個團隊。例如，維護共享資源（昂貴、稀有、或數量龐大的測試設備），工具與基礎設施、協調與教練（facilitation and coaching）。

這樣的單位很顯然就是component team，也是Scrum想要避免的團隊模式。在組織SS單位需要小心專業過度集中與形成瓶頸的問題。

• Product Owner Team：PO團隊包含一位PO、若干位APO，以及其它可以協助釐清需求的成員。

***

看到這裡對於Scrum拓展應該有個基本的認識，最後還有兩個問題：

• 分散在不同團隊的專業人員要如何技術成長？答案是可以組成Communities of Practice（CoP），請參考〈單一職能團隊比較容易促進學習嗎？〉。
• 會計、人資、行銷、業務等部門跑去哪裡？關於這一點［SLAD］沒提到，暫時列入待釐清問題清單之中 XD。

***

友藏內心獨白：面向客戶的組織型態。