English Audio versions of this case study are _available here

概要

長期的な成功を収めるには、プロダクトの境界（バウンダリー）を広く取り、プロダクトの全範囲を対象とするフィーチャーチームが必要だと強く信じています。コンポーネントチームから始めて、よりクロスファンクショナルなコンポーネントチームと、真のフィーチャーチームへと積極的に移行するための段階的なアプローチは、追求する価値があると信じています。

ナカシマのモジュラー・コンピューティング・システム部門におけるこの戦略の利点は以下の通りです。

• 拡張されたコンポーネント境界内での適応性と価値の提供を局所的に改善した。
• 品質向上を実現する技術的なプラクティスが改善され、さらに改善することで何ができるかを認識できるようになった
• 拡張コンポーネントに関連する不具合の早期発見と解決
• 拡張コンポーネントチーム内の従業員のコラボレーション、エンゲージメント、および学習が改善された
• 組織的な障害や、さらなる組織的な変革の必要性への認識が高まった

私たちの成功は、皆さんにとって刺激的であり、勉強になるものです。同様に、私たちの失敗を繰り返さず、新しい失敗をしながら学ぶことにエネルギーを使ってほしいと思います。

LeSS適応の全体像

プロダクト概要~組織をどう巻き込んだか~

ナカシマのモジュラー・コンピュート・システム（MCS）部門は、ハードウェア、ソフトウェア、ネットワーキング・コンポーネントを統合した製品開発に注力しており、これらのコンポーネントが一括して完全なプレバンドル型社内データセンター・ソリューションとして機能するようになっています。MCSは、Amazon Web Servicesのようなプラットフォームを、フォークリフトでオンサイトに配備するようなものです。典型的なエンドユーザーは、大手銀行、保険会社、携帯電話プロバイダー、科学研究機関などである。

規模感としては、ナカシマのMCS事業部だけで数千人規模になる。そのほとんどが、サンフランシスコ、ポートランド、ベンガルールといった大都市圏に集中している。

MCS事業部の仕事は、すべてMCSの製品開発に集中している。基板製作、金属加工、組み立てなど、量産品の製造はすべてMCS事業部が作成した仕様書をもとにアウトソーシングしている。

フィールドサポートは、ナカシマのもう一つの部門が担当している。フィールドサポート部門は、ナカシマの全製品に対してシームレスなカスタマーサポートを提供することに重点を置いています。電話機などのネットワーク製品、テレビ会議システム、ワイヤレスネットワークソリューションなど、MCSとは関係のない製品まで幅広くサポートを行っている。

実際、フィールドサポート部門には、MCSのサポートに特化したスペシャリストが存在する。このスペシャリストは、現場のお客様の実態や、MCSの大規模かつ多様なお客様の間でどのように変化しているかを観察するのに非常に有利な立場にあります。そのため、MCS製品を開発するエンジニアは、これらのフィールドサポートスペシャリストと直接協力することによって、最も有用でフィルタリングされていないフィードバックを得ることができます。

MCSのサポート体制は、一般的なコンシューマー向け製品とは異なります。迅速な対応が可能な、大規模なテクニカルサポートです。MCSを開発するエンジニアと同じように、フィールドサポートのスペシャリストも、専門分野に精通し、高い報酬を得ている。

トレント・ガンベールは、MCS事業部のプロジェクトマネジメントグループを率いてきました。このグループは、MCSの開発全体を調整する10人弱のプロジェクトマネージャーで構成されています。日々のプロジェクトマネジメントの多くは、MCS事業部内の様々なエンジニアリングディレクターが担当していました。MCS部門における私の最初のスポンサーシップは、トレントと、彼の副社長と当時の上級副社長兼GMの積極的な関与によってもたらされたものです。トレントは、私が以前ナカシマの別の部門で仕事をしていたことを知っていました。

初期のアジャイル適応の焦点について

当初の目的は、ほんの一握りの既存の（表向きの）「アジャイル」チームを評価し、意味のある改善を支援し、特定できた部門の他の有望な領域でアジャイル適応を開始することでした。

数日間の調査の後、今やっている「アジャイル」な取り組みが、アジャイルではないことが明らかになりました。たとえば、次のようなことです。

• 経営陣は日常的に見積もりを「コミットメント」として扱っていた。
• 自動化されたユニットテストのようなアジャイルエンジニアリングプラクティスが実践されていなかった。
• スプリントレトロスペクティブのような「検査と適応」のためのイベントがなかった。
• チームは自己管理からかけ離れていた。

既存の、いわゆるアジャイルな取り組みを最初に調査した後、私は学んだことをトレントと話し合いました。私たちは、最も効果的にエネルギーを注ぐべき場所は、変革の成功に最も貢献すると考えられる分野に、機能横断的かつコンポーネント横断的な新しいスクラムチームを作ることであると判断しました。各チームは、開発、テスト、リリース、その他の活動のすべての側面を実行する能力とともに、関係するさまざまな技術のあらゆる側面に取り組むためのスキルと権限を持つ必要があります。

私が既存の取り組みを調査したところ、上級管理職の大半が、健全な自己管理型チームに対する真の理解や経験を持っていないことが明らかになりました。これでは、より持続可能な部門全体の組織改革に十分な関心を持たせることは難しいでしょう。トレントと私は、１つのスクラムチームがスターチームとして成功すれば、より大きな賛同を得られると期待していました。

しかし、「構造的な要因のいくつかに対処できなかったことが、結局、それまでの成功の大部分を台無しにしてしまった」のです。構造的な要因のうち、大きなものは次の2つです。

• 報告関係の再構築を適切に行わなかったため、一部の管理職がチームメンバーの業務から目を逸らしてしまった。
• 新しい機能は、ナカシマ全体としては非常に大きな節約になるにもかかわらず、経営陣のインセンティブに付随するものであった。

