超越控制與放權：探索管理者在Scrum中的關鍵角色（一）
〈這裡說的「管理層」、「管理者」和「主管」為同一意思〉
中英對照翻譯
💡來源出處：Scrum Pattern — Involve the Managers
…組織已承諾採用 Scrum，並且現在開始使用 Scrum 來指引產品的構思與實現。但 Scrum 與傳統的組織結構有相當大的不同，因此傳統組織角色的定位問題隨之而來。那些在傳統產品開發中擔任管理職務且感到舒適的人，現在正在尋找在 Scrum 文化中的對應角色。在生產多種產品的大型組織中，管理層特別顯眼，但即使在所有規模的傳統組織中，管理層也具有一定的影響力。管理職責與 Scrum 角色的職責有所重疊。當組織開始思考管理控制的範圍，甚至是否需要管理層時，一個迫在眉睫的難題變得明顯。
…the organization has committed to adopting Scrum and is now starting to use Scrum to guide the conception and realization of its products. But Scrum is considerably different than traditional organizational structures, and questions arise about the place of traditional organizational roles. Those who were comfortable with management roles in traditional product development now seek analogues in the Scrum culture. Management has a particularly visible presence in large organizations that produce multiple products, but also carries influence in traditional organizations of all sizes. Management responsibilities overlap with those of Scrum roles. An imminent dilemma becomes clear as the organization deliberates the extent of management control, or whether there should be management at all.
✥ ✥ ✥
在 Scrum 框架中並沒有管理者。Scrum 開發團隊是自我管理的團隊，而產品負責人（Product Owner）雖然對利害關係人和投資人負責，但並不受企業內任何高層的控制。因此，在敏捷轉型中，管理者難以找到能發揮其貢獻的角色，除了可能成為一個不分職位的支援角色。
There are no managers in the Scrum framework. Scrum Development Teams are Self-Managing Teams, and the Product Owner, while accountable to stakeholders and investors, isn’t subject to control by any higher power within the enterprise. So managers in an agile transformation have difficulty finding an outlet for their contribution except as an otherwise undifferentiated support role.
在傳統組織中，開發經理協調工作，並且可能在開發團隊中直接分派工作。然而，回應變化和在接近工作現場做出快速決策的需求表明，開發人員應該管理自己的日常開發活動。這就是 Scrum 產品開發的運作方式。然而，傳統的管理技能和身份在複雜的產品開發組織中仍然有其意義。這些技能超出了日常開發的範疇，也超出了 Scrum 能帶給組織的範疇。
A development manager in a traditional organization coordinates work and may actually give work assignments in a Development Team. But the need for responsiveness, and for making rapid decisions close to the work, suggest that developers instead manage their own day-to-day development activities. This is how Scrum product development works. Yet the traditional management skill set and identity may still make sense in a complex product development organization. This skill set falls outside of day-to-day development and outside of what Scrum brings to the organization.
「管理者」這一職位在法律上往往具有代表公司的地位和承擔公司活動責任的意義。管理者有能力重組組織，而產品負責人則無此權力。雖然單個Scrum 團隊可以應對日常干擾和突發事件，但單獨的團隊無法靈活處理超出單一團隊範疇的問題。例如，對於一個為多個產品提供開發支援的外部供應商來說，單一產品負責人來承擔合約的責任，就顯得不合適。
The position of “managerˮ often carries distinguished standing under the law in terms of being able to speak for the company, and in terms of carrying liability for corporate activities. Managers have the station and power to restructure the organization while Product Owners do not. While individual Scrum Teams can navigate daily interruptions and exigencies, they individually cannot adeptly deal with issues beyond the scope of a single team. For example, it is awkward for any single Product Owner to bear the contractual responsibility for a relationship with an external vendor that supplies multiple product developments (i.e., the development efforts of multiple Product Owners).
從英語中對「管理」一詞的定義來看，管理本質上涉及控制和責任。責任意味著願意承擔責任。Scrum 中沒有管理層的原因之一是，開發過程的控制分散在自我管理團隊的成員之間。由於開發工作複雜，開發領導力在團隊成員之間動態轉移。任何集中的控制或管理都會使工作效率下降。然而，除了開發本身外，還有其他支持產品開發努力的必要功能。產品負責人對產品的方向有最終決策權，這實際上也是一種控制，因此認為 Scrum 完全沒有控制中心的觀念是一種誤解。
In the usual English language sense of the term, management is fundamentally about control and responsibility, according to the dictionary definition ([1]). Responsibility means willingness to take accountability. One reason there is no management in Scrum is that control of the development process is decentralized across members of the Self-Managing Team. Because development is complex, development leadership moves dynamically from team member to team member. Efficient work languishes under any locus of centralized control or management. Yet, there are functions other than development per se necessary to sustain a product development effort. The fact that the Product Owner controls (has the final say over) the direction of the product is indeed a form of control, so the sentiment that Scrum is without any loci of control is a myth.
在經營一個生產型組織時，還有一些方面，比如 Product Owner 的這項 Scrum Pattern 提到，集中決策可能比集體共識更適合。例如，一些關鍵的商業決策，可能依賴於「直覺」而非單靠會議討論或實證分析。AT&T 公司曾因認為，現有的模擬技術經濟效益較佳，而決定不追求當地的數位交換市場。北方電訊（Northern Telecom）於1970年代後期開始開發 DMS-100 數位交換機，當數位手錶剛剛出現，數位技術也變得流行時，北方電訊出其不意地在 1979 年擊敗了AT&T。市場對價值的認知超越了工程分析。
There are yet other facets of operating a production organization that, as with the Product Owner case, may be better suited to centralized decision-making than to collective consensus. For example, some crucial business decisions may owe more to “gut feelingˮ than can be substantiated by caucusing or empirical grounding alone. When considering whether to transition from analog to digital telecommunications, AT&T justified that the existing analog technology was economically superior, and decided to not pursue the local digital switching market. Northern Telecom started developing the DMS-100 digital switch in the late 1970s and caught AT&T off-guard, as digital had become fashionable in the age when digital watches were emerging. The market perception of value trumped the engineering analysis. Evolving an existing product wasn’t enough: it was a matter of launching a new product line. Though there were intense discussions of these issues at the engineering level in Northern Telecom, it was ultimately a management decision for them to pursue digital switching out of a hunch and vision. They beat AT&T to that market in 1979. [2]
在一家開發多項產品的企業中，現有的 Scrum 團隊在處理與團隊或產品生存周期相關的戰略問題時，會感到尷尬。比如，在一個生產多種產品的規模化組織中，決策需要集體考量，好比在不同產品之間合理分配承擔風險的責任。儘管產品負責人們（Product Owners）可以對產品負責，但他們無法自行承擔問責責任。當商業考量要求放棄產品時，他們往往無法做出足夠客觀的判斷。個別產品本身可能也沒有足夠的範疇、資源或備案能力來承擔重大風險。
In an enterprise that develops multiple products, it is awkward for existing Scrum Teams to deal with strategic issues related to the lifetime or very existence of a team or product. For example, decisions in a scaled organization (producing multiple products) include collective considerations, such as responsible distribution of risk-taking across different products at different times. While Product Owners can take responsibility for a product, they cannot levy accountability on themselves. They are unlikely to have an adequately objective view to defund their own product when business sense dictates that they should. So individual products may themselves not have the scope, resources, or fallback ability to take major risks.
Scrum 團隊強調持續改善（kaizen），但 kaizen 強調的是持續的、局部的漸進變革。然而，有時候產品甚至整個企業必須經歷不連續的變革才能生存下去。極端的案例包括 Sun Microsystems 縮減硬體業務、Nokia 從製造橡膠靴轉型為手機製造商，以及 Toyota 從製造織布機轉型為汽車製造商。IBM 則從 1985 年硬體銷售佔收入的近四分之三（當時軟體是捆綁銷售的組件）轉型為服務型組織，到 2015 年硬體銷售收入佔比不到 10% 。1986 年，管理層決定在六年內，將服務業務從收入的 25% 提高到 40%。
Scrum Teams emphasize ongoing kaizen, but kaizen emphasizes ongoing, local, incremental change. Sometimes a product or even an enterprise must go through discontinuous changes to survive. Extreme cases include Sun Microsystems slimming down its hardware business, Nokia going from making rubber boots to making cellular phones, and Toyota going from making weaving machines to making cars. IBM went from 1985 hardware sales accounting for almost three quarters of their income (in which software was a bundled component: see [3]), to a services organization where 2015 hardware sales were less than 10 percent of the income. [4] In 1986, management decided to boost its services business from 25 percent of its income to 40 percent of its income within six years ([5], p. 52).
產品負責人和 Scrum 團隊通常專注於透過 kaizen 的漸進變革來管理風險，因此可能無法看見這些轉型機會。他們可能不願通過放棄產品（即他們自己的產品）來降低風險。團隊成員可能將激烈的變革（在日文中稱為 kaikaku）視為威脅。任何單一產品的組織，可能會認為上面提到的這些大幅躍進超過了他們的風險承受能力。如果組織將所有改善的責任都推給各個產品或最低層級的團隊，最終可能會產生數個局部最佳化的產品，卻忽略了更廣泛的產品或業務協同機會。
Product Owners and Scrum Teams may be blind to such opportunities because they usually focus on managing risk through the incremental changes of kaizen. They may not want to mitigate risk by killing a product — namely, their own product. Team members may view radical change — called kaikaku in Japanese (see Kaizen and Kaikaku) — as a threat. Any single product organization may feel that great leaps such as those of the above examples exceed their risk appetite. If an organization pushes all responsibility for improvement into individual products or onto the lowest-level team, the result can be several locally optimized products that ignore opportunities for broader product or business synergy.
管理者通常在敏捷轉型開始時便存在於組織中，甚至可能是轉型的發起者。他們想要幫助團隊，但那些已被教導自我管理的團隊，往往視這種管理層的幫助為不受歡迎的干涉。一位管理者可能會不斷介入 Scrum 團隊的事務，分散團隊的注意力，並成為一種干擾。在極端情況下，該管理者甚至可能會親自執行技術工作，或指導團隊成員如何完成他們的工作。2001 年，Wayne Rosing 在擔任 Google 工程副總裁時，解雇了所有這樣的管理者，並將所有約 160 名管理者直接向他匯報，正如他在 [6] 中所述。然而，Rosing 作為管理者自己做出了這個決定：使組織不僅僅停留在局部最佳化，就必須有人點燃不連續的變革。
Managers are often present in the organization at the outset of an agile transformation; they may even initiate it. And they want to help. Teams that have been taught they are self-managing often view such management help as unwelcome. A manager keeps meddling in the affairs of the Scrum team, distracting the team, and generally becoming a nuisance. In extreme cases, the manager might even take on technical work or tell team members how to do their job. Wayne Rosing disposed of all such managers when taking the reins of vice president of engineering at Google in 2001, and had all 160 or so of them report directly to him, as he tells in [6]. Yet Rosing took this decision as a manager himself: somebody has to ignite discontinuous changes if an organization is to move forward on more than just local optimization.
因此：
應維持一個具備權力的管理職能，能夠在組織中發起並負責推動激烈的變革（ Kaikaku ），並處理 Scrum 團隊中的 Scrum Master 或產品負責人無法應對的重大阻礙。Scrum 團隊在戰術層面和大部分產品策略方向上自行管理，主要以自主團隊的形式運作。Scrum 團隊每週與管理者在 MetaScrum 會議上互動（通常由產品負責人代表），但管理者不參加其他 Scrum 活動。
Therefore:
Sustain a management function that can act from a position of power to initiate, and take responsibility for, radical changes in the organization, and deal with impediments that may be too weighty for the ScrumMaster or Product Owner in the Scrum Team. Scrum Teams manage themselves in all matters of tactical and most strategic product direction, functioning largely as Autonomous Teams. Scrum Teams interface with managers in a weekly MetaScrum event (typically through their Product Owners), but managers do not take part in other Scrum events.
💡 這項 Scrum Pattern 的系列文：
- 超越控制與放權：探索管理者在Scrum中的關鍵角色（一）：中英對照翻譯
- 超越控制與放權：探索管理者在Scrum中的關鍵角色（二）：中英對照翻譯
- 超越控制與放權：探索管理者在Scrum中的關鍵角色（三）：中英對照翻譯
- 我對「Involve the Managers」這項 Scrum Pattern 的想法：TBD
喜歡這篇文章 ⮕ 歡迎「拍手 5 次～」支持並「追蹤」我！謝謝你的閱讀！👍🏻 👍🏻 👍🏻 訂閱我 ⮕ https://kktalks-tw.medium.com/subscribe