これらについては、_【ラーマンの組織行動第一法則と第五法則の発現】(#bookmark=id.26in1rg)_の項で詳しく解説しています。

私たちはまず、MCS製品にエンド・ツー・エンドの診断機能を追加することに焦点を当てた1つのスクラムチームを立ち上げました。エンドツーエンド診断のスターチームは、このケーススタディの主要な焦点ではありませんが、初期の部分的な成功は、より広範なBIOS関連の取り組みへの扉を開くのに役立ったのです。

エンドツーエンド診断の取り組みは、BIOSの取り組みで遭遇した課題のいくつかを明らかにし、予兆を示すのに役立つので、診断チームの取り組みについては、後でもう少し詳しく説明します。

BIOS グループを巻き込んだLeSS指向の採用{#less-oriented-adoption-within-bios-group}

診断のスターチームの初期の成功と、私が MCS 部門の中で社交的であり続けたことが、BIOS グループの米国にいるエンジニアのディレクターである ミーチャ の興味を引き、最終的に加入させることになったのです。ミーチャ と私が率先して行ったBIOSグループ内でのLeSS指向の適応が、このケーススタディの主な焦点となります。

BIOSドメインは非常に複雑でした。加えて、BIOS開発だけに限定されたコンポーネント境界がありました。それでもLeSS指向の構造から大きな利益を受けるようなレベルでした。長年の習慣的な問題を解決するのに役立ったのです。

また、BIOSドメインは、MCSシステム全体のフルフィーチャー化に向けた自然な進化の道筋を提供するものでした。インテルがCPUを生産開始する前に、生産前の新世代のインテルCPUをMCS製品に迅速に吸収する能力は、市場の関連性を維持するために重要でした。これは、すべての必要なBIOS機能がプリプロダクションCPU上で正しく動作することを確認し、同様にブレードアーキテクチャの改訂と拡張がCPU統合の観点から適切に動作していることを確認することを含みます。さらに、MCS管理ユーザーインターフェイスで公開されるすべてのCPU管理サービスが動作していること、およびインテルが量産前のCPUで導入する新機能をサポートするために拡張されていることも確認する必要があります。

上記のすべては、MCS製品全体に対する自然なLeSS Hugeリクワイアメントエリアと見なすことができます。

LeSSフレームワークのルールでは、LeSS-Huge採用の各リクワイアメント領域は、「最初に」完全なLeSS構造を確立する必要があるとされています。ミーチャと私は、BIOSグループの米国を拠点とするメンバーを最初から完全に再編成しましたが、上級管理職との連携や賛同があれば、より充実した、より適切な製品のフィーチャーチームから始めることができたはずです。

私たちは、できる限りのことから始め、徐々にBIOSコンポーネントの境界を、さまざまなコンポーネント層を通して上方に広げていきました。「フィーチャーチーム Adoption Map for BIOS」と「Initial BIOS Component Boundary」、「Expanded BIOS Multi-Component Boundary」図は、この段階的な拡大を示しています。このアプローチは、「Large-Scale Scrum」で説明されている「フィーチャーチーム Adoption Map」ガイドと一致していることに、賢明な読者はお気づきでしょう。More with LeSS_で説明されている_フィーチャーチーム Adoption Map_ガイドと一致していることにお気づきでしょう。

BIOSのLeSS指向の適応活動は、ちょうどミーチャと私が活動を始めた頃に起こった上級副社長/GMの交代によって妨げられました。もし、当初のシニア・バイスプレジデント/GMと同じレベルの経営陣のサポートがあったなら、もっと幅広く、持続的な成功が達成されていたことでしょう。

私は、ナカシマのMCS部門におけるLeSS指向の採用活動の成功例と失敗例の両方から、多くのことを学びました。このケーススタディが、私たちの成功例から、そして失敗例からさらに多くのことを学び、皆さんの旅立ちの指針となることを願っています。

ハードウェア開発ではなくファームウェア開発に焦点をあてる{#initial-focus-on-firmware-not-hardware-development}

これまで、リリーススケジュールの予測に関する問題の大部分は、MCS製品開発グループのファームウェア（BIOS、ネットワーク・インターフェイス・コントローラ、シャーシ・コントローラなど）および上位のソフトウェア（MCS Administrator、診断など）開発面で発生していました。ハードウェアの開発面は、はるかに予測しやすい傾向がありました。

実際には、外部製造業者の製造仕様設計に携わる人たちとの会話はわずかな時間しかありませんでした。ハードウェアの設計に携わる技術者にLeSSの採用を拡大することは、長期的には意味のあることですが、当初の焦点には入っていませんでした。

実際、私が一緒に仕事をした診断チームもBIOSチームも、ハードウェアエンジニアと積極的にコラボレーションする必要性はあまりなかったのです。ファームウェアの開発者が必要なときはいつでも、ハードウェアの設計エンジニアと話をすることができましたが、それは頻繁に起こることではありませんでした。私がMCS部門にいた頃は、MCSは比較的成熟した製品でしたので、ハードウェア設計の変更は小規模で漸進的なものになる傾向がありました。将来的には、ハードウェアとファームウェアの開発をより緊密に統合し、部門横断的なチームによるイノベーションを促進できる可能性があります。

スクラムチームのメリットをアピールする{#demonstrate-benefits-of-a-scrum-team}

MCS 部門では、当初、ハードウェアとファームウェアの開発作業においてスクラムが意味を持つかどうかにつ いて、非常に大きな懐疑論があった。ファームウェアとハードウェアの取り組みは、典型的なエンタープライズソフトウェア開発とはどこか異なっており、したがってスクラムとの相性は良くないと考えられていました（1980年代のハーバード大学によるスクラムのルーツ研究は、ハードウェア製品を対象としていたので、皮肉なことです）。この視点は、MCS内の既存の「アジャイル」開発の取り組みがすべて「なんちゃってアジャイルだった」という事実によって強化されていました。

この文脈から、有用な結果を実証できる健全なスクラムチームを立ち上げるための有意義な多成分の境界を特定するために、フィーチャーチームアダプションマップを使用して段階的なLeSS採用ガイドを適用することは理にかなっていたのです。つまり、問題を解決するためのすべてのスキルを持った小さなチームが、問題を抱えた顧客と直接仕事をし、このチームが顧客の問題を反復的、適応的、漸進的に解決することの価値を実証することに意味があったということです。

私たちは、それを実証することで、さらなる「組織的な後ろ盾」を得ることを望んでいました。

• ファームウェア/ハードウェアを使ったスクラム
• 自己管理するチーム
• 顧客との協力関係の改善
• 改善された価値提供
• 文化に対する構造の影響
• コード品質の向上
• 契約ゲームの回避

パイロット版マルチコンポーネントの望ましい特性

上記のデモンストレーションの目的を達成するために、私たちは、パイロットスクラムチームが集中するためのMCS製品の適切な機能セットを特定する必要がありました。私は、製品全体の自然なLeSS Hugeリクワイアメントエリア（RA）に著しくマッピングされる、大きく分離された複数のコンポーネントのセットを特定できれば、成功の可能性が最も高くなると認識していました。(RAはコンポーネントやアーキテクチャの境界によって定義されるものではありませんが、機能的なRAと関連するコード群が大きく重なることがあり、この初期段階のケースでは、採用を単純化する上で有利であったことに留意してください）。

以下の基準は、私たちが特定しようとしていた複数のコンポーネントのグループを定義するものである。私たちは、次のようなコンポーネントのグループを求めました。

• MCSの「前面から背面へ（よりユーザに近いところからシステムのバックエンドへ）」通過するもの。
• 単一のチームの能力に適切である。
• 顧客に有意義な価値を提供する
• 成功したデリバリーは政治的・組織的に無視できなくなる
• チームがリリースの圧力から保護される可能性があるもの
• ウォーターフォール開発者の軍団による悪習を避けるために、少なくとも適度にMCSシステムの残りの部分から切り離されたコードベースがあること。

もう一つの基準として、私たちはこの基準なしでも生き残ることができましたが、次の基準も見つけることを希望していました。

• ウォーターフォールのMCSのリリースとは別にリリースできるコンポーネント群、それによって実際の顧客からのより迅速なフィードバックが得られること

パイロットスクラムチームのための適切な診断機能セットの特定

　

トレントや社内の他の人たちと熟考を重ね、良い候補のコンポーネントを見つけることができたのです。結論は？MCSの診断機能セットは、リストのすべての項目を満たすため、非常に良い選択であることが判明しました。

顧客サポートコストの大幅な節約とそれに伴う評判の向上は、政治的な援護射撃になると同時に、現場サポート部門からの熱狂的な支持を得ることができました。診断機能は、私たちの基準を満たす唯一の機能セットでしたが、その適合性は素晴らしいものでした。

診断チーム行動実績

最初の立ち上げから、人々は以前とは違う行動をとるようになりました。4～5回のスプリントの後、変化した行動には次のようなものがありました。

• 診断スクラムチーム全体とフィールドサポート部門のエンジニアとの積極的な協力関係
• 個人としてではなく、共同で作業するチーム、Sprint ごとに段階的に調整と改善を行うチーム、常に出荷可能なコンポーネントを生産するチーム、主要な利害関係者と豊かで直接的な協力関係を確立するチーム。
• フィールドサポートと別の協力部門が作成した指標に大きく影響されたマルチコンポーネントバックログの発注。これらの指標により、私たちが概念化したほとんどの診断能力について、月々の推定遅延コストを割り出すことが可能になりました。優先順位の高い診断機能で予測される節約額は、驚異的なものでした!

診断チームが技術的に達成したこと

明確かつ拡張された「Doneの定義」、効果的なスクラムイベント、少量の技術コーチング、そして契約ゲームの回避が組み合わさり、技術的な実践に大きな違いを生み出したのです。

4～5回のスプリントの間に、以下のことが容易に観察できるようになりました。

• 診断スクラムチームが触れたMCSのC++とPythonのコードのあらゆる部分において、ユニットテストが自動化された。
• 自動化されたユニットテストは、診断に特化したコードとMCSコードベース全体の一部に対して、より良く作られた、より問題の少ないコードのための強制機能として作用していました。
• MCS システムのために、以前より改善された、より広範な自動化された統合テストの積極的な開発。

診断チームの立ち上げのステップ

成功には何の不思議もなかった。手順は以下の通りです。

• チームをサポートし導くことに貢献する人格を特定するために、LeSSガイド　Temp_orary_Fake Product Owner を診断用マルチコンポーネントに適用し、彼の決定が様々な利害関係者によって尊重されるために十分な地位と政治的影響力を持つ人物としました。
• この人物は、社内の他者から指示された要件をこなし、マイルストーンに準拠する「契約ゲーム」をまだ行わなければならないため、「偽の」プロダクトオーナーとなりました。
• 必要な様々なMCSサブシステムを横断して作業するために必要な（または学んだ）すべてのソフトウェアとテストエンジニアリングのスキルを持つ8人のメンバーの開発チームを組み立てました。
• 開発チームの共同作業スペースとして使用するために、中規模の会議室をフルタイムで所有した。
• スクラムチームの全メンバーと主要なステークホルダーのために、数日間の正式なクラスルームトレーニングを提供しました。
• 数日間に渡る専用ミーティングと、様々な事前ミーティングやフォローアップミーティングから成る、共同憲章作成作業を実施。これにより、ステークホルダーとスクラムチームメンバーとの間で、全体的な整合性をとることができました。
• 私は、最初の数スプリントの間、経営陣、プロセス、技術的なコーチングを積極的に行い、その後、MCS部門のBIOSグループにおけるLeSS指向の導入に力を注ぎました。

大規模スクラムの「はじめに」ガイドを参照してください。チームの立ち上げに関する追加のガイダンスについては、『大規模スクラム：LeSSでさらに進化する』の_Getting Starting_ガイドを参照してください。LeSS 構造の中で複数のチームを立ち上げるという観点から書かれていますが、1 つのパイロットスクラムチームを立ち上げる場合にも同じように適用できます。

診断チームの写真とアーティファクト

診断チーム文化的関連要素

試験的な取り組みに関するいくつかの文化的観察を以下に列挙する。これらの文化的観察の多くは、BIOSグループにおけるその後のLeSS指向の採用のより良い理解にも関連するものである。

ラーマンの組織行動第一法則と第五法則の発現{#manifestation-of-larmans-first and-fifth-laws-of-organizational-behavior｝

ラーマンの組織行動の法則の第一法則と第五法則は、以下の通りです。

• 組織は、暗黙のうちに、現状維持の中間・第一レベルのマネージャーと「専門家」の地位・権力構造を変更しないように最適化されている。
  **(大きく確立された組織で) 文化は構造に従う。そして、小さな若い組織・会社では、構造は文化に従う。

ラーマンの組織行動の法則の全5項目は、LeSSのウェブサイトの構造のページhttps://less.works/less/structure/indexで見ることができます。

小規模な診断パイロットスクラムチーム内でも、第一法則と第五法則が明確に表れていた。効果的な構造とその結果としての文化におけるポジティブな変化は、診断チームと、診断チームが積極的に協力するステークホルダーに限られたものであった。一方、中間管理職層の大部分では、現状がほとんど変化していなかった。

診断チームが拡大した構成要素の境界は、MCSシステム内の多くの異なる構成要素にまたがるものであった。これらのコンポーネントには、通常、エンジニアと地域ごとのマネージャーがおり、2人の副社長のうちの1人にロールアップされていた。診断開発チームは、各マネージャーが関連するコンポーネントの知識を持つソフトウェアエンジニアやテストエンジニアを完全に配置することで結成されました。ウォーターフォール開発における納期のプレッシャーを考えると、マネージャー達は診断チームに人を割り当てることにとても抵抗がありました。最終的には、シニアバイスプレジデントの意向でそうすることになりました。

スクラムチームが稼動してからは、政治的な圧力とシニアバイスプレジデントからの正式な指示により、ファーストレベルとセカンドレベルのマネージャーは、診断開発チームの個々のメンバーに関係のない仕事をさせることをやめました。開発チームのメンバーの中には、いくつかの問題を解決するために、最終的に診断作業に関連するマネージャーの下に正式に配属されなければならない者もいました。

Larmanの組織行動の法則が予言するように、スクラム開発チームメンバーが、MCS製品全体からの納期プレッシャーに同時にさらされるエンジニアリングマネージャーに報告することは、非常に問題であった。副社長が協力することでこの問題は軽減されたが、組織図が完全にフラット化されることはなかった。開発チームのメンバーの多くは、この変更を完全に受け入れることなく、副社長の1人を通じて報告を続けていました。唯一の変更は、診断スクラム開発チームのメンバーの一部を、どのディレクターが担当するかということでした。

LeSSブックガイダンスとの対照表

一見したところ、この診断パイロットは、LeSSの3冊目の本である「大規模スクラム」の中の「並列組織」ガイドと一致している。しかし、残念なことに、少なくとも2つの重大な相違点がある。

LarmanとVoddeは、並列組織戦略について説明する際に、いくつかの注意点を挙げています。最初に挙げられている注意点は

並列組織はお試しではなく、組織の報告系統を従来の組織とは別にする必要があります。

診断チームの有効なチームレベルの構造を抜本的に変更し、スクラムに合わせたが、正式な組織の報告関係は残ったままであった。この失敗により、チームは経営層の変化に対して過度に脆弱になった。

診断チームは契約ゲームの対象外であったにもかかわらず、診断チームのメンバーは、ウォーターフォールの取り組み全体の契約ゲームに従事していた中間管理職を通じて、報告を行った。中間管理職は、ウォーターフォールのリリースを控え、より多くの開発能力を求めるようになると、個々の診断チームメンバーの努力を方向転換させるという、以前のような行動を取るようになりました。当初のエンジニア SVP/GM は、このような機能不全から診断チームを積極的に守っていましたが、彼が去るとすぐに、診断チームの初期の成功を可能にした支援的な状況が徐々に侵食され始めました。

第二の違いは、診断チームが、いずれ並列組織を形成することになる多くのチームの第一陣としてではなく、スターチームとして捉えられていたことである。言い換えれば、この診断チームは、MCSのすべての開発をLeSS指向の構造にゆっくりと移行させるという上級管理職によるコミットメントされた集団的決定を実行するための最初のステップとは見なされていなかったのです。

関連文献

LeSS 規則の最新版は、LeSS ウェブサイトに掲載されています。https://less.works/less/rules/index

以下のLeSSルールは特に関連性が高いと思われます。

• “LeSSのルール。プロダクトグループについては、LeSSの完全な構造を「最初に」確立すること。”

1つのチームしか設立されていないため、明らかに達成できていません。診断チームレベルの構造は最初からできていたのですが、診断チームに関連する報告関係の変更と組織図のフラット化ができていなかったのです。

大規模スクラム。More with Less では、以下の関連ガイドを提供しています。

ガイド チームベースの組織を構築する。このガイドでは、動的なマトリックス構造よりも安定した組織を持つことに特に重点を置いています。

• ガイド LeSSの組織構造。以下の引用が含まれています。”LeSSの組織にはマトリックス構造はなく、点線の管理者は存在しない”
• ガイド フィーチャーチームsへの移行: 様々な移行戦略のハイレベルな概観を提供します。
• ガイド 一度に1つの要件領域。LeSSの大規模な導入のための段階的なアプローチについて説明しています。
• ガイド: 並列組織: 採用戦略として、別組織を作ることについて詳しく説明しています。特に、記載されている注意点は洞察に富んでいます。
• ガイド: フィーチャー・チーム採用マップ: 図4で示されるように、フィーチャーチームの責任が徐々に拡大する様子を可視化するための、より深い洞察を提供します。
• ガイド: フィーチャーチームの採用マップ Done の定義を進化させる_: Done の定義を使用して、どのように漸進的な改善と様々な利害関係者との関連性をより明確に可視化できるかを説明します。
• ガイド 始め方:個々のチームの立ち上げにも、複数のチームの立ち上げにも、同じように適用できます。

エグゼクティブレイヤーの交代を振り返って

エグゼクティブレイヤーの変更に関する考察。新しいSVPは、彼なりに非常に優秀で、技術的にもそこそこ精通していましたが、後任の短期間のチーフエンジニアスタイルのSVPのような技術的な見識に欠けていたのです。

SVPの下にいる既存の上級管理職は、優れたソフトウェアエンジニアリングの実践を行う適切なアジャイルチームのようなものに実際に触れる機会がありませんでした。そのような経験を積んでいない限り、さらなる変革への支持を得ることは困難だった。

契約ゲームの回避に失敗し、現状維持の権力構造を自己防衛しようとしたため、多くの人が時間をかけて行われた改善を評価し、受け入れることは困難だった。これは、前述した「ラーマンの組織行動の法則」の第一法則が予言する通りである。

もし、当時の私に知恵と技術があり、「Certified LeSS for Executives」コースのような、シニアマネジメントが変化を借りるのではなく、自分のものにすることに焦点を当てたエグゼクティブワークショップを実施する必要性を認識していたら、事態は違っていたかもしれないのです。 もし、私がまだ元のSVPのサポートを受けていた時にこの方法をとっていたら、元のSVPは、部門レイヤーの上に作用する政治的な力を乗り越えて、十分に思い切った変化を起こしていると見なされたかもしれません。

何はともあれ、インフォームド・コンセントのワークショップと組み合わせたエグゼクティブ・ワークショップは、ソフトウェアVPによる受動的攻撃的な行動を浮き彫りにするのに役立ったかもしれません。

持続可能な文化の変革に必要な組織の構造的変化の大きさをより強く認識させることは、せっかく実現した漸進的な成果をあげる前に、改善の努力を止めてしまう危険性がある。しかし、このような経営者向けワークショップの後、元のSVPがLeSS指向の採用に積極的であったなら、採用活動を覆すことはさらに困難だったでしょう。

新しいSVPが現れた時には、大規模なレイオフと多くの有意義な改善の破壊につながる賽は既に投げられていたのです。私はまだそれを知らなかっただけで、あと1年は知らないでしょう。

しかし、このとき達成された成果には、大きな意味がありました。パイロット診断チームが導入した診断機能は、数百万ドルのコスト削減を実現し続けています。レガシーの組織構造では、同等の品質の診断機能を実現することは不可能だったでしょう。BIOS の生産コード、BIOS テストインフラ、BIOS チーム内の組織的規範の多くの改善によるさらに大きな好影響は、完全に元に戻すにはあまりに大きな勢いを得ました。

啓蒙された人々は、二度と同じ世界を見ることはない。同様に、量産製品のコードに組み込まれた改良も、何十年も続く傾向がある。

BIOS管理への関心

診断スクラムチームが軌道に乗り始めると、私はMCSの分野で別の分野に注力することを模索し始めました。私は再びトレントの組織力学の知識を活用しました。前回同様、経営陣のサポートが十分に得られる分野に焦点を当てながら、徐々にフィーチャーチームに移行していこうと考えていました。スクラムチームの診断の効果を考えると、もう少し広い範囲での取り組みが可能になってきた。とはいえ、コーチはまだ私一人でしたし、当時はコーチング能力を追加するための十分な資金もありませんでした。

ミーチャというディレクターがいたのですが、彼は当初はやや懐疑的だったものの、どんなメリットがあるのかに興味を示してくれました。数週間かけて、私はミーチャの考えをさらに深めることができました。その際、ミーチャの仲間であるクリシュナ・ミシュラという人物が協力してくれました。クリシュナは、診断パイロット・スクラム・チームの活動で重要な役割を果たしました。また、クリシュナは、ミーチャのグループと頻繁に交流しているエンジニアのグループを管理していました。

ミーチャのグループは、MCS用にカスタマイズされたBIOSを提供する役割を担っていた。BIOSは、起動時に計算ノード（ブレード）のハードウェアを初期化するためのファームウェアです。また、MCS内のコンピュート・ノードで稼働しているどのOSに対しても、ランタイムサービスを提供します。MCSや競合製品の場合、カスタムBIOSは、ハードウェアに物理的にアクセスすることなく、各ノードのハードウェア設定をリモートで管理することを可能にする一部である。ハードウェアが遠く離れた、人手の少ないサーバーファームにあることを考えると、このアクセスは特に重要です。

BIOS概要

カスタムBIOSコードは、MCSシステム全体の中で最も困難で専門的なソフトウェア開発の側面であったと言えるでしょう。残りのシステムの多くは、成熟したチップセット上で動作するC++、Java、Pythonミドルウェアで構成され、専用のアプライアンスハードウェア上でストリップダウンしたLinuxオペレーティングシステム内で実行されました。これらのシステムの中には、低消費電力やメモリの制約を受けるものもありましたが、BIOSエンジニアが対処しなければならないことに比べれば、大したことではありません。それにもかかわらず、経営陣が最も改革・改良に意欲的だったのがBIOSグループだったのです。

ナカシマでは、インテル社のプロセッサーのリリースに合わせて、カスタムBIOSのリリースを迅速に行うことが、市場からの要求に応えることでした。AMIがBIOSファームウェアのベースを提供していたとしても、歴史的にエンジニアリングのやり方が悪く、部門横断的なマルチラーニングチームがなかったため、インテルの最新情報を得るためには、40人以上の高度に専門化したハードウェア、ソフトウェア、テストエンジニアがカスタムMCS BIOSに取り組む必要がありました。

BIOSのメジャーリリースはMCSの全体的なリリースに対応する傾向がありましたが、より小さな独立したBIOSのリリースも時折行われます。独立した小規模なリリースは、通常、インテルハードウェアのマイナーリビジョンや、カスタムMCS BIOSのベースとなるAMIコードベースのマイナーアップデートによって動機づけられています。

BIOS管理レポートライン内の変更に対する熱意と、ソフトウェアVPからの不十分なサポートを考慮すると、賢明なことは、ハードウェアVPと品質保証VPの影響力の範囲内で、可能性の芸術を追及することでした。私たちは、カスタムBIOSだけに限定してコンポーネントの境界を定義し、BIOSチームが成熟するにつれて徐々に境界を広げていくことにしました。

マクロレベルではBIOSはMCSシステム全体の1コンポーネントに過ぎないが、ミクロレベルではLeSS指向の構造のあらゆる部分が完全に関連性を保っている。BIOSのコンポーネント自体は、このドキュメントの範囲外である非常に大きなサブコンポーネントのセットで構成されています。

MCS部門には、数千人のエンジニアがおり、全員がMCS製品の様々な側面に集中しています。BIOSコンポーネントチームの範囲内でエンジニアリングプラクティスとクロストレーニングを改善する前に、BIOSマルチコンポーネントの境界を拡大することから始めるのは問題があったでしょう。MCS全体のエンジニアリング手法は、長年のコントラクトゲームから予想されるように、比較的ひどいものであった。最初のBIOSコンポーネントの境界内には、品質の問題とエンジニアリングのサイロ化が十分すぎるほど存在し、私たちが提供できるコーチングの焦点をすべて消費していました。

LeSSでは、https://less.works/less/adoption/coachingで説明されているように、3つのレベル（組織、チーム、技術）でコーチングを行うようアドバイスしており、私はその3つをすべてカバーしていました。私はTrentがベンガルールで何人かのコーチを面接し採用するのを手伝いましたが、MCS部門が西半球で持つ唯一のアジャイルコーチは私だったのです。もし、私が在籍していた最初の2ヶ月半の間に、最初のエンジニアリングSVP/GMを失っていなければ、コーチング能力の状況はおそらく違っていたでしょう。新しいエンジニアリングSVP/GMは部門の縮小を考えており、アジャイル採用の取り組みを十分に理解していなかったので、私たちは幸運にもコーチング能力を持つことができました。

BIOS ボトムアップからの拡張

LeSSでは以下のように説明されています。

LeSS Hugeの採用には、おおよそ2つのアプローチがあります。

1) 一度に1つの要件領域を採用する

2) チームの作業範囲、Doneの定義、プロダクトの定義を徐々に拡大する。

— https://less.works/less/less-huge/huge-adoption_

私たちは、1つ目のアプローチではありますが、2つ目のアプローチに従いました。当時は、1つの要件エリアが、よりインパクトのある組織改革を意味したのでしょう。

BIOSのLeSS指向の採用は、製品全体に焦点を当てた顧客中心主義という原則に直接起因するものではありませんでした。むしろ、LeSS指向の構造の仕組みは、BIOSチームが直面していた透明性、調整、品質の問題の多くを解決するためのソリューションと見なされた。

BIOSのマルチコンポーネント境界を拡大し、MCS製品の自然な機能セットと一致させるように努力することの利点は、当初BIOSチームや経営陣にとって明確ではなかったが、時間の経過とともにそうなっていった。BIOSチーム以外の依存関係に対処することで生じる障害の透明性の向上、効果的なレトロスペクティブの結果、各新スプリントで有意義な実験ができたこと、そして私自身が継続的に指導したことなど、さまざまな要因によって意識の高まりがもたらされたのです。詳細は、後述の_BIOS Component Boundary Expands_のセクションに記載されています。

奇妙なことに、LeSSチームの拡大したマルチコンポーネント境界は、製品アーキテクチャ全体の難解なコンポーネントの奥深くから始まり、その後、ユーザーインターフェースに向かってゆっくりと拡大していきました。これは、LeSSの採用が始まる場所としては珍しく、理想的とは言えませんが、経営陣の賛同と変化への関心が見出された場所でした。たとえ理想的とは言えないスタート地点であっても、チームの創造的な可能性を引き出すだけで、どれだけのことが成し遂げられるか、驚くべきことなのです。

BIOSチームの中間で

新しく結成されたBIOSチームにふさわしい形容詞を選ぶのは、ちょっと難しいですね。

新しく結成されたBIOSチームは、レガシーBIOSチームよりもはるかに多くのクロスファンクショナルでした。各チームは、BIOSの変更に対して責任と権限を持ち、エンドツーエンドのテストを行うことができました。

新しく結成されたBIOSチームは、最初からセルフマネージメントと共同ロケーションを採用していました。しかし、レイオフやその他の組織変更により、ミーチャと私が意図したほどには**長続きはしませんでしたが。

大規模スクラムの_フィーチャーチーム Adoption Maps_ガイドには、チームを説明するための有用な定義がいくつかあります。そのうちの2つを紹介します。

新しく構成されたBIOSチームは、結成当初から「拡張コンポーネントチーム」として活動することが可能でした。彼らは、自分たちが行ったあらゆる変更について、エンドツーエンドのテストを行う能力と責任を持っていました。そのテストは、MCS GUI（そのコードは書いていない）から、シャーシコントローラ（そのコードは書いていない）、ノードコントローラ（そのコードは書いていない）を経て、最終的にIntel CPU上で動作するBIOSコードに至るまで拡張された。一方、新しく構成されたBIOSチームのコーディングは、当初は図8で説明した「Initial BIOS Component Boundary」内だけであった。これは、「拡張コンポーネントチーム」の定義と完全に一致することがおわかりいただけるだろう。

新しく構成されたBIOSチームは、当初はフィーチャーチームの定義に合致しなかった。フィーチャー・チームになるには、関連するすべてのコードをフロントからバックまで含める必要があります。私がナカシマMCSに在籍していた頃は、BIOSチームがこれを達成することはなかったが、少しずつ前進していた。

新体制のBIOSチームをまとめると

1. 拡張コンポーネントチームとしてスタートし、セルフマネジメントと共同ロケーションを実現。
2. 1. BIOSコンポーネントとMCS GUIコンポーネントの間の通信経路に沿ったより多くのコンポーネントをカバーするために、コンポーネント拡張チームとなることを目指した。
3. エンドツーエンドの機能を提供するために必要な「すべて」に責任を拡大し、「フィーチャーチーム」になることを計画した。

BIOSの組織的な背景

BIOSのLeSS指向の採用は、役員層の入れ替わりが激しい時期に行われました。BIOSの採用が始まったとき、すべてのハードウェア開発を担当する副社長が非常に協力的で、組織全体の他の様々な副社長も同様だった。これは、最初の採用活動を可能にし、短期的に成功させるのに十分であった。しかし、SVPや副社長クラスの経営陣が交代すると、私たちの努力は関係者の多くから成功したと認められていたにもかかわらず、必要なサポートの多くを失ってしまったのです。新しいSVPが両義的な態度をとり、ハードウェア担当のVPを失い、さらに大規模なレイオフが行われたため、最終的に我々の努力は水の泡となりました。次の一連の組織図が、このような状況を浮き彫りにしています。

BIOS コンポーネントの境界（バウンダリー）と地層

歴史的な理由により、ハードウェアの世代が変わるたびに、BIOSのコードベースが完全に分離され、共通機能を再利用可能なサブコンポーネントにほとんど集約されないという現実がありました。

興味深いことに、これはBIOSチームをより持続可能なペースで成長させる機会を提供するものであった。以前は関与していなかったBIOS開発者が、以前の生産ハードウェア世代に関連する不具合の解消に取り組み始めると、LeSS指向の構造内で、さらに機能横断的なチームを結成することになりました。BIOSコードベースのダイナミクスとAMIとの関係については、さらに詳しく説明します。

このようにして、ミーチャを通して報告する米国に拠点を置く人々と機能横断的なBIOSチームを立ち上げるのに半年間の猶予を得た後、インドのBIOS開発者と管理者をより積極的に巻き込む必要が出てきました。インドのBIOSエンジニアが米国のBIOSエンジニアと同じBIOSコードベースで作業を始める頃には、米国のBIOSエンジニアは、まだ機能横断的なBIOSチームに入っていないインドのBIOSエンジニアが同じ改善された品質基準を満たさない場合に、反発できるほど結束していたのです。

最初の苦労は、インドに拠点を置くBIOSエンジニアが、クリーンなビルドと基本的なスモークテストをパスしない限り、コードをチェックインしないように注意する、というような単純なものであることが多かった。追加の自動テストと、機能横断的な BIOS チームの直接管理下にあるプライベート CI サーバーは、改善された品質基準に従わない開発者によって問題が発生した場合に、米国ベースのチームがそれを検出するのに役立ちました。

機能横断的なBIOSチームの成功により、ミーチャと私は、根本的な構造的問題の解決に着手するための政治的立場をより強固なものにすることができたのです。ミーチャは、プロジェクトマネジメントSVPの要請で、機能横断的なBIOSチームの改善についてナカシマ全体にプレゼンテーションを行っていました。

インドにいるBIOSチームへの解決策は、機能横断的なBIOSチームを1つまたは2つ追加することだった。理想を言えば、こうした構造的な問題はすべて最初から解決しておきたかったのですが、当時はまだ政治的に実現可能ではありませんでした。その代わりに、私たちは実現可能なことをしたのです。私たちは、将来的に政治的な勝利が得られるよう、意図的に問題を分離し、遅らせたのです。私たちは、2つの別々の運営モデルから生じる摩擦を予期していただけでなく、将来的に意味のある構造改革を政治的に実現するために、それを当てにしていたのです。

ミーチャと私は、インドに行く準備をし、政治的な解決に乗り出そうとしていました。もしハードウェア担当副社長が残っていたら、BIOSコンポーネントという境界の中で、より差し迫った政治的課題を解決することができたと思うのです。すでにインドにいるBIOSマネージャーを味方につけていましたが、ディレクター層でいくつかの問題を解決する必要がありました。

コードベースを分けることによる弊害

新しい世代のハードウェアが出るたびに、まったく別のBIOSコードベースを持つというのは、いいことではありません。私たちはその事実をうまく利用しましたが、望ましいこととは程遠かったのです。

コピーペーストの再利用があまりにも多く、開発者が自信を持って後方互換性のある変更を行えるようにするための自動テストカバレッジが不十分で、AMIコードベースの変更からMCS関連の変更を分離するためにAMIプラグインレイヤーを使用することに失敗していたのです。

このような自業自得の負担により、インテル® CPUの変更に対応することは、他の方法よりもはるかに困難なものとなりました。皮肉なことに、インテルのCPUの変更に対応する能力は、インテルのリリースサイクルよりも速く、MCS部門の収益と市場シェアを維持するために非常に重要である。

これらの問題を解決するための努力は、後述する「BIOSの定義」の項で見ることができる。

BIOS 地理的に分散したチーム

グローバルに最高レベルの価値を提供するために、最高レベルの適応性を最適化するという観点からは、これほど多くのエンジニアが製品に携わることはなかったはずだ。また、エンジニアが複数の場所やタイムゾーンに散らばっていることについても同じことが言える。しかし、最初からそうであったのだから、そうでないことを納得させようとしても、うまくいくはずはない。

Intelの発売日に間に合わせるという重要性と、レガシーコードベースにある膨大な量のコピーペーストの再利用が相まって、困難な状況を作り出していたのです。米国に拠点を置くBIOSチームのメンバーのほとんどが力を合わせなければ、必要な変更を時間内に行うことができず、また、この状況を引き起こした不十分なエンジニアリング手法に対処しながら行うには、十分な知識を結集させることができなかったでしょう。それに対して、まったく異なるタイムゾーンにある別の地域を追加することは、事態を遅らせるだけである。

LeSSの本からいくつかの異なる引用が、この点を強調するのに役立ちます。

LeSSの本からのさまざまな引用は、この点を強調するのに役立つ： >優れた人々の小さなグループから始め、それが本当に苦痛になり始めたときだけ成長する。それはめったに起こらない。

多くの人が必要かどうかを議論するのではなく、アジャイルとリーンの原則で開発を改善することを支援するようにします。

品質保証グループという名前が最悪だ

品質とは、後付けできるものではないことを認識することが重要です。なぜか？製品の品質は、製品開発システム全体の成果であり、品質管理部門が個別に責任を負うものではありません。テストグループの正式名称は「品質保証」だが、より正確には「品質管理」というべきだろう。

品質保証の正しい使い方は、テストファーストまたはテスト駆動開発の確立、効果的なコードレビューの実践、静的コード解析ツールの設置、継続的インテグレーション行動の確立、ペアリングまたはスワーミング行動の確立などの活動を指すものです。これらのプラクティスは、ソフトウェア開発が「コードコンプリート」とみなされた後に品質をボルトで固定しようとか、その他のナンセンスなこととは一切関係がないことに注意してください。

品質保証グループは、実にお粗末な名前であった。その名前からして、高品質な製品を開発するためのメンタルモデルが崩れていることがわかります。しかし、歴史的な正確さを期すために、私はレガシー構造の中ですべてのテスターを含む組織ブランチをQAグループと呼び続けることにします。このドキュメントを読むときは、この区別を覚えておいてください。

BIOSテスターがもたらしたエンドツーエンドの知識

MCSの幅広さと複雑さ、そして過剰な専門性の歴史は、それまでレガシー構造の中でエンドツーエンドのテ ストにほとんどの時間を費やしていたテスターほど、エンドツーエンド製品を理解している人がいないことを意味し ていました。その結果、テスターは、従来のBIOSファームウェア開発者と同じように、それぞれのBIOSチームに価値をもたらすことになったのです。

テスト出身のBIOSチームメンバーは、品質保証担当副社長を通じて、正式な報告を行っていた。彼女のサポートと関連するQAディレクターのサポートは、BIOSチーム内での事実上の平等を可能にするために重要であった。この正式な報告関係の維持は、BIOSのLeSS指向のチームが生み出す品質の抜本的な改善を組織として受け入れてもらうために有効であった。

テスターのために別の報告構造を維持することは、組織的な脆弱性をもたらしました。品質保証担当副社長の役割が変われば、起きているポジティブな変化の多くを簡単に解きほぐしてしまう可能性がある。長期的な目標として、組織構造における正式なテスト特有の区別をなくすことは、テストの経歴を持つチームメンバーが、そのチームのスプリントバックログとは無関係の仕事に気を取られるリスクを回避するのに役立つだろう。

リーン＆アジャイル開発の規模拡大のための実践」の第3章では、実践と戦略の両レベルでテストに最も適したアプローチを行う方法について包括的に扱っています。

## 拡張BIOSマルチコンポーネントの目標と制約

電子メール、ホワイトボードの走り書き、口頭での会話以外に正式に文書化されたことはありませんが、BIOS LeSS採用の目標には以下が含まれます。

• MCSハードウェアの将来の変更にMCS BIOSを適応させる能力を向上させ、特にIntelチップセットへの定期的な更新を行う。
• 技術的な卓越性を評価し、「契約ゲーム」によって生じる非生産的なストレスを回避する文化を創造する。

最新のインテル製チップセットのBIOSサポートは、MCS製品と競合他社の製品との差別化の重要なポイントになることはほとんどありませんが、インテルのリリースイベント時に同等でなければ、一晩で市場シェアと収益を大幅に減少させることになります。このことは、経営陣もよく理解していた。そのため、次のような制約が重要であった。

• BIOSのアジャイルな採用努力が、MCS製品がIntel CPUの製品版をサポートできない理由となることは、決して許されない。

その結果、BIOSの適応性の目標は、ミーチャのように上級管理職の頭の中にあるわけではなかったが、その目標の重要性は暗黙のうちによく理解され評価されていた。

このような共通認識にもかかわらず、従来のレガシー・ウォーターフォール・アプローチの機能不全の程度は、広く受け入れられてはいなかった。コントラクトゲーム」、「お粗末なエンジニアリング手法」、「過剰な専門化」などは、部門全体で観察することができた。

上記の目標について考えてみると、「大規模スクラム」で述べた「組織的完璧性ビジョン」のガイドにあるLeSS完璧性ビジョンと非常に強く共鳴していることに気づくでしょう。また、そのガイドにある、ローカルな最適化と本当のシステム改善を見分けるための2つの質問とも強く共鳴していることがわかるでしょう。

上記の目標をサポートするBIOSグループ内の目標には、以下のようなものがありました。

• Establish a single BIOS-コンポーネントバックログ, to make the highest-value BIOS work more visible. Baby steps towards a single product-level backlog.
• Expand the knowledge and skills of each engineer to encompass a broader portion of the product, thereby improving the adaptiveness of each team and the overall ability to switch to and then focus on newly-discovered highest-value work.
• Increased “whole product focus” (a LeSS principle) by each BIOS team while transitioning towards an expanded BIOS multi-component boundary spanning a greater portion of MCS.
• Work to improve the craftsmanship practices around the MCS BIOS component.

• Avoid the Contract Game as much as possible.

• 最も価値の高いBIOSの作業をより見えるようにするため、単一のBIOSコンポーネントバックログを確立する。単一の製品レベルのバックログに向けたベイビーステップ。
• 各エンジニアの知識とスキルを拡大し、製品のより広い部分を網羅することで、各チームの適応性を高め、新たに発見された最も価値の高い作業に切り替えて集中する全体的な能力を向上させることができます。
  *各 BIOS チームによる「製品全体への注力」（LeSS の原則）を強化し、MCS の大部分にまたがる拡張 BIOS マルチコンポーネント境界に向かって移行しています。
• MCS BIOS コンポーネント周辺の職人技の実践を改善するよう努力する。
• コントラクトゲームを可能な限り回避する。

BIOS Adoption Story in Diagrams Alone

ダイアグラムだけでわかるBIOS採用ストーリー

タイムライン図、コンポーネント境界図、機能採用マップ、組織図、ハードウェア世代別機能チーム拡大図とそれぞれの図のキャプションを合わせて、ストーリーアーチの全体像を理解するのに十分な文脈を得ることができます。

BIOSエンジニアリングと文化的課題

MCSの中でカスタマイズBIOSシステムが果たす役割について、大まかな理解が得られたと思います。ここでは、BIOSチームが直面する技術的・文化的な課題について、深入りしないようにまとめたいと思います。もし、この内容が気になるようであれば、読み飛ばしていただいて結構です。

### AMIはBIOSコードの基礎を提供した

MCS計算ノードのカスタムBIOSは、AMI社からライセンスされた常に更新されるコードベースを修正することで作成されました。AMI が BIOS コードベースの継続的な変更を行う典型的なイベントには、以下のものがあります。

• Intel が、プロトタイプのチップセットやリファレンスボードの設計において、ハードウェアとファームウェアのインターフェイスの一部を変更した場合。
• AMIは、プロトタイプのインテル製チップセットまたはリファレンスボード設計の改良された機能によって実現される、新しいBIOS機能のサポートを追加します。
• AMI またはライセンスパートナーの 1 社が特定したバグを修正する。
• AMI が理にかなった理由で BIOS コードベースを変更することを決定した場合。

MCS BIOSカスタマイズとAMIコードベース間のインターフェイスがほぼ安定しているため、これらの通常のAMIアップデートの影響は最小化されるでしょう。しかし、実際にはそうではありませんでした。AMIコードベースとの正式なプラグインは存在するものの、ナカシマのBIOSカスタマイズのほとんどは、歴史的にAMIコードベースの奥深くで行われてきたのである。

MCSのBIOSエンジニアは、新しいチップセットを作るたびに、古いチップセットのBIOSバージョンに合わせたカスタマイズから、新しいプロトタイプチップセット用のコードに機能をコピーすることを試みた。同様に、MCSのBIOSエンジニアは、AMIのコード変更を常に把握し、それらをアクティブなワーキングブランチにマージし、手作業で再テストを行う。テストには、ラボでの実作業が必要なものもあったが、これまでよりもはるかに多くのテストを自動化することが可能であった。

デスマーチ文化はインテル・リリースに支えられている

市場の流れは、インテルのチップセット発売日に支配されています。ハードウェアインテグレーターは、プロトタイプチップセットとリファレンスボードアーキテクチャにいち早くアクセスすることができます。インテルのリリース日に合わせて出荷する能力は、市場で生き残るために不可欠です。

インテルの仕様変更に対応できるように最適化することが、組織設計上の賢明な判断であった。しかし、残念なことに、従来の組織の対応は、問題に大量の人員を投入し、リリース日に向けてデスマーチすることでした。そのため、発売日が迫ってくると、どうしても品質が犠牲になってしまうのである。

### ナカシマMCSの知の喪失

ナカシマのMCSを構成するパーツを最初に作った人たちの多くは、何年もかけてナカシマを去っていった。そのような人たちは、部族の知識も一緒に出て行ってしまったのです。理想は、テストピラミッドの全レベルで広範な自動テストが行われ、よく練られた読みやすいコードが存在することです。最低でも、システム全体のアーキテクチャを詳細に説明する有用な文書があるはずです。ウォーターフォール文化の納期のプレッシャーの中で開発された複雑な製品に期待されるように、これらのものはほとんど存在しませんでした。

### Intel BIOSは高度に専門化されている

AMIは、BIOSのカスタマイズに精通したエンジニアは、世界中に数千人しかいないと見積もっています。x86ハードウェアファームウェアインターフェースの動作やデファクト仕様の多くは、PC革命の初期に遡る部族的知識を必要とします。

実際には、MCS BIOSの各カスタマイズ領域は、1人または2人のエンジニアがAMIコードベースを深く掘り下げ、そこで見つけたものをリバースエンジニアリングした結果です。ある意味、これはプロのソフトウェアエンジニアが一日かけて行うことと変わりませんが、違いは、BIOS開発において、これがいかに難解で頻繁であるかということです。

3つの地域にまたがる多数の技術者

40人ほどの技術者が忙しく働けるほどの仕事量である。職人技を磨けば、最終的にはもっと少ない人数で済むはずだ。とはいえ、自業自得の技術的な問題から脱却するには、膨大な作業と調整が必要だった。

歴史的な理由により、BIOSにフォーカスしたソフトウェア、ハードウェア、テストエンジニアが、ポートランド、サンフランシスコ、ベンガルールといった大都市に散らばっていました。チームの規模を拡大する計画では、この分散問題を解決しなければなりません。幸いなことに、私たちは同じ場所にいるチームに自己組織化することができました。さらに、ベンガルールで行われている作業は、ポートランドやサンフランシスコでの作業からある程度独立していました。

大きな技術的課題

MCS BIOSチームが直面した課題の多くは、自ら招いたものでしたが、いくつかは、仕事そのものに内在するものでした。それらは以下の通りです。

• プロトタイプのチップセットとボードに対するハードウェアのアップデートは定期的に行われます。新しいボードデザインの製作にかかるリードタイムは、通常6週間程度でした。これは、物理的な問題ではなく、組織的な障害であると言えるかもしれません。
• プロトタイプのチップセットは、ファームウェアと同じように問題の原因となる可能性が高かったのです。その結果、テストとトラブルシューティングの重要な側面は、研究室での実地作業を必要としました。
• x86 BIOSツールチェーンは、非常に古く、使いにくいものです。これは、AMIがツールを改善するために大きな投資をする経済的動機が不十分であったためです。
• 自動ユニットテストのようなソフトウェアエンジニアリングの実践は、世界全体のx86 BIOS開発文化の中で一般的に欠けています。この文化的な歴史は、MCS BIOSチームがカスタマイズしたAMIコードベースでもはっきりと観察することができた。このため、以下のような複雑な問題が発生しました。
• 単体テストツールは、すべて手作業で行う必要がありました。
  ユニットテストのツールはすべて手作業で行わなければならなかった。 + AMI BIOSコードベースに効果的な依存関係逆転メカニズムを組み込むことは、通常のJavaやC#フレームワークで行うよりもはるかに困難だった。
• 書籍、記事、フォーラムの投稿、サンプルコード、その他のリソースで、BIOSコンテキストでのユニットテストのガイダンスを提供するものがなかった。
• 自動ユニットテストのコンセプトはもちろん、テストファーストやTDDの実践も、MCS BIOSエンジニアにとって完全に異質なものでした。
• 低レベルファームウェア開発の世界では、すべてが平均的なソフトウェア開発の努力よりも退屈である。MCS BIOSに関連するいくつかの例を挙げよう。
• オペレーティングシステムが存在しないため、オペレーティングシステムサービスが存在しない。
• コードがクロスコンパイルされ、その後ターゲットにフラッシュされなければならない。
• BIOSブートプロセスの初期段階では、TCP/IPネットワークスタックが存在しないため、ターゲットとの通信が特に困難である。ターゲットデバイスとの初期の通信は、シリアルポート通信と同様の制約のあるメカニズムに限られていました。
• ファームウェア開発エンジニアの多くは、ソフトウェア工学の専門知識よりもマイクロエレクトロニクス工学の専門知識を持つ人が多い傾向にあります。

ここに挙げた問題は、いずれも克服できないものではありません。多くの場合、大規模な Web アプリケーション開発など、他の領域の技術が、これらの問題の多く を解決するためのヒントを既に与えてくれています。

例えば、JavaとC#はどちらも洗練された依存性注入フレームワークを持っており、既製品として利用することができます。James Grenningによる_Test Driven Development for Embedded C_は、これらの技術の相互提供を改善する試みの一例である。

BIOS採用の取り組み

ミーチャと私は、自分たちの取り組みが大変なものであることに気づきました。BIOS機能チームの立ち上げ、立ち上げ、成熟化の手順は、診断チームで行ったこととほぼ同じでした。主な違いは、課題の難易度と規模です。

大きな違いは、どちらかというと単純なスケーリングの側面に関わるものでした。

BIOS起動手順

ミーチャと私は、まずサンフランシスコとポートランドのエンジニアに焦点を当てることにしました。サンフランシスコとポートランドは、新しいIntelチップセットとボード設計の立ち上げに主に集中していました。ベンガルールのエンジニアは、すでに生産されているチップセットのサポートに関わる問題の修正が主な仕事でした。

私はミーチャと一緒にトレーニング会場を手配し、サンフランシスコとポートランドのMCS BIOSエンジニア全員にスクラムトレーニングを実施するスケジュールを組みました。その際、他のグループと密接に協力しているテストエンジニアや、その他の関係者も数人参加させるようにしました。私の記憶が正しければ、この結果、3週間かけてサンフランシスコで2回、ポートランドで1回のトレーニングセッションが行われました。ミーチャは、サンフランシスコの各トレーニングセッションに参加しました。ポートランドのトレーニングには、ミーチャは参加しませんでしたが、クリシュナ・ミシュラがサポートに入りました。ミティアはポートランドのトレーニングには参加しませんでしたが、クリシュナ・ミシュラがサポートに入りました。ミティアは、その1週間後に行われたローンチの際、私と一緒にポートランドに向かいました。

立ち上げ作業は、サンフランシスコとポートランドで分担して行われた。最初の2日間は、木曜日と金曜日にサンフランシスコで行われ、ポートランドのBIOSチームのメンバーが会議に参加しました。翌週、ミーチャと私はポートランドで合流し、ポートランドのチームメンバーと共に立ち上げ作業を続けました。これにより、ポートランドのチームメンバーは、前週の作業に影響を与え、調整し、批准する機会を得ることができました。ポートランドの立ち上げ活動では、サンフランシスコのチームメンバーとも頻繁に打ち合わせをしました。

その際、私は達成すべきことをリストアップし、全員が各項目の意図を理解していることを確認しました。そして、必要なときにだけ参加することで、できる限りグループの主導権を握れるようにしました。このリストには、BIOSコンポーネントのバックログの作成、共通のDoneの定義、個々のチームの境界線の決定、イベントのスケジューリングなどが含まれています。

BIOSコンポーネントバックログ

この立ち上げ作業で最も興味深かったのは、コンポーネントバックログの作成です。次のIntelチップセットを立ち上げるために必要な知識は、チーム全体に非常に広く分散していた。どのチームメンバーも、全体をよく理解していなかったのだ。この解決策には、数日間のブレーンストーミングと、小規模なワーキンググループでの個々のPBIの詳細な改良、そして最後に段階的なストーリーマッピングの取り組みが必要でした。

初期コンポーネントバックログのブレーンストーミング

最初のBIOSコンポーネントバックログのブレーンストーミングの構造はかなり標準的なもので、違いは達成された有用な詳細と調整のレベル、そしてそれをうまく行うために必要な時間の長さであった。

この場合、BIOSエンジニアは、過去に何度も集団で行ってきたことを行っていたのです。互いに必要な知識を引き出す作業を集団で行う限り、必要なものをほぼ網羅した膨大かつ詳細なリストを作成することが可能だったのです。今にして思えば、コピーペーストの再利用や手動テストに頼るなど、ソフトウェアのやり方が悪かったために、BIOSエンジニアはIntelのチップセットが新しくなるたびに、ほとんど同じ手順を再確認していたのだと思います。

私たちは、思いつくことをすべてポストイットに書いて、予約しておいた大きな会議室の窓ガラスに貼って、共同作業をしていました。そして、ミーチャや他のメンバーが、それぞれの付箋に目を通すように指示します。そして、その付箋紙を感覚的に思いつくままにグループ分けし、同時に重複するものを整理していきました。グループ内で各ポストイットについて議論し、コンセンサスを得ると、参加者はその場で新しいポストイットを作成し、それが意味をなすようにしました。その後、小グループに分かれて新しいポストイットを作成し、再びディスカッションセッションに戻り、すべてを統合しました。これが初日の大半を占めた。1日目の終わりには、立ち上げ時のチェックリストの他の項目に切り替え、翌日のためにさらに多くのポストイットを用意させることに合意しました。

2日目の朝は、コンポーネントバックのブレーンストーミングを続け、お昼頃にブレーンストーミングを終了しました。その後、ローンチチェックリストの他の項目の仕上げに戻りました。

最初のSprintをサポートするのに十分な数のコンポーネントバックがありましたが、私たちが望み、可能であるとわかっている有用な詳細レベルを達成するにはまだ十分ではありませんでした。もし、これが典型的なソフトウェアエンジニアリングの文脈で開発されている新製品であれば、私たちが行ったことは無駄なことだと思います。しかし、この場合、私たちは長年にわたって蓄積してきた部族の知識を効果的に統合し、文書化したのです。

大規模スクラム」の「初期PBR」ガイド。More with LeSS_にある_初期PBR_ガイドでは、_初期プロダクトバックログリファインメント_をより詳細に扱っています。動機の1つは以下の通りです。

顧客中心的な見方に関する限られた知識。

古い項目が以前は顧客中心的な方法で表現されていたとしても、事前のサイロ化された専門家たちは狭いタスクに集中しているため、完全な顧客中心的な視点を理解していないのです。

リーン＆アジャイル開発を拡大するための実践」の「第5章：計画」にも、関連するさまざまな実験があります。最も直接的に関連するのは、「Try…Kickstart large-scale Scrum with one initial Product Backlog refinement workshop_」である。

初期BIOSコンポーネントバックログのリファインメント

最初の2、3スプリントの間、私は、インセプションで作成された最初のBIOSコンポーネントバックログのさまざまな側面について最もよく知っているエンジニアの異なる小グループと一緒に働きました。私は、各ワーキンググループにINVESTテストを思い出させ、いくつかのPBIを作成する作業を手伝いました。一度、うまくまとまったPBIがどんなものかという感触を得ると、そのグループは、自分たちが知っているすべてのPBIに手を入れ、洗練させていきました。ほとんどの場合、私は彼らと一緒にいて、彼らの作業をサポートしました。通常、各ワーキンググループは、1行の説明をどのようにすれば良い受け入れ基準を持ったPBIになるのか、そのコツをつかむのに1〜2時間かかりました。その後、ワーキンググループは、残りの関連する優先度の高いPBIを、よく練られたPBIに改良するために、さらに1～2時間の努力を必要としました。これらのワーキンググループの開発者は、通常、設立時に結成したBIOS機能チームのうち2つ以上にまたがっていました。

BIOS コンポーネントバックログの詳細が十分であると感じたところで、ミーチャと私は、ストーリーマッピングと親和性推定に移りました。ミーチャと私は、各PBIの要約詳細を小さなカード形式で印刷し、San Francisco BIOSチームが座っている場所の近くにある小さな情報ラジエーター専用ルームでストーリーマップの構築を開始しました。ミーチャと私は、BIOSエンジニアの時間的な制約に配慮しながら、意味のあるときにはいつでも、さまざまなグループのBIOSエンジニアを引き込みました。最終的には、新しいIntelチップセットとボード設計のMVPとともに、BIOSコンポーネントバックログの合理的な順序を作り上げました。MVPは、コンポーネントバックログの半分以上を占めることになりました。ストーリーマップが落ち着きを取り戻すまでには、数日間にわたり、それぞれ1～2時間のセッションが必要でした。

この最初の改良作業の終わりに、私たちはBIOSチームのメンバー全員を集めて、壁に貼ってあるものを見直すために、より大きなミーティングを開きました。ポートランドチームのメンバーが効果的に参加できるように、デジタル写真とビデオ会議を組み合わせて使用しました。この大きな会議で、BIOSチームのメンバーは、ミーチャがストーリーマップの全体的な健全性をチェックするのを手伝いました。また、親和性推定を使用して、MVP内のすべてのPBIの大まかな工数推定値を得ました。

BIOSチーム全員の集合的な知識を最終的に把握したので、1～2スプリント先という短期的な視野に焦点を当てた、日常的な改良セッションに入りました。

LeSSの本からの様々なマルチサイト参照コンテンツは、以下のマルチサイト参照コンテンツのサブセクションにリストアップされています。

図17: 最初の2日間の立ち上げ会議からの簡単な付箋紙のPBIは、さらに改良されて電子的に保存されました。これらの改良作業は、BIOSコンポーネントの特定の領域に焦点を当てた小さなクロスチーム・グループによって行われました。チーム横断のグループが収穫の少ない地点に到達するまでに、1スプリント以上かかりました。チーム横断的な改善活動から十分な知見が得られたので、全体像を把握するために、物理的なフォーマットに戻しました。これは、ストーリーカードを印刷し、壁に無造作に貼り付けて、さらなる改善活動に備えているところです。

図18：_BIOS Fake Product Ownerは、自然なグループ分けと順序付けを探し始めた。最終的な結果は、ストーリーマップと、壮大なグループ化を伴う蛇のように順序付けられたコンポーネントバックログを少し混ぜたようなものでした。この大きなマップは、数日間かけてゆっくりと進化していきました。BIOSの機能チームから様々なグループの人々が、より深い洞察を得るために引き抜かれました。壁が落ち着くと、偽のプロダクトオーナーは、BIOSスクラムチームのメンバー全員とミーティングを行い、全体的な健全性をチェックするようにしました。この時点で、赤い矢印で示すように、MVPが明らかになりました。

図19: _大グループのマルチチームのサニティチェックの間、すべてのBIOSスクラムチームメンバーが利用可能であったが、MVP内の残りのすべてのPBIを再推定するために親和性推定が使用された。その後、カードはよりきれいなストーリーマップのバージョンに再配置され、ラリーは新しい情報を反映するために更新されました。

**図20：ミーチャは、私たちが必要とするマスキングテープを提供してくれるヘルパーがいることを確認しました。

マルチサイト参照コンテンツ

「Practices for Scaling Lean & Agile Development」には、多拠点会議の進行に関連する有用なコンテンツが多数掲載されています。大規模スクラムによる大規模、マルチサイト、オフショア製品開発_』に、マルチサイトミーティングのファシリテーションに関連する有用なコンテンツがたくさんあります。副題でさえも、それを暗示しています。

大規模スクラム More with LeSSには、関連する物語と、いくつかの関連するガイドも含まれています。

_Large-Scale Scrum: More with LeSS_のコンテンツは以下の通りです。

• _ガイド。クロスチーム・ミーティング
• ガイド マルチサイト PBR
• _LeSS Huge Story。マルチサイト・チーム

リーン&アジャイル開発のスケーリングのための実践」の第12章「マルチサイト」。大規模スクラムによる大規模、マルチサイト、オフショア製品開発_の第12章：マルチサイト_は、マルチサイトの課題への対処に完全に費やされている。この章の中で、最初のBIOSコンポーネントバックログの改良作業に最も直接関連するいくつかの実験があります。

• Try…Seeing is believing-ubiquitous cheap video technology and video culture（見ることは信じること-ユビキタスな安価なビデオ技術とビデオ文化
• 試してみよう…マルチサイト計画ポーカー（見積もりポーカー）
• Try…多拠点会議の基本プラクティス

初期のリファインメントを振り返って

最初のBIOSコンポーネントのバックログを改良するために費やした詳細と努力の量は、私が以前または以後に行った同様の作業の中で最も大きいことは確かです。しかし、このような状況であれば、もう一度やり直したいと思います。私たちは、BIOSエンジニアの整合性と参加意識を高めることができました。

将来、プロトタイプのIntelチップセットに対応するためにコンポーネントバックログを拡張する際に、作成した詳細な情報が必ず役に立ちます。AMI プラグイン アーキテクチャの利用が増えれば、手戻りが少なくなるため、詳細はさまざまになります。しかし、新しいPBIの種を蒔くには、以前に行われたものに目を通すのが一番でしょう。

私たちは、人工的な改良のタイムボックスに自分たちを押し込めるようなことはしませんでした。どのレベルまで明確にし、どのレベルまで詳細にするのが最も合理的かを判断し、それを達成するためにエネルギーを集中させたのです。そして、それが完了したら、今度はチーム横断のリファインメントミーティングを実施しました。

BIOSのDoneの定義

2つ目は、「Doneの定義」の作成です。チームは、過去のひどいコピーペーストの行動から可能な限り離れることを確実にすることに決めました。可能な限りAMIのプラグイン可能な拡張ポイントを活用し、足りない必要な拡張ポイントはAMIに追加するよう圧力をかけることにしました。このコミットメントは、以下に含まれるより正式なDoneの定義に表れています。以下の行をご覧ください。 「プラグインレイヤー以外の変更は行わない。

図21: これは、数日間のローンチイベント中にBIOSチームによって作成された最初のドラフト Doneの定義である。

図22: BIOSチームが使用したDoneの定義は、数回のSprintの後、ここに示すように進化しました。このDefinition of Doneの例は、追加のコンテキストとともに、Forging Changeの表9.3で見ることができる。

BIOSスクラムの主な役割

Trent、ミーチャ、そして私は、プロダクトオーナーとスクラムマスターの最適な選択について、非常に多くの考えを巡らせました。

詳細は後述しますが、結局、ミーチャがプロダクトオーナーとして唯一の賢明な選択となりました。

また、当初は私が全チームのスクラムマスターとして活動する必要があるという結論に達しました。他のスクラムマスターの選択肢の中には、必要な経験を持った人がいませんでした。もし、ミーチャをプロダクトオーナーにすることにこだわらなければ、ミーチャをスクラムマスターに選んでいたかもしれません。

私たちが選んだプロダクトオーナーとスクラムマスターについて、よりニュアンスの異なる洞察を以下に述べます。興味があれば読み、なければ読み飛ばしてください。

ミーチャ、一時的な偽プロダクトオーナーになる

ミーチャは、BIOSグループ全体のディレクターでした。ミーチャ、Trent、そして私は、プロダクトオーナーが開発チームのメンバーに対して直属の権限を持つことは、力関係が不均衡になるため、非常に問題があることを認識していました（下記参照）。別の人格がその役割を担っていた場合、これは重大な問題となった可能性があります。私たちの場合、ミーチャは生まれつき謙虚なサーバント・リーダーなので、この対立は大きな問題にはなりませんでした。

Trent、ミーチャ、そして私は、プロダクトオーナーとしてより良い選択をしようと考えました。最終的に私たちは、この役割を効果的に果たすのに十分な要素を持ち、かつ適切な性格の強さを持つ人が他にいないことに気づきました。他の候補者は、性格に問題があるか、MCS製品全体とBIOSコンポーネントに関する十分な知識がなく、その役割を果たすことができなかったのです。

ラインマネージャーがプロダクトオーナーにならないようにする

私たちは、ミーチャをラインマネージャーと偽の一時的なプロダクトオーナーの両方として、私たちの特定の状況を回避できたからと言って、一般的に同じことを試みることをお勧めしません。LeSSの組織構造に関するガイダンスでは、チームメンバーがプロダクトオーナーに報告することを明確に避けています。

以下は、Large-Scale Scrumからの引用です。More with LeSS からの引用が参考になる。

ピーンではなくピア-チームがプロダクトオーナーに直接または間接的に報告し、階層的な力関係がある場合、その構造を変更し、チームとプロダクトオーナーがピアとして協力できるようにする必要があります。プロダクトオーナーは、チームをタスクのための小間使いのように扱うのではなく、協力的な関係を育むのです。5つの関係性_**

この組織構造で重要なポイントは、チームとプロダクトオーナーは「仲間」であり、上下関係にはならないということです。私たちは、役割の間で力のバランスを保つことが重要であると考えました。チームとプロダクトオーナーは、可能な限り最高の製品を一緒に作るために「協力的な」仲間であるべきで、ピア構造はこれをサポートします。この点については、「プロダクトオーナー」の章でさらに詳しく説明します。LeSSの組織構造

コンポーネントバウンダリのバランスに起因するPOの懸念事項

製品管理グループには、POとして迎えることを検討していた真のプロダクトオーナー候補がいました。残念ながら、関連する副社長の影響力の範囲に制限があったため、これらの個人のいずれかが管理するためのドメイン知識を持っていたマルチコンポーネントの境界になるように、コンポーネントの境界を十分に拡大することができませんでした。BIOSのマルチコンポーネント境界を拡張しても、MCS BIOSコンポーネントとMCS製品全体の自然な複雑さは、一般的な企業情報システムよりも根本的に大きいことを覚えておくことが重要である。

我々は、部門内の最も上級の幹部の一部から賛同を得ていたが、それらの幹部は、対処するために他の競合する多くの懸念を持っていた。しかし、そのような状況下でも、私たちの取り組みに政治的な圧力をかけてくれた幹部がいたことは間違いない。しかし、現実には、私たちに代わってさらに大きな組織改革を行うための政治資金を得るには、時間がかかり、さらに大きな成功を収める必要がありました。

高度に専門化した BIOS エンジニアが、さまざまな BIOS サブコンポーネントを横断して作業することに慣れるまでは、BIOS マルチコンポーネントの境界をさらに拡大すると、BIOS チームの技術力とチーム力が持続可能なレベルよりもさらに急速に伸びることになります。したがって、早い段階でBIOSコンポーネントの境界をさらに拡大することは、いずれにせよ選択肢とはならなかったのです。これらの理由は、LeSSガイダンスが製品定義を段階的に拡大し、LeSS Huge採用において要件領域を段階的に追加する動機付けとなるものです。

関連するLeSS製品規則

The following selected LeSS Framework rules are particularly relevant:

• There is one Product Owner and one Product Backlog for the complete shippable product.
• The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.
• All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.
  特に、以下の厳選されたLeSSフレームワークのルールは、関連性が高い。

出荷可能な完全な製品に対して、1人のプロダクトオーナーと1つのプロダクトバックログが存在する。
プロダクトオーナーは単独でプロダクトバックログの洗練に取り組むのではなく、顧客/ユーザーやその他のステークホルダーと直接作業する複数のチームによってサポートされる。
優先順位付けはすべてプロダクトオーナーを通すが、明確化はできるだけチームと顧客/ユーザーやその他のステークホルダーとの間で直接行う。

プロダクトオーナーシップは最大の課題ではない

拡張BIOSマルチコンポーネントの観点から見ると、顧客の問題はむしろ単純である。各新しいIntelチップセット用のカスタムBIOSは、前世代のIntelチップセット上で動作する前世代のBIOSが提供するのと同じサービスを提供しなければならない。これらの機能のマイナーな拡張は、新しいチップセットの世代ごとに必要とされることが多いが、それでも基本機能に比べれば些細なことである。BIOSのFake Product Ownerは、ある程度、将来的に問題を解決するためのより良い方法をチームと一緒に考える専門家に過ぎなかったのである。

コードベースの貧弱な状態は、「契約ゲーム」によって推進された歴史的に劣悪なエンジニアリング慣行の結果であった。非現実的な人工的な「コード・コンプリート」の期限を守るよう、常に上からプレッシャーをかけられ、職人気質のための個人の安全が十分に確保されていなかったのです。大量のコピーペーストの再利用と自動テストカバレッジの低さは、「コントラクトゲーム」がもたらした自業自得の2大例と言えるでしょう。その結果、BIOSコードベースを新世代のIntelチップセットに適合させるという途方もない作業が人為的に行われることになったのです。

皮肉なことに、より包括的な「Doneの定義」と、すべてのテストを段階的に完了させることのできる部門横断的なチームがあれば、より良い仕事をするための十分な時間が常にあったのである。インテルのチップセットのリリース日は本当だったが、ウォーターフォールステージのゲートデイトは、ウォーターフォールプロセスの押し付けによって生じた人工物だったのである。

新しいBIOSチームによって生み出された劇的な品質向上が、この状況を変えていくことになるはずだった。BIOSのカスタマイズの大部分がプラグイン可能なレイヤーになり、より優れた自動テストが行われるようになれば、新しいIntelチップセットへの適応も、従来よりもはるかに少ない労力で可能になると思われます。さらに、改善努力を続けることで、BIOSチームは、MCS Adminレイヤーを通して作業する能力を完全に拡大することができた。

品質向上とコンポーネント境界の拡張の両方が十分に進んだら、新しいチームはよりダイナミックな要件を処理するための時間とスキルの両方を手に入れることができます。それまでは、拡張されたBIOSのマルチコンポーネントの目標は非常に明確で簡潔であり、関連する作業も膨大だったため、プロダクトオーナーの役割はあまり必要なかったのです。実際、長年のBIOS経験を持つこのBIOSエンジニアのグループは、すでに何度も実装してきたものをより良く実装する方法について、新しい道を切り開く必要があっただけなのです。

BIOSチームがまとまり始め、エンジニアリング手法が改善され、BIOSのマルチコンポーネント境界がMCS製品全体の自然な要件領域を形成するMCSAまで拡張されると、製品管理からの真のプロダクトオーナーがいずれ重要になるだろう。

プロダクトオーナー選定制約の概要

これらの理由を総合して、私たちはミーチャをプロダクトオーナーの中期的なベストチョイスとして選びました。つまり、私たちは「リーン開発とアジャイル開発のスケールアップのための実践」で説明されている「偽プロダクトオーナー」の実験と、「大規模スクラム」の「一時的な偽プロダクトオーナーによる早期開始または混乱」のガイドを実施することを選んだということです。『More with LeSS』の Start Early or Messenger with Temporary Product Owner のガイドを参照してください。

BIOSチームの過剰な専門性と局所的な焦点に加え、長年の貧弱なエンジニアリングプラクティスによってもたらされたさらなる複雑性が、偽のプロダクトオーナーを開始することを要求しました。この人物は、BIOSコンポーネントバックログを理解し、BIOSチームの尊敬を維持するのに十分な専門的技術的深みを持つ人物である。
元来、他人に力を与える傾向があり、マイクロマネジメントを避けるプロダクト オーナーは、BIOS チームが成長し成熟できるような支援的な状況を確立するのに重要な存在だったのです。

• BIOSのLeSS指向の構造は、依然として契約ゲームによって駆動される大規模なウォーターフォールのコンテキスト内で実行されていたので、BIOSチームのための支援コンテキストを確立するのに役立つ十分な地位と政治的影響力を持つプロダクト オーナーを持つことが重要でした。
  コンポーネント境界を拡大することで、BIOSコンポーネントバックログを理解し導くために必要なBIOS固有の知識を減らすことができ、それによってプロダクトオーナーの他の良い選択が可能になる。BIOSエンジニアの機能横断性が高まり、これが可能になるまでは、BIOSの知識を多く持つFake Product Ownerが必要であった。
  Fake Product Ownerの存在は、BIOSチームをMCS製品全体の顧客からさらに孤立させることになる。私たちは、できるだけ早くFake Product Ownerの必要性をなくしたいと考えています。

スクラムマスターとしてのコーチ

MCS部門には、BIOSチームで試みるような厳しい状況下で、Scrumチームの設立を効果的に指導できるだけの経験を持つ正社員はいないと判断していた。選ばれた正社員は、徐々にその役割を指導していく必要があります。

Trentと私は、ミーチャが優れたスクラムマスターになるための適切な性格、人間関係、組織的知識、コンポーネント知識を持っていると感じていました。しかし残念ながら、コンポーネントの境界をさらに拡大するまでは、ミーチャにプロダクトオーナーの役割を担ってもらう必要がありました。

私たちは最終的に、最初は私がスクラムマスターとして活動する必要があると判断しました。Trentと私は、私がその役割を果たすための帯域幅を確保することに気を配りました。私は、BIOSエンジニアリングエリアの空いているデスクに移り、その後数ヶ月は、BIOSチームの立ち上げと成熟に専念しました。毎週、ポートランドに通っていたので、いつでも都合のいいときに移動することができました。実際、ミーチャと私は、ほとんどのことを一緒にやっていました。私は、ミーチャや他の強力なナチュラル・リーダーが、ほとんどの活動を自らリードできるよう、継続的にサポートしました。

BIOSチームがまとまり、成熟し始めると、さらに何人かの自然なスクラムマスター候補が現れました。彼らはもともと必ずしもスクラムに取り組んでいたわけではなかったのですが、時間の経過とともにそうなっていきました。ミーチャと私は、このような特定の人たちを、将来スクラムマスターになる可能性のある人たちに成長させることに焦点を当てました。

ミーチャの次の推薦文は、その困難な状況を明らかにしている。

Jamesとの仕事は、私にとっても、チームにとっても変革的な経験でした。

彼は、私たちを「ここでスクラムができるわけがない」から「もう後戻りできない」状態にしてくれました。彼は、チームをウォーターフォールからスクラムへと導いたのです。

私たちはファームウェアエンジニアのチームであり、スクラムは私たちの分野にはふさわしくないと固く信じていました。ジェームズは、スクラムがソフトウェアクラフトマンシップ、品質、そして仕事の計画の仕方に焦点を当てるためのフレームワークであることを実証したのです。

Jamesは、私がプロダクトオーナーとして行動できるように指導し、チームがスクラムフレームワークの学習曲線を乗り越えるように指導してくれました。

開発、テスト、CI/CDの技術的な側面に焦点を当てた彼の指導は、チームにとって非常に有益なものでした。彼は多くのコンセプトやツールを紹介し、必要な技術面ではチームメンバーと協力してくれました。

結果は非常にわかりやすいものでした。私たちはスクラムを1年近く実践しています。バックログの可視性が格段に向上しました。チームワークが良くなった。初期の製品品質が向上した。

スクラムマスター選択制約の概要

• The exotic hardware and firmware engineering context coupled with the cultural challenges involved were too challenging for the skill-set of any full-time Scrum Master candidate available.
• ミーチャ had the natural aptitude to be quickly grown into an effective Scrum Master. This option was precluded due to our need for ミーチャ to act as the Fake Product Owner.
• Once it became politically and technically practical to expand the component boundary we could replace ミーチャ as Product Owner, transitioning ミーチャ or anyone else who showed promise and growth to a Scrum Master role.
• I was the only person available to us with a strong enough Scrum Master skill-set to attempt such a challenging Scrum adoption. I could only do it by leaning heavily on the BIOS developers, ミーチャ, and others for guidance as we collectively found our way to improving things.

異国情緒あふれるハードウェアとファームウェアの技術的背景、そして文化的な課題は、フルタイムのスクラムマスター候補者のスキルセットには難しすぎるものでした。
ミーチャは、効果的なスクラム マスターに短期間で成長する素質がありました。このオプションは、ミーチャが偽の製品所有者として行動する必要があったため、除外されました。
コンポーネント境界を拡張することが政治的にも技術的にも現実的になれば、ミーチャをプロダクトオーナーに置き換え、ミーチャや有望で成長を見せた人物をスクラムマスターの役割に移行させることができます。
私は、このような難しいスクラムの採用を試みるのに十分な、強力なスクラムマスターのスキルセットを持つ唯一の人間だったのです。私は、BIOS 開発者や ミーチャ などのガイダンスに大きく依存しながら、集団で物事を改善する方法を見つけることでしか、それを行うことができませんでした。

BIOS Teams 自ら選ぶ

インセプションでは、それぞれの新しいチームに誰が入るかを共同で考えました。

ポートランドの人たちが1つのチームを作ることは、グループにとって簡単な決断でした。ポートランドには、6人ほどの人しかいませんでした。その中には、ソフトウェア、ハードウェア、テストのエンジニアも含まれていた。ミーチャ、クリシュナ、トレント、そして私の4人は、ポートランドでトレーニングする人を決めたときから、そうなるように努力してきました。クリシュナは、MCSの他の部分を担当しているグループから引き抜いたテストエンジニアの中から、適切な人材を見つける手助けをしてくれたかもしれません。

本当の課題は、誰がサンフランシスコのどのチームに入るのか、そしてサンフランシスコのチームがいくつあるのか、ということでした。当初は2名でスタートしました。確か、最初の打ち上げの日の午後に、チーム編成を自分で考えてみたんです。その後、一晩考えて、2日目にはチーム編成を少し修正しました。

数カ月後には、BIOS のコンポーネント境界の端で作業する開発者を数人加え、同じ LeSS 指向の構造で作業する別のチームを 1 つまたは 2 つ形成する予定です。

ポートランドのチームは、ほぼ同じ場所で活動していましたが、当初は重要なエンジニアリングスキルがいくつか不足していました。しばらくは、サンフランシスコのエンジニアが1〜2人、ポートランドチームのメンバーとして参加していました。やがて、ポートランドのエンジニアは完全に自立していったと思います。

BIOSのケーデンスとスプリントタイミング

そこで、2週間の周期で行うことにしました。スプリントの境界線が週の半ばになるようにしたのは、私が成層圏のどこかで飛行機に乗っているのではなく、チームのために使えるようにするためです。

BIOSレトロスペクティブの構造

私たちは、チーム横断的なレトロスペクティブとチームごとのレトロスペクティブを組み合わせて、いくつかのバリエーションを試しました。レトロスペクティブの構造は、細部では若干異なるものの、精神的にはLeSSスプリントルールに類似していた。

レトロスペクティブのメタ構造の観点から、私たちは通常、Esther DerbyとDiana Larsenによる_Agile Retrospectives_に見られるアドバイスに従いました。最も一般的なテクニックは、ドット投票による単純なブレーンストーミング、タイムボックスによる議論、そして回顧構造そのものに関する簡単な4箱の回顧の使用であった。

初期のレトロスペクティブの構造

当初のレトロスペクティブな構成は以下の通りであった。

1. チーム横断ミーティングを行い、チーム横断的に最も優先度の高い議論項目を特定する
2. チームごとのレトロスペクティブで、チームごとの問題点とチーム横断の最優先事項を議論する
3. チームごとの会議の結果を議論し、チーム横断的な問題を解決するためのアプローチについて合意するためのチーム横断会議（LeSS全体レトロスペクティブ）。

クロスチーム・ミーティングには、いずれもBIOS各チームのメンバー全員と、偽プロダクトオーナーのミーチャ、そしてスクラムマスター代行の私が参加しました。

最初のクロスチーム・ミーティングは、チームレベルのレトロスペクティブで検討することが重要だとグループが感じた、チーム横断的な課題を特定することに焦点を当てました。その意図は、チーム横断的な問題に対する潜在的な解決策を、より小さなチームレベルのディスカッションで考え出す機会を提供し、その後のクロスチーム・ミーティングでは、より大きなグループのディスカッションでは表面化しなかったかもしれない深い洞察から恩恵を受けるようにすることでした。

これは、チームレベルのレトロスペクティブの後に全体のレトロスペクティブを行うというLeSSフレームワークの構造に非常によく似ていることにお気づきでしょう。重要な違いは、チームレベルのレトロスペクティブは、全体的なレトロスペクティブの第1部と第2部の間に挟まれていることです。

実際には、チームレベルのレトロスペクティブは、全体的なレトロスペクティブの最初の部分で特定されたあらゆる問題にほとんどの時間を費やしていたようです。もし、LeSSフレームワークが規定するように、チームレベルのレトロスペクティブが全体的なレトロスペクティブ会議の前に実施されていれば、チームレベルのレトロスペクティブはより深い洞察に満ちたものになっていただろうと思います。

表面化した問題のほとんどは、チーム横断的なものでした。これは単に文脈の結果なのか、それともチームレベルのレトロスペクティブの前に全体のレトロスペクティブの一部を行うことで、意図せずチームレベルの議論からチームの注意をそらす効果があったのかは分かりませんが、チームレベルのレトロスペクティブはより困難なものでした。

後期のレトロスペクティブの構造

私たちは一般的に、チーム横断の最終回顧展を、回顧展そのものの回顧展で締めくくるように気をつけていました。このことから、最終的には以下のようなレトロスペクティブの構成に変更することにした。

1. チーム横断会議による、チーム横断の最優先検討事項の洗い出し
2. 上位数点の課題についての分科会。2. チームの垣根を越えて、自分が最も熱意をもって取り組めるもの、あるいは最も必要とされているものに参加する。
3. チーム横断会議：分科会の成果を議論し、チーム横断的に議論された課題を解決するためのアプローチについてコンセンサスを得ます。

この構成は、真ん中のステップを除いて、最初の構成と同じであることがおわかりいただけると思います。チームごとのレトロスペクティブに分かれるのではなく、チームの垣根を越えて、最も親和性が高いと思われるグループと連携するワーキンググループに分かれたのです。

実際には、ポートランドチームは第2ステップの間、通常チームとして活動しました。チーム横断的なイベントは、テレプレゼンスルームで行うのが一般的でした。もし、サンフランシスコの誰かが、ポートランドのメンバーの大半が参加したトピックに特に熱意を感じていたら、そのトピックのためにテレプレゼンスルームを使用することになります。他のワーキンググループは、テレプレゼンス機能が限られた他のブレイクアウトルームを使用することになります。

サンフランシスコでの振り返りワーキンググループの分かれ方は、ややランダムなことが多かったですね。会議テーブルの真ん中に分かれて、数人がワーキンググループを交代することがよくありました。

関係者の生来の協調性と人間関係の歴史を考えると、チームごとの専用の回顧がないことは問題ではないように思えました。私が関わってきた他のグループでは、チームごとのレトロスペクティブが重要であることがよくわかりました。おそらく、時間が経ち、チームが増えれば、力学が変化し、チームはチームレベルのレトロスペクティブを復活させることを決めたことでしょう。

オーバーオールレトロスペクティブでは対処しきれない、より大きな構造的な問題

LeSS では、全体的な回顧は、より広範なシステム的問題に対処することを目的としている。BIOSチームは、自分たちの管理下にあるチーム横断的なシステム上の問題には積極的に取り組み、解決策を実行したが、より広範なシステム上の問題にはほとんど取り組むことができなかった。VP層マネージャーも、新しいSVPマネージャーも、一度も出席していない。

ガイドを参照。大規模スクラムの_全体的な振り返り_を参照してください。このトピックに関するより詳しいニュアンスについては、_大規模スクラム: LeSSでさらに詳しく_を参照してください。

BIOSとLeSSルールの整合性

BIOSチームからの詳細や洞察を述べる前に、正式なLeSSルールとの整合性を確認することが有益である。

**図23：Scaling Lean and Agile Developmentの中で、LarmanとVoddeはJay Gilbrithの星型モデルの観点から組織戦略について述べている。LeSSの採用における最大の問題のいくつかは、報酬と人材、そして、それらと構造との交差に関連している。技術的熟練と管理的熟練を同じレベルで報いる報酬構造への十分な配慮と相まって、正式な組織構造をフラット化することに失敗したのである。BIOSのLeSSルールへの整合](#bios-alignment-to-less-rules)のセクションを読むときに、ギルブリスのモデルを心に留めておくと便利です。(図は許可を得て使用しています。)

LeSS 構造の枠組み

• 実際のチームを基本的な組織の構成要素として、組織を構築する。

  はい

• 各チームは、（1）自己管理、（2）機能横断的、（3）同じ場所にいて、（4）長寿命である。

セルフマネジメント： すべてのチームは、初日からセルフマネジメントを行いました。各チームはスプリントにどれだけの仕事を取り込むかをコントロールし、各スプリントを共同でタスク化し、BIOSコードベース内のアーキテクチャの決定を完全にコントロールし、毎日のスクラムを実行し、その他セルフマネジメントのチームに期待されることすべてを実行したのです。

クロスファンクショナル： 初期には、各チームがBIOSコンポーネントの特定の領域に強い親和性を持っている傾向がありました。BIOSコンポーネント内でもよりクロスファンクショナルになるには、各チームともしばらく時間がかかりました。チームがさらに進化するにつれ、当初の親和性から徐々に外れていくようになったのです。

共通のBIOSコンポーネントバックログと単一のFake Product Ownerの存在は、チーム内およびチーム間のクロストレーニングのレベルを継続的に高める構造的な力を生み出した。

BIOSチームがMCSAを通じてBIOSコンポーネントの境界をさらに拡張するために働くと、チームは徐々にMCS製品全体の観点からさらにクロスファンクショナルになっていきました。これは完全な可能性に達することはありませんでしたが、MCSA関連のBIOS作業に親和性のあるあるあるチームは、確実にその道を歩んでいました。このトピックは、_BIOSコンポーネント境界の拡張_のセクションでさらに検討されます。

各チームはほとんど同じ場所に配置されました。 ポートランドチームはBIOSコードベースのいくつかの分野で知識が不足していたため、ポートランドチームは当初、サンフランシスコ地域に1～2名のメンバーを配置していました。このような例外的なケースを解決するために、各チームは積極的にクロストレーニングに取り組みました。確か、サンフランシスコを拠点とするポートランドチームのメンバーは、数回のスプリントでポートランドチームを離れ、サンフランシスコチームのいずれかに参加することができたと記憶しています。

長続きしたこと チームは数ヶ月間、ほぼそのままでした。大規模なレイオフは、明らかに長寿命化に影響しました。また、ポートランドチームの分散が解消され、開発中のハードウェア世代のBIOSに対応できるBIOS開発者が増えたため、チーム間でメンバーの自主的な入れ替えが少しありました。一般的には、新たに加わったメンバーが新しいチームを結成し、元の3つのチームはかなり安定した状態を保っていました。

しかし、数カ月ごとに新しいチームに移籍するようなことはありませんでした。

数年のタイムスケールから長寿を見ると、確かに問題がありました。Larman氏とVodde氏は、「Scaling Lean and Agile Development」の中で、組織戦略についてJay Gilbrith氏のスターモデルという観点から語っている。様々な要素のうち、「報酬」と「人」の要素には十分な注意が払われていない。

既存の報酬体系では、エンジニアが技術的な道を歩み続けるインセンティブはすでにある程度備わっていたものの、管理職として出世するための金銭的・文化的インセンティブがはるかに強く残っていたのです。同様に、部門の最高レベルで行われているコミットメントゲームから生じる継続的な圧力釜は、重要な学習や専門的な成長のための時間をほとんど残さないままであった。

• チームの大半は、顧客志向のフィーチャーチームです。

各チームは BIOS コンポーネントの境界でほぼ垂直方向にスライスされていましたが、BIOS コンポーネントの境界はそれ自体、妥協の産物でした。BIOSチームが成熟するにつれ、私たちはMCS製品全体を貫く、より垂直方向に拡張されたマルチコンポーネント境界を確立しようと努力しましたが、最終的に達成できたかもしれないほど垂直方向にはなりませんでした。

• スクラムマスターは、LeSSの導入がうまく機能するように責任を持ちます。彼らの焦点は、チーム、プロダクトオーナー、組織、および開発プラクティスに向けられます。

  できていました

• スクラムマスターは、1つのチームだけでなく、組織全体のシステムに焦点を当てます。

  できていました

• スクラムマスターは、専任のフルタイムの役割です。

  そうなっていました

• 1人のスクラムマスターが1～3チームを担当することができます。

  米国にいるすべてのBIOSエンジニアがフィーチャーチームに組み込まれる頃には、私は5つのチームにサービスを提供していました。実際には、ミーチャをはじめ、スクラムマスターに育てつつある人たちと多くの負担を分かち合っていました。

• LeSSでは、管理者はオプションですが、管理者が存在する場合、その役割は変化する可能性が高いです。彼らの焦点は、日々の製品作業の管理から、製品開発システムの価値提供能力を向上させることに移ります。

  そうですね。ミーチャ、Trent、私の3人で、非常にフラットな体制を維持しています。ミーチャが日々のBIOSコンポーネント作業の管理に注力した記憶はありません。

• マネージャーの役割は、Go Seeの実践、Stop & Fixの奨励、”適合性より実験 “など、製品開発体制を改善することです。

  はい。

  ミヤと私は、SFOを拠点とするチームに同席していましたが、時々ポートランドにも飛んでいました。Go Seeとexperiment over conformanceの様々な例を挙げます。

  • Dmitry と私は、有益と判断された場合には、1 人以上の BIOS 開発者とペアでプログラムしたり、設計の議論に参加したりすることがありました。
  • Dmitryと私は、組織の上下左右にいる様々な人たちと積極的に会い、多くの組織的な障害を解決する手助けをしました。
  • Emmett Brownとペアを組み、BIOSコードの自動ユニットテストを作成する方法を研究しました。
  • BIOSチームがコントロールできるCIサーバーを立ち上げるために、数人の開発者とペアを組み、多くの時間を費やしました。
  • BIOS チームの振り返りでは、Sprint ごとに少なくとも 1 つの実験を特定し、その後のそれぞれの Sprint でアクションを起こしました。

• 製品グループについては、LeSSの完全な構造を「最初に」確立すること、これがLeSS採用のために不可欠です。

はい、拡張BIOSコンポーネントの範囲内です。いいえ、より広い全体的なMCS製品の範囲内です。

• 製品群を超えた大きな組織では、GoとSeeを使って進化的にLeSSを採用し、実験と改善が当たり前の組織を作りましょう。

  できていました。

LeSS プロダクトの枠組み

• 出荷可能な完全な製品に対して、1人のプロダクトオーナーと1つのプロダクトバックログが存在します。

BIOSコンポーネントについてはYes。MCS製品全体ではありません。

• プロダクトオーナーは単独でプロダクトバックログの洗練に取り組むのではなく、顧客/ユーザーやその他のステークホルダーと直接作業する複数のチームによってサポートされる必要があります。

  できていました

• 優先順位付けはすべてプロダクトオーナーを通すが、明確化はできるだけチームと顧客・ユーザーなどのステークホルダーとの間で直接行う。

BIOSコンポーネントについてはYes。MCS製品全体ではありません。

• 製品の定義は、実用的な範囲で、エンドユーザーや顧客を中心に幅広く設定する必要があります。時間の経過とともに、製品の定義は拡大する可能性がある。より広範な定義が望まれる。

  BIOSコンポーネントの境界を可能な限り広く拡張するという点ではYes。MCS製品全体を包含するLeSSコンテキストの欠如という点で、「いいえ」。

• 製品全体のDoneの定義は1つで、全チームに共通です。各チームは、共通の定義を拡張することで、より強力なDoneの定義を持つことができる。

BIOSチームによって使用される共通の「完了定義」の点ではYes。MCS製品全体から見ると、「いいえ」。

• 完成目標は、Doneの定義を改善し、Sprintごとに（あるいはもっと頻繁に）出荷可能な製品に仕上げることである。

BIOSコンポーネントに関してはできていましたが、MCS製品全体にLeSSの採用を拡大するまでは、避けられないUndoneの作業が少しありました…。

LeSS スプリントの枠組み

• 製品レベルのスプリントは1つであり、チームごとに異なるスプリントではありません。

BIOSのコンポーネントチームという点ではそうですね。

• 各チームは同時にスプリントを開始し、終了する。各スプリントの結果、製品全体が統合されます。

BIOSのコンポーネントチームという点ではそうですね。

• スプリントプランニングは2つの部分から構成されています。スプリントプランニング1は全チーム共通で行い、スプリントプランニング2は通常各チームで別々に行います。スプリントプランニング2は、密接に関連する項目については、共有スペースで複数チームのスプリントプランニングを行う。

BIOSのコンポーネントチームという点ではそうですね。

• スプリントプランニング1には、プロダクトオーナーとチームまたはチームの代表者が参加します。各チームがそのスプリントに取り組む項目を仮選定します。各チームが協力する機会を確認し、最終的な質問を明確にします。

BIOSのコンポーネントチームという点ではそうですね。

• 各チームはそれぞれのスプリントバックログを持っています。

BIOSのコンポーネントチームという点ではそうですね。

• スプリントプランニング2は、チームが選択したアイテムをどのように実行するかを決定するためのものです。これは通常、設計とスプリントバックログの作成に関係します。

BIOSのコンポーネントチームという点ではそうですね。

• デイリースクラムはチーム毎に行われている

BIOSのコンポーネントチームという点ではそうですね。

• チーム間の調整はチームが決める。中央集権的な調整よりも、分散的で非公式な調整を優先する。コードでのコミュニケーション、チーム横断ミーティング、メンター、トラベラー、スカウト、オープンスペースなどによるJust Talkやインフォーマルなネットワークを重視する。

BIOSのコンポーネントチームという点ではそうですね。

• プロダクトバックログリファインメント（PBR）は、共有学習を増やし、調整の機会を活用するために、複数のチームで行うことが望ましい。

BIOSのコンポーネントチームという点ではそうですね。

• There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the information needed for effective inspection and adaptation.

BIOSのコンポーネントチームという点ではそうですね。

• チーム毎にスプリントレトロスペクティブが実施されている

  当初はBIOSのコンポーネントチームという観点ではそうでした。その後、先の「BIOS Retrospective Structure Adaptation」の項で説明したように、少し逸脱しました。

• チームレトロスペクティブの後に全体レトロスペクティブを開催し、チームやシステム全体の問題を議論し、改善策を練る。プロダクトオーナー、スクラムマスター、チーム代表者、マネージャー（いる場合）が参加します。

BIOSのコンポーネントチームという点ではそうですね。

BIOS トリアージルール

BIOSチームは、MCSシステム全体の他の部分に取り組んでいるエンジニアや経営陣からの要求に気を取られることがよくありました。これらの要求の中には、MCS 開発全体のために迅速な対応が必要なものもあれば、迅速に拒否するか、BIOS コンポーネントバックログに移動して優先順位をつけるのが最善と思われるものもあった。

一部のテストエンジニアを除き、BIOS スクラム開発チームのメンバーは全員、ミーチャ に直接報告した。機能管理者が、彼らに報告するBIOSチームメンバーの気を散らすという問題は、ほとんど存在しなかった。

この問題は、実際のMCS製品の境界線と比較した場合、BIOSコンポーネントの境界線が不完全であることと、MCS BIOSコードとAMI BIOSコードが過剰に結合していることが主な要因でした。

トリアージガイドラインの正式なセットを作成すると、根本的な根本原因がより完全に対処できるようになるまで、これらの混乱を管理する上で非常に有用であった。以下のような利点がありました。

• プロダクトオーナーの意思の尊重
• 予期せぬ重要な要求に対応することができる
• BIOSエンジニアが不適切な要求に対してノーと言えるよう支援する
• 関係者全員への透明性の提供
• BIOSエンジニアの集合的な知恵の集約
• BIOSチーム内の整合性の達成
• BIOS スクラムチームが過去のデータに基づいてよりよく検証し、適応する能力

図24: BIOSチームが使用するこのトリアージガイドラインは、3つの基本カテゴリーを確立している：即時行動を起こす、プロダクトオーナーに尋ねる、BIOSコンポーネントバックログに載せる、である。プロダクトオーナーは意図を明確に伝えると同時に、スクラム開発チームが適切なときに即座に行動を起こせるように権限を与えている。ガイドラインを明示することで、プロダクトオーナーは、チームの知恵を結集してガイドラインを共同で改良する確率も向上させることができます_。

BIOS のユニットテストの可能性

意思あるところに、方法あり。BIOS内の自動ユニットテストは非常に困難であることは分かっていました。開発の初期段階ではTCP/IPネットワークスタックが存在せず、標準的なCライブラリ関数もほとんどなく、すべてのコードをクロスコンパイルしてターゲットにフラッシュしなければならず、AMI BIOSエコシステム内のユニットテストに対する既存のアプローチも見つかりませんでした。

私はソフトウェアエンジニアとして10年以上、テストファーストの開発を実践してきましたが、BIOSや低レベルのハードウェア設計についてはほとんど何も知りませんでした。同様に、BIOSエンジニアは、よりパフォーマンスの高いミドルウェアチームに見られる言語、ツール、デザインパターン、様々な職人技の実践にほとんど触れることがなかったのです。多くの点で、MCSのBIOSエンジニアのほとんどは、非常に狭いソフトウェアエンジニアリングのスキルを持つ電子工学のウィザードです。

Emmett Brownは情熱的なエンジニアで、MCS BIOSコードのテストファースト開発へ移行する方法を見出そうと決意していました。私はEmmettと一緒に、必要な設計要素を理解し、さまざまな上位の開発エコシステムにおけるそれぞれの事例を紹介しました。Emmettは私に、UEFI規格やBIOSツールチェーン、関連するハードウェアの制約など、さまざまな詳細を教えてくれました。そして、私たちは課題を解決するために、さまざまなアプローチを検討しました。

数週間の作業を経て、Emmettは最終的に実用的なプロトタイプを完成させました。彼は、依存関係の逆転を実現するために UEFI 標準の一部を使用し、テストダブルを手作業でコーディングし、粗い C 単体テストフレームワークを移植し、結果を Windows ワークステーションまたは CI サーバーに戻すためにシリアル接続で基本転送プロトコルを構築し、構築ツールチェーンまたは努力を指揮したのです。

私は、技術的にそれほど難しくない状況で、命令型言語で開発するエンジニアが、自動ユニットテストが技術的に不可能である理由として、あらゆる種類の理由を提供するのを聞いたことがあります。しかし、それを信じてはいけません。Emmettは、複雑な回路基板の原始的な泥の中で、あらかじめ構築された有用な単体テストツールのない状況で、単体テストの自動化を達成しました。

BIOSチーム数の増加{#bios-team-count-increases}。

初期の採用範囲を管理しやすくするため、当初は最新のインテル製チップセットとリファレンス・ボード・デザインのサポートに携わる人たちだけを対象としていました。旧製品のインテル製チップセットに関するバグフィックスやその他のマイナーな作業に従事する者は、レガシー組織設計の中で作業を継続しました。つまり、BIOSコンポーネントの境界には、最新のプロトタイプIntelチップセットだけが含まれていたのである。

IntelのメジャーリリースごとにAMIのコードベースが分かれていたため、この戦略はかなりうまくいきました。レガシーIntelチップセットに関する作業が一段落する頃には、最初の3つのBIOSスクラムチームは、ほぼ統合されていた。

サンフランシスコのBIOS開発者が増えたため、BIOSコンポーネントバックログを1つにまとめたものをもとに、新たに2つのチームを結成しました。それぞれの新しいチームは、プロセスへの完全な関与とコミットメントを確保するために、様々なチーム横断的な成果物に影響を与え、承認することが許可されました。思い出せませんが、この取り組みの一環として、必要な人にはアジャイル概要トレーニングを実施したはずです。

2つの新しいBIOSスクラムチームを立ち上げると同時に、BIOSコンポーネントの境界を事実上拡大し、Intelチップセットの全世代を含むようにしました。

BIOS コンポーネントの境界を拡大する

MCS システムの最上位には、MCS インフラストラクチャ全体を管理する責任を負う Modular Compute System Administrator (MCSA) があります。MCS の顧客のシステム管理者が MCS と対話するとき、それは通常、彼らが対話する MCSA です。

MCSのBIOSコードの強化のいくつかは、MCSAで小さな変更を行う必要がありました。また、各ノードで実行されている低消費電力ノードコントローラ上で実行されているファームウェア内で行われる必要がありますあまり一般的ではありませんでした。

当初、BIOSチームは、より上級のMCSA開発者数名と、横断的な機能に関して共同作業を行いました。BIOSスクラムチームは、MCSA開発者と作業を調整することがしばしば困難であることに気づきました。MCSAの開発者は、ウォーターフォール型のプロジェクトにつきものの、納期に対するプレッシャーに悩まされていた。

もし、政治的に可能であれば、MCS製品全体の自然な要件領域と一致するBIOSコンポーネントの境界をより広く拡張して開始することで、上記のような調整の問題は存在しなかったでしょう。

政治的な状況を考慮すると、MCS BIOS開発者がMCSAの変更を自ら行うための専門知識をゆっくりと身につけることが明白な解決策でした。BIOS スクラムチームが成熟するにつれ、BIOS スクラムチームの多くにとってこの必要性はますます明白になっていきました。私も、この方向で彼らを励ます傾向がありました。

様々な会話を通じて、私たちは、MCSAで働く少数のエンジニアと、ノード・コントローラ・ファームウェアで働く別のエンジニアから、賛同を得ることができました。この合意は、BIOSスクラムチームが、横断的な変更をBIOSスクラム自身が行えるほど簡単に行えるようにするための指針として、彼らに協力してもらうというものでした。その後、BIOSスクラムチームが作業を行い、BIOSチーム外の関連する専門家にコードレビューを行わせることになりました。

サンフランシスコのBIOS開発者は、何年も前からサンフランシスコのMCSA開発者の多くとうまくコラボレーションしていた。MCSAチームの主要なリーダーやアーキテクトの観点からは、BIOSチームがMCSAとBIOSの統合作業の一部を引き受けることは、歓迎すべきことだと考えられていたのです。ですから、ソフトウェア担当副社長が現状維持のために消極的に積極的に動いていたことは、実際には重要な問題ではないことがわかりました。MCSAとBIOSの統合作業が完了する限り、上級管理職の誰もそれがどのように行われたかを気にすることはなかったのです。

Node Controllerの開発者は、診断チームの設立に携わったのと同じディレクターを通じて報告する。そのため、BIOSチームにクロストレーニングを施し、ノードコントローラ内で小さな変更を加えるというような、政治的な大きな課題はなかったのです。Node Controllerの開発者のほとんどは、ポートランドのBIOSチームが使っていたのと同じポートランドの小さなオフィスに座っていた。

ミーチャと私は、このアプローチの成功は時間とともに大きくなると推論しました。いずれ、MCSAのエキスパートを1人か2人、BIOSグループに再配置しないことが、政治的に難しくなるだろうと予測したのです。BIOS スクラムチームが MCS を横断してエンドツーエンドで作業できるようになればなるほど、BIOS コンポーネントの境界はより自然なものになっていくでしょう。より多くのプロダクトバックログアイテムが、MCSプロダクトマネジメントグループにとって意味のあるものになっていくだろう。そうなれば、ミーチャは偽のプロダクトオーナーから脱却することができる。そして、チームのダイナミクスをさらに向上させ、私の代わりに効果的なスクラムマスターを育てることができるようになる。

しかし、少なくとも1つのBIOSチームをBIOSコードベースの外側に引き伸ばすという合意に対して重要な行動を起こす前に、私たちの周りで分裂が侵食され始めたのです。_【サポート体制の崩壊】(#bookmark=id.3l18frh)_の項では、上級管理職の交代とレイオフについてもう少し詳しく説明します。

BIOSインドチームの挑戦{#bios-india-team-challenges}。

サンフランシスコとインドのオフィス間の時差が非常に大きいことも、常に課題でした。同様に、報告系統の違いもアライメントの問題を複雑化させる傾向にありました。以下に、そのいくつかを紹介します。

以下のLeSSフレームワークとLeSS Hugeフレームワークのルールを振り返ることは有益である。

• 製品グループについては、「最初に」完全なLeSS構造を確立してください。
• 構造的な変更を含む LeSS Hugeの採用は、進化的な漸進的アプローチで行われます。

シニアレベルの経営陣の賛同が得られれば、インドチームとの協働で直面した問題のいくつかは、もっと早い段階で構造的に解決できたかもしれません。しかし、一方で、一度に多くの変化を起こすことは、持続可能なことでもあります。BIOSのLeSS採用が開始されるまでに、積極的に参加した当初のエンジニアリングSVPが退職していたことを忘れてはならない。

BIOSのアジャイル導入を通して、ミーチャと私は、私たちが行っている仕事を広く社会化するよう心がけました。古いIntelチップセットのレガシーサポートに取り組んでいたエンジニアでさえ、新しいIntelチップセットで使用されているDefinition of Doneを認識していました。インドからのリードエンジニアは、LeSS指向のスプリントレビューに参加するために、しばしば自宅からダイアルインしていました。

図15とその近くの BIOS Organizational Context セクションで、ミーチャと私がとった、インドにいるBIOS開発者の組織変更を孤立させて遅らせる戦術を説明しました。拡大したマルチコンポーネントの境界の1つとしてIntelチップセットの世代を使うことができたことと、インドが当初は旧世代のIntelチップセットに関する問題の解決に注力していたことが、これを可能にしたのです。この戦略を完全に実行する前に、ハードウェア担当の副社長が退職してしまったため、サポートの継続性に依存するという点でリスクの高い戦略でしたが、私たちの制約を考えると、他に実行可能な選択肢は思い当たりません。もし他に選択肢がなければ、将来この戦略を繰り返すこともあるかもしれませんが、可能であれば、より広範な変化への賛同を前もって得ておくことを強くお勧めします。

コーチングサポート {#coaching-support｝

MCS部門では、最初の1年間は私一人のコーチでした。トレントと私はかなり早い時期にインドを訪れましたが、当初は現地に大きな影響を与えるほどのコーチング能力を持ち合わせてはいませんでした。私は数日間のトレーニングを行い、人間関係を構築しましたが、それ以外はほとんど実践的ではありませんでした。

2年目に、Trentはインドで数人のコーチを雇うのに十分な資金を得ることができました。インドでベテランのアジャイルコーチを見つけるのは、米国で見つけるよりもさらに難しい。しかし、何ヶ月も面接を重ねた結果、私は最終的に数人を見つけることができた。さらに1カ月ほどして、Trentと私は、これらのコーチのためにインドのマネージャーの共同承認を得ることに成功し、交渉とオンボーディングを終えました。

インド拠点のBIOSエンジニアに対するウォーターフォールの圧力 {#waterfall-pressures-on-india-based-bios-engineers}.

レガシーIntelチップセットに関する作業が先細りになるにつれ、インドにいる数人のBIOSエンジニアが新しいIntelチップセットのBIOSコードベースへの貢献を開始しました。インドのエンジニアは、LeSS指向のBIOSチームの共通の「完了定義」や関連する規範を十分に理解していた。しかし、残念ながら、彼らのマネジメントは、まだウォーターフォール方式で進められていた。

サンフランシスコのBIOSスクラムチームの初期メンバーは、自分たちが苦労して向上させた品質を落とさせまいと、断固とした姿勢で臨んだ。サンフランシスコのBIOSチームのメンバーは、継続的インテグレーションを改善し、統合テストの自動化を進め、あらゆるコード変更を頻繁にレビューし、インドのBIOSエンジニアと何度も腹を割って話をした。これらの戦術的な解決策は、間違いなくプラスの効果をもたらし、問題のいくつかを部分的に軽減することができました。

ミーチャと私は、これらの問題を予期していました。私たちは、政治的な勢いが増すまで、組織的な戦いを遅らせるために、BIOSコンポーネントの境界を意図的に設計していました。この意図的な遅延により、インドオフィスでは有能なアジャイルコーチが確保され、米国に拠点を置くBIOS LeSSチームは結束し、BIOS LeSSチーム内で品質と予測の透明性が大幅に改善されたことを示す重要な証拠があったのです。

ミーチャ、Trent、そして私は、根本的な構造的問題を解決するためには、かなりの努力とシャトル外交が必要であることを認識していました。私たちは、構造的な問題を解決するために、危機的な状況に追い込む覚悟はできていました。しかし、残念なことに、ハードウェアを支える副社長をほぼ同時に失い、大規模なレイオフが行われたことで、私たちの戦略は失敗に終わったのです。

アジャイル導入タイムライン」図、「組織構造」図、「MCSハードウェア生成によるBIOS拡張コンポーネントチーム拡張」図を組み合わせて使用すると、これらのさまざまな要素の合流を見ることができます。

サポートシステムの崩壊

私がナカシマMCS部門に在籍していた頃、報告体制、部門資金、従業員数、経営陣が大きく変わりました。

市場シェアが低下し、競争環境が成熟化する中で、MCSの売上は縮小していました。ナカシマの経営陣は、MCS部門を抜本的に縮小することを決定した。その結果、事業部の人数は約半分になった。ナカシマの多くの人が、「ナカシマで見たこともないような大規模なレイオフだ」と言っていた。少なくともBIOSチームの半数は、すぐにレイオフされることになる。

レイオフに先立ち、管理職層の多くが、資金力のある新興企業に引き抜かれることになった。その中には、ミティアがもともと所属していた副社長も含まれていた。ミーチャはその後、もともとスクラムとアジャイルを完全にサポートしていなかったソフトウェア担当副社長に報告をするようになった。私が退職して間もなく、ミーチャは前の副社長に続いて新しいスタートアップ企業に行った。

私はレイオフ後も残りましたが、Trentが私の契約を更新することは政治的に不可能になりました。アジャイルコンサルタントの相場と旅費は、少なくとも2、3人のエンジニアを雇うのに十分な金額です。Trentに任せていれば、私は契約を延長してもらえたかもしれませんが、Trentでさえ、2つ上の層の予算の承認を得なければならなかったのです。それから1年余り後、トレントもナカシマを去った。

結論{#conclusion｝

組織的変化に関する考察

振り返ってみると、エンジニアリング担当のSVPが早期にいなくなったことと、短期的な利益率の急回復に焦点を当てた頻繁なレイオフの文化で長期的な雇用の安全が確保できなかったことが、組織構造と文化の変革で長期的に成功する確率を劇的に低下させたのです。これらの課題がなければ、BIOSコンポーネントでの成功は、より広範なLeSS導入に活用できたと私は考えています。

BIOSのLeSS導入が成功した後、当初のエンジニアリングSVPは、さらに上を目指すために必要な上級管理職の幅広い参加に貢献できたはずだと私は考えています。その代わりに、シニアマネジメントは、差し迫ったレイオフという政治的な状況を切り抜けようと奮闘しながら、近々リリースされるMCSを押し出すために奔走することになりました。もっと早くから積極的な構造改革を行っていれば、非常に有効だったと思いますが、私たちが時間をかけてゆっくりと実績を積み上げていかなければ、関係する上級管理職はそれを受け入れる準備ができていなかったと思います。

種をまく農夫が、さまざまな土壌に広く種をまくというたとえ話を思い出しました。浅い土にまいた種は発芽も成長も早いが、根が張らないのですぐに太陽の下で枯れてしまう。一方、深い土にまいた種は、豊かな実りをもたらす。LeSSを導入する際に土壌を適切に整えなければ、初期には劇的な成功を収めることができても、長期的には問題が発生する可能性が高いのです。BIOSのLeSS採用のための土壌は、初期の素晴らしい結果を生むには十分な深さでしたが、その豊かな潜在能力を発揮するにはまだ十分ではありませんでした。

特典の概要{#summary-of-benefits}.

BIOSチームは、拡張コンポーネントチームから始まり、_拡張コンポーネントチーム、フィーチャーチームへと移行していきました。利点は以下の通りです。

• 拡張されたコンポーネントバウンダリー内で、ローカルに改善された適応性と価値提供を実現する。
  • 事前に観察したこと
    • あるBIOSのサブコンポーネントを理解しているのは、1人か2人しかいなかった。コードの所有権と知識は、事実上、個々のファイルレベルであった。
    • BIOSコンポーネント以外のコードベースに関する知識は、BIOSエンジニアリンググループ内にほとんど存在しなかった。
    • 新しいブレードハードウェアで新しいIntel CPUの世代を立ち上げるために必要な作業の全体を把握している人はいませんでした。BIOSファームウェアエンジニアとBIOSファームウェアテスターは、それぞれ、パズルの小さな一片を理解していただけでした。
  • 以前の影響
    • BIOS エンジニアは、個々の専門領域に制限されていたため、どの時点でも、最も価値のあ る作業を選択することができなかった。
    • 完成を正確に予測することは、ほぼ不可能だった。
  • その後の観察
    • すべてのチームメンバーは、以前より多くのBIOSサブコンポーネントを扱うことに徐々に慣れてきた。
    • 多くのBIOSチームメンバーは、GUIとBIOSコンポーネント間の実行パスに沿って、システム全体のあらゆる面をテストし、修正することにますます熟練するようになっていました。
    • BIOSチームのメンバーは皆、新しいIntel CPUを立ち上げるために必要な作業について、全体的によく理解していた。LeSS指向のBIOSチームのどのメンバーも、BIOSコンポーネントのバックログにあるどの項目も、それが全体像にどう当てはまるかを説明することができました。
    • BIOS コンポーネントバックログは、次期 BIOS リリースの出荷に必要な既知の残作業のすべてについて、常に最新の情報を提供してくれました。
    • BIOSチームは、製品開発の自然な変動性を受け入れ、BIOS Definition of Doneに明示されているように、（スコープではなく）クオリティにコミットした。
  • その後の影響
    • LeSS指向のBIOSチームは、どの時点でも一貫して最も価値のある仕事に集中することができた。
    • BIOSチームは、リリース予測にはるかに自信を持つことができた。
    • BIOSチームは、優先順位の低い機能に取り組む前に、リリース可能なレベルの機能が達成されたことを確認することができた。
    • LeSS指向のBIOS拡張コンポーネントチームは、すべてのSprint IncrementがMCSシステム全体とうまく統合され、テストされたことを確認した。数千人のエンジニアの中で、同様のことを主張できるのは、小規模な診断パイロットスクラムチームだけでした。
• 品質向上**を実現した技術的実践の改善と、さらなる改善への意識の向上
  • 事前に観察したこと
    • 品質基準がどのようなものであるかについての共通の合意がなかった。
    • AMIから提供されたBIOSコードの変更は、MCS固有のコードと混在しており、メンテナンスが困難だった。新世代のIntel CPUは、事実上ゼロから始める必要があった。
  • 以前の影響
    • MCSを新世代のIntel CPUに適合させるために、1年以上とBIOSエンジニアの軍団を要した。インテルが公式に新しいCPUをリリースする前にこの作業を完了できなかった場合、数千万ドルの収益損失が発生する。
  • その後の考察
    • BIOSのDefinition of Doneは、各新BIOSチームによって受け入れられている生きた品質基準である。Doneの定義は、チーム自身によって時間をかけて継続的に明確化、拡張される。
    • BIOS Definition of Doneには、MCS BIOSの変更が可能な限りAMIプラグインレイヤーを活用することを保証するコミットメントが常に含まれている。この賢明な要件は、監督や経営陣からではなく、チーム内部から生まれたものである。
  • その後の影響
    • 技術的な慣習が改善されたことで、次世代 Intel CPU への対応に要する時間が劇的に短縮されることが期待されます。
    • 健全なレトロスペクティブと品質重視の姿勢は、次の改善策を常に明確にする。
• 拡張部品に関連する不具合の早期発見と解決.
  • 事前に観察したこと
    • BIOS ファームウェアのエンジニアは、コードの変更を行い、そのコードを、テストグループ に丸投げしていた。テスト担当者が問題を特定し、BIOSファームウェアエンジニアに問題を投げ返すまでには、通常、数週間から数ヶ月を要した。
    • 自動化されたテストは、ほとんどありませんでした。ほとんどすべてのテストは、非常に手作業で行われていました。
    • コンパイルに問題があるコードをソースコントロールにコミットするのは、一般的な慣習でした。
  • 以前の影響
    • 不具合が発見され、解決されるまでには、通常数ヶ月を要しました。
    • BIOSエンジニアは、他の開発者によってもたらされた破壊的な変更を追いかけるのに、しばしば時間を浪費していました。多くの場合、この作業は、問題が発見されたときにはもう仕事をしていない、離れた時間帯にいる別の開発者によって行われました。
  • その後の観察
    • どのBIOSチームにも、開発および変更のテストを行うためのスキルと知識を持った人がいました。
    • 各BIOSチームは、通常、一度に少数の変更を行うことに集中していた。彼らは、個人としてではなく、実際のチームとして、関連する製品バックログ項目のDefinition of Doneを達成することに積極的に焦点をあてて働いていた。
    • BIOSチームのメンバーは、技術的な知識と専門的な知識の両方において、積極的にお互いを鍛え合いました。テスターはより強い開発者になり、開発者はより強いテスターになりました。
    • 自動テストのレベルを上げ、自動ビルドシステムを導入することで、問題の早期発見をより確実なものにしました。
    • 自動化されたビルドとテストは、従来のチームとLeSS指向のチームとの間で矛盾する優先順位を特定するのに特に役に立ちました。
  • その後の影響
    • 欠陥の発見と解決は、数ヶ月ではなく、数分から数時間以内に行われました。コードフリーズ」後のバグ潰しで何ヶ月も無駄にするのが常だったが、それが全く不要になった。
    • レガシー構造の中で働いていた海外チームの品質に対するインセンティブや目標の矛盾は、海外チームが同じコードベースで仕事をするようになると、非常に見えやすくなりました。時間とマネジメントの継続性があれば、この可視化によって、海外チームの再編成と改善も政治的に可能になっただろうと思う。
• 拡張コンポーネントチーム内の従業員のコラボレーション、エンゲージメント、学習**の改善
  • 事前に観察したこと
    • チームというより個人として働き、各自が個人的な課題に集中していた。
    • チームは、マネージャーが交流や仕事の割り当てを主導・推進する典型的なエンゲージメント・モデルに従っていた。
    • 成長と学習は、個人の責任範囲と過去の専門知識の範囲に限定されていた。 自分の専門性と責任を新しい分野に広げるには、仕事をアレンジし、シフトさせる必要がありました。これには時間がかかり、必ずしも現実的ではありませんでした。
  • 以前の影響
    • 多くの努力と限られた見返り」-ミーチャ
  • その後の観察
    • チームは自分たちで仕事を管理し、自分たちのチームが選んだPBIを実現することに集団的かつ熱心に集中していた。
    • 個人もチームも、自分たちのチームが今集中しているPBIを完成させるために必要なことは、何でも積極的に学んでいた。チーム内、チーム間の知識の伝達の度合いは、以前観察されたものより桁違いに大きい。
  • その後の影響
    • Richard Hackman氏の「Leading Teams」の用語では、BIOSチームは、緩やかに協力する個人ではなく、「真のチーム」として行動していた。各チームは、明確なチームタスク、明確な境界線、自身の作業プロセスを管理するための明確な権限、そして長期にわたるメンバーシップの安定性を持っていました。
• 組織的な阻害要因**に対する認識が深まり、さらに組織的な変革が必要になっている
  • 事前の観察
    • 開発サイクルが長い、不具合発見が遅い、チーム間で頻繁に引き継ぎがある、一人の作業がボトルネックになるなど、様々な問題が普通に受け止められていた。もっと良くなるはずだという意識が希薄。
    • 個々のチームメンバーには、グローバルレベルでの適応性や価値提供に注力する構造的な動機がほとんどなかった。
    • 長年にわたる組織の障害を取り除くための議論や努力はほとんどなされていなかった。
  • 以前の影響
    • グローバルレベルでの適応性と価値提供を改善するための生産的な努力はほとんどなかった。
  • その後の観察
    • BIOSチーム内の定期的なチームおよび全体の振り返りにより、組織的な障害が頻繁に特定され、チームと経営陣はそれを積極的に解決しようとするようになった。
    • BIOSの変更を完全に検証するためのBIOS拡張コンポーネントチームの努力は、コード所有権の境界を挑戦し、複数のコンポーネントにまたがってコード変更を行う能力を拡大させるようになった。
    • BIOS Definition of Doneで明示されたより厳格な品質基準の追求は、レガシーBIOSチームの構造的なインセンティブの矛盾を浮き彫りにするのに役立った。
  • その後の影響
    • 人々は、何が可能か、そしてより大きな組織変革の必要性に徐々に目覚めていった。

ラップアップ

私は、長期的な成功を収めるには、製品の境界を広く取り、製品の全範囲で実行するフィーチャーチームが最適だと考えています。もし「可能性の芸術」がこの選択を排除するのであれば、拡張コンポーネントチームから始めて、拡張コンポーネントチームと機能チームに積極的に移行する漸進的なアプローチは、まだ追求する価値があります。