Shaaron A Alvares: Jeffさん、インタビューの時間を頂いて、ありがとうございます。あなたの活動やScrum@Scaleの状況を拝見していますが、世界中で採用されている公認トレーナプログラムのセットアップで多忙を極めているようにお見受けします。カンファレンス開催のために飛び回ったり、認定トレーナ候補を自らトレーニングもされていますが、それら以外の近況について教えてもらえますか？
Jeff Sutherland: ２年ほど前、Scrum Allianceのリーダが私たちに、スクラムをスケールアップするためのフレームワーク開発に協力してほしい、と依頼してきたのです。当時の私たちは、スクラムチームの人たちだけでなく、ビジネスや役員にとっても有用なフレームワークを求めていました。スケールアップ用のフレームワークはいくつかありますが、Scrum Allianceが考えていたような、組織的なビジネスアジリティをサポートするものはありませんでした。彼らはまた、このスケールアップモデルを、人々がコントリビューションし、フィードバックやケーススタディの共有を通じて発展できるようなものにしたい、と思っていました。さらに、スクラム自体がそうであるように、このスケーリングフレームワークをオープンソースにしたいとも考えていました。
Scrum Inc. はScrum Allianceのリーダと交渉して、2018年の初め、トレーニングの提供とインストラクタの認証を行うジョイントベンチャのScrum@Scaleを設立し、活動を開始しました。
そうですね、本当に忙しいです。私は、Scrum＠Scaleコンテントのチーフプロダクトオーナをしています。基本的には、インストラクタをトレーニングするためのカリキュラムの監督や開発、Scrum@Scaleガイドのコンテンツの作成などが仕事です。世界中でScrum@Scale実践家のトレーニングを提供しながら、新たなScrum@Scaleインストラクタのための"トレーナのトレーニング"全般をサポートしてきました。現在では、世界中に約100名の認定トレーナを擁しています。スクラム創設者によるトレーニングを希望するクライアントや実践家もいるので、Scrum Inc.の一部として、Certified Scrum Masterコースの提供もしています。講演の誘いもありますし、研究や論文の執筆も続けています。
さらに私たちは、新たに２冊の本も書いています。今はちょうど、そのうちの１冊である"The Scrum Fieldbook"のレビューをしているところです。この本は、私の共著者でScrum Inc.のCEOでもあるJJ Sutherlandの手によるもので、企業の役員や大規模組織がスクラムにアプローチする方法や、組織全体にスクラムを展開する方法を考える上で役立つことを目的にしています。現在は予約注文を受付中で、10月に出版される予定です。本書は、2014年に私たちが出版した、オリジナル本である"Scrum: The Art of Doing Twice the Work in Half the Time"の続編になるもので、人々や組織がフレームワークを適用し、実験する方法について、たくさんのケーススタディを紹介しています。
それとは別になりますが、実践家のグループと一緒に、私たちは10年にわたって、Scrum Patternsの書籍化に取り組んできました。この本は最終編集中で、2019年の夏か秋には出版する予定です。スクラムパターンは非常に重要です。ハイパフォーマンスなスクラムを実現するには、スケールアップに取り掛かる前に、チームレベルで推奨パターンを実装する必要がある、ということが分かったからです。 デイリースタンドアップイベントのような、いくつかのプラクティスをつまみ食いしようとしても、それではうまくいきません。推奨パターンをすべて実践できなければ、スクラムのすべてのメリットを得ることはできないのです。私たちは何年もの間、私たちのコースでそのパターンを教えてきました、その一部がドキュメント化された書籍が出版されるというのは、大変うれしいことです。これは重要な成果であって、スクラムとScrum@Scaleの採用を成功させる手助けとなることでしょう。
Alvares: Sutherlandさん、それは素晴らしいですね。どちらの本も、読むのが楽しみでなりません！あなた方はオープンソースを活用して、Scrum@Scaleガイドを一般公開するだけでなく、誰でもGitHubでフィードバックや改善提案を返すことができるようにしていますね。さらに、Scrum@Scaleサイトには、トレーニングされたプロフェッショナルによるケーススタディが数多く含まれています。トレーナやコーチが無償でアドバイスしたり、質問に答えたりする、グローバルな仮想Scrum@Scaleプラクティスコミュニティの構築にも成功していますし、Slackチャネルも一般公開されています。
今日までの活動の中で、オープンソース化によるメリットは、おもに何でしたか？フィードバックの収集や、フレームワークの採用の促進は実現したのでしょうか？
Sutherland: まず最初に、オープンソースにした理由を説明しましょう。1995年、Ken Schwaberと私は、スクラムを正式なものにしました。私はそれを、無償でオープンソースにしたいと思っていました。世界中に早く広めたかったのです。これがスクラムで非常にうまくいったので、Scrum@Scaleでもこのモデルを拡大し、改善することにしたのです。例えば、実践者が認定トレーナになるためには、ケーススタディを提出して、それをオープンソースにする意思を持っていることが必要です。すでに約100件のケーススタディがあります — すべてがWebサイトで公開されている訳ではなく、準備中のものもありますが。1,000件のケーススタディが掲載されれば、さまざまな人たちや組織がScrum@Scaleを、自身の文化や組織に合わせてカスタマイズし、実装した様子がすべて分かるようになります。スクラムと同じく、規範的なモデルというものはありません。フレームワークには適用能力があって、組織による調整の繰り返しを支援しています。さまざまなケーススタディを、私たちのサイトを通じて紹介したいと思っています。既存のほとんどのスケーリングフレームワークと比べた場合、これが大きな違いです。仮想コーチングセッションでも、フォーラムを提供しています。誰でも質問が可能で、課題を共有し、ベストプラクティスをすぐに手に入れられるような、コミュニティが作り上げられているのです。
Alvares: 私が間違っていなければ、あなたは2014年にScrum@Scaleのデザインに着手して、最初のロールアウトを行いました。その後、2018年5月になって、Guideの最初のイテレーションを、Scrum@ScaleのWebサイトでリリースしています。フレームワークを試行し、フィードバックに基づいたプラクティスのデザインを行う中で、さまざまな組織の中で目にしてきた、あなたの考える重要なアンチパターンは何でしたか？Scrum@Scaleでは、それにどう応えようとしているのでしょうか？
Sutherland: そのとおりです。フレームワークの正式版を書き始めて、2014年に、Scrum@Scaleトレーニングのロールアウトを開始しました。既存のスケーリングフレームワークでハイパフォーマンスなチームを手にすることができなかった多くの人たちが、Scrum@Scaleを使ってハイパフォーマンスを何度も実現した方法を文書化するように、私に求めてきました。"Sutherlandさん、あなたのやったことを文書にしてくれませんか。"そこで私は、Scrum@Scaleで実践した、最初の実装と最初のプロトタイピングに立ち返ることにしました。これは1983年に、米国とカナダで150の銀行を運営する、ある大規模な金融企業で行われたものです。
私はそこのCTOで、先進システムを担当するVPでした。最初は数名のリーダクラスのメンバによる自主的参加で始まって、スクラムプラクティスを使った別の運用モデルを採用していました。私は役員に、最も収益の大きいビジネスユニットを選択して、スクラム実践のテストをするように提案しました。最初はセールスやマーケティング、サポート、導入、開発といったATM関連の部署全体を対象に、アジャイルバブルを発生させたのですが、それがよく機能して、成果をあげることができました。スプリント計画ミーティングを毎週実施して、プロダクトマネージャとチームが顔を合わせて、プロダクトバックログの優先順位の設定や、デリバリを完全化するための組織的な障害への対処を行いました。その結果、開発中の機能を毎週金曜日にデプロイできるようになったのです。スクラムだけではなく、Scrum@Scaleのプロトタイプも実施した結果、６ヶ月を待たず、行内で最も収益性の高いビジネスユニットになりました。銀行側がそのビジネスユニットの拡大に対して2,000万ドルの投資を決定したので、Scrum@Scaleをもっと大規模にするための資金が生まれました。
当時目にしたアンチパターンは、非アジャイルなビジネスユニットによる、ウォーターフォール型のリーダシップでした！彼らのプロジェクトはすべて遅延していました。それを修正するため、マネジメントはさらに多くの人材を無計画に投入し、日次や週次のステータスミーティングやレポートによる詳細な報告を要求しました。これらはただ、プロジェクトをさらに遅延させるだけだったのです。
リーダーシップの状況は、現在でもあまり改善されていません。私は定期的に、Scrum Gatheringやアジャイルカンファレンスに参加していますが、最近２回のScrum Gatheringで、200～300名の出席者に対して、"スクラムを実践しているが、マネジメントはウォーターフォール形式で行われている、という人はいますか？"と質問しました。そうすると、そこにいた人たちのほぼ100パーセントが手をあげたのです。つまり、今日に至るまで、私たちはこのアンチパターンを目の当たりにしている、ということです。マネージャやリーダは、一般的なウォーターフォール形式のレポートをすべて受け取りたいのです。それなのに彼らは、それをチームやアジリティとは隔離した形で、スケーリングフレームワークを採用します。この一般的状況は、人々や組織に多大な苦痛をもたらします。それこそが、最も普遍的なアンチパターンなのです。Scrum@Scaleは、このような状況を変えて、エンドツーエンドの変革において、リーダシップが積極的な役割を果たすようにデザインされています。
Alvares: 今の話にもありましたが、大きな変革を妨げる最大の課題のひとつは、組織のリーダを参加させることです。リーダは関心を持っていますし、アジャイルのメリットを望んではいるのですが、それが自分たちのためだとは思っていません。しかも彼らは、一般論として、よりアジャイルで機敏な組織になることよりも、アジャイルを実践すること自体に注目しています。考え方よりもテクニックを重視しているのです。リーダシップの抵抗にあった場合、あなたが用いる"勝利の戦術"は何ですか？例えば、どうやって彼らを、アジャイルリーダシップ向けのトレーニングに参加させているのですか？
Sutherland: そうですね、まず最初に、役員に次のように話すのです。"皆さんはチームがアジャイルであることを望んでいますが、チームだけではうまくいきません。" これは新しい話ではありません。過去60年間、ウォーターフォールの世界でプロジェクトが失敗を重ねてきた最も大きな理由は、組織の問題を是正する上で、幹部社員の協力が得られなかったことなのです。アジャイルプロジェクトでも、これと同じアンチパターンが発生しています。
Scrum@Scaleでは、"Go See"と呼ぶ活動のために、数人のコーチを派遣しています。昨年はToyotaのチームで、適切なアジャイル展開を行うことによって劇的な改善が見込まれるような、組織上の最大の問題を特定することができました。次に、特定したその問題を確認するために、カスタマイズされた役員向けワークショップを開催し、価値と影響の大きさによって優先順位を設定した上で、それらをアジャイルがどのように解決できるかを確認しました。リーダを含めた私たちチームは、変革のためのバックログとそれを実施するロードマップを作成して、最優先課題に取り組みました。続いて、パフォーマンスの高いスクラムバブルを数チームで立ち上げて、スケールアップ前にそれが有効であることをリーダに示すための、ある種の概念実証を行いました。
次には、スケーリングフレームワークの重要な部分として、"Executive Action Team"、つまりEATを導入しました。EATの大きな役割は、障害を食べる(eat)ことです。スクラムチーム内のスクラムとして機能し、チームレベルでは処理できない障害を取り除く最終点であり、プロダクトバックログの最適化、透明性、組織間のコミュニケーションの経路としての役割を担います。
私たちの経験から言えるのは、初期段階から役員の関与を得ることが、変革を成功させる上で不可欠だ、ということです。開始した時点ですべてが必要な訳ではありませんが、組織内にアジャイルを導入することを確約し、実際に機能させる人、あるいは少数の人たちが必要なのです。それを望まないのであれば、ウォーターフォールに留まるべきです。アジャイルに移行したところで、大したメリットはないでしょう。
Alvares: さまざまなカンファレンスで、リーダやチームによる組織のリファクタリングという概念を発表されていますが、どちらについても、マネジメントの考え方を大きく変える必要があります。Scrum@Scaleによると、アジャイルかつ持続可能な組織は、"脆弱な(Fragile)"組織とは対照的に、トレーニングされたマネージャ、要するにリーダが、組織をリファクタすることになっています。さらに、"非脆弱(Anti-Fragile)"組織と呼ばれる、最高に成熟した組織では、組織をリファクタするのはチームの役割とされています。これについて、詳しく説明して頂けますか？アジャイルから"非脆弱"へはどうやって移行するのか、その大きな違いは何なのか、ひとつの状態から別の状態に移行するのには、どの程度の時間が必要なのか、といったことです。それによって起こる考え方の変化は、どのようなものなのでしょう？
Sutherland: プロダクションのバックログに対する生産性を最大化するためには、チームのデリバリを迅速かつ容易にするような方法でチームを編成し、運営することが必要だ、という例を、これまでに何度となく見てきました。一例としてLEGOでは、大規模なプログラムを立ち上げて、チームの人選や構成の決定に6ヶ月を費やした後にスクラムを採用しましたが、うまく行きませんでした。同社はHenrick Kniberg氏を招聘しました。氏はある朝、開発者全員をひとつの部屋に集めました。そこで、プロダクトオーナがバックログを提示して、全員に"チームはどうあるべきか"を問いました。数時間のうちに、全員が組織化のあるべき方法を考え出し、すぐに成果を上げることができたのです。必要なのは、適切なバックログを支える適切なチーム構成であり、適切なチームにおける適切な人たちなのです。チームはクロスファンクショナルで、可能な限り機能指向でなければなりません。そこから直接入力を得ることが、成功には欠かせないのです。
ほとんどの組織では、従来のウォーターフォール型のマネジメントが、アジリティから自らの身を守る手段として、チーム構成やスケーリングフレームワークへのアプローチを決めています。組織をリファクタリングする目的は、組織を調整し、潜在的に再構築することによって、価値のフローを守り、組織的な債務を排除する作業を継続することにあるのです。
"アジャイル成熟状態"のマネージャは、リーダと呼ばれるようになり、そしてプロダクトバックログに取り組むチームを、完全に自己組織化するようになります。リーダ(マネージャ)は、プロダクトの実現とビジネスのアジリティを最高の形でサポートするために、組織のリファクタリングを行う責務を担います。
"非脆弱な成熟状態"では、チームが製品戦略を設定し、プロダクトの方向性を示し、価値のフローを最大化するために組織をリファクタします。リーダはチームの要請に応じて、継続的改善のサポートと実現を行います。このレベルにまで達した組織の数は、まだ多くありません。
要約すると、私たちに必要なのは、初期バックログを作成し、そのバックログに沿ってチームを編成することです。それがScrum@Scaleの基本なのです。現在の目標は、大規模な組織において、半分の時間で2倍の価値を提供可能にすることです。そのためには、まずスクラムを適切に適用すること、次に大規模なデリバリが可能なように組織を編成すること、この２つが不可欠なのです。スケーラビリティの実現には、チームの数は問題ではありません。必要なのは、プロダクションを増やすことです。ウォーターフォールの世界では、チームに人を投入するほどスケジュールは遅延します。それはBrooksの法則であり、ウォーターフォールのアンチパターンです。このアンチパターンを回避するには、スケーラビリティを最大化するように、組織を再設計する必要があります。チームの人数が倍になれば、プロダクションも倍にならなくてはなりません。これは難しいことです。
Alvares: スクラムとScrum@Scaleは、ソフトウェア以外の開発産業にも適用できると言われています。ですが、ソフトウェア開発産業において、エンジニアリングプラクティスとしてのDevOpsとは、どのように統合されているのでしょうか。今日では、ほとんどの組織が、リリースインフラストラクチャのエンジニアリングの手段として、さらにはそれが提供する多くの文化的メリットを目的として、DevOpsを積極的に採用しています。Scrum@ScaleとDevOpsのシナジーは何でしょう、この２つはどのように連携するのでしょうか？
Sutherland: 1983年に立ち返ってみましょう。私が最初に、銀行でScrum@Scaleのプロトタイプを導入した頃です。当時の私たちは、毎週金曜日の午後に、実用的な機能をデリバリしていました。そのためには構築、テスト、さらにデプロイメントも自動化しなくてはなりませんでした。それは今日、私たちがDevOpsと呼んでいるものです。DevOpsとは、最終的には、構築、テスト、デプロイメントを通じて人が関与しない、という意味です。手作業によるプロセスの排除は、常にスクラムの大きな目標でもあります。スクラムの初期の段階から、それは変わっていません。
1995年頃、私は、上場したばかりの企業で働いていました。そこで最初に行ったことのひとつは、毎週デプロイ可能なチームをセットアップすることでした。サーバをサーバルームから運び出して開発ルームに置き、継続的デプロイメントをサポートしたのです。DevOpsは常に、スクラムを支える思想全体の一部でありました。当時の私たちは、スクラムのフレームワークとプラクティスの形式化に取り組んでいました。それらのエンジニアリングプラクティスが、スクラムおよびスクラムガイドの定義の重要な部分になると考えていたのです。Extreme Programmingの作者であるKent Beck氏が当時、私たちと一緒に仕事をしていました。Beck氏と私たちは、氏がエンジニアリングプラクティスを中心とし、私たちがチームやプロダクトバックログ、組織的プラクティスを中心とすることで同意していました。ですから、スクラムが誕生した1983年の時点から、最高のスクラムの実現には、Extreme ProgrammingとDevOpsプラクティスが常に含まれていたのです。
DevOpsは今日おもに、重要な概念のひとつであると理解されています。これはツールベンダが、構築、テスト、デプロイ、運用サポートを完全な自動化な達成に取り組んでいるためです。しかしながら、技術的な卓越性を実現するためには、チームはまずアジャイルでなければなりません。DevOpsはデプロイメントを自動化するツールですが、それによって実現される文化的なメリットの方が重要なのです。
2005年末、私は、"The Future of Scrum: Parallel Pipelining of Sprints in Complex Projects"という記事を書いて、Scrum@Scaleと継続的デプロイメントについて説明しました。この記事は、継続的デプロイメントと運用サポートの自動化を公開した初めてのものです。
Alvares: 特に多数の複雑なインテグレーションに直面している企業が、完全なDevOps自動化やスタック全体を扱うことのできる開発者の採用、組織的な変革への投資に躊躇しているのはなぜでしょうか？私はこれまで、MicrosoftのEnterprise Commerce(ECIT)やGlobal Volume Licensing、ExpediaのBookingデータエンジニアリングチームなど、いくつかの企業で、クロスドメインの複雑なアプリケーションやデータインテグレーションを毎日扱ってきたのですが、彼らはリリースパイプラインに投資するのではなく、自動化のスキルをほとんど、あるいはまったく持たない人材を採用したり、役割を複製してサイロ化したり、手作業をさらに増やすようなことを行っていました。
Sutherland: リーダ層の抵抗、コミットメントやトレーニングの欠如については、これまでに話しました。ウォーターフォール組織のマネージメントは、リスクが高く失敗の多いウォーターフォールを長く実践してきたために、アジャイルがさらなるリスクになることを恐れているのです。アジャイルやDevOpsに関するトレーニングを受けていなかったり、論文を読んだことのないリーダは、適切に導入されたDevOpsやアジャイル転向が価値のフローと利益を増大し、欠陥を削減させるということが理解できません。アジャイルがリスクを大幅に低減することについては、広範な業界データが存在します。アジャイルの成果に関する研究出版物をひとつも読んだことのないリーダが存在するという事実は、世界的に、この業界の大きな機能不全なのです。
第2の側面は、これが重要なのですが、自動化に関するものです。David Rico氏が、構築からテスト、デプロイメントまでのパイプラインの自動化への投資に対する収益を示した、画期的な論文と書籍を発表しています。その中で氏は、投資収益率が72,000パーセントを越えることを証明しました。アジャイルはリスキーで、自動化にはコストが必要だと考えている経営陣は、社内のリリース技術やDevOps自動化に対して継続的な投資を行う企業によって、自らのビジネスを失うことになるでしょう。3,200のスクラムチームを擁して、3秒に1件異常の新機能を市場に提供しているAmazonは、自動化への１ドルの投資に対して72,000ドルの利益を得ているのです。
この説明として、Amazonがドイツ国内でローンを提供し始めた時、ドイツ最大の銀行が、彼らに対抗することは不可能だ、この市場を諦めるしかない、と私に打ち明けたことがあります。"Amazonは数分でローンを処理することができる。数分でリスクを評価してローンを提供できるのだ。数週間を要していたのでは歯が立たない。"そこで、その大規模なレガシ企業の幹部たちは、目を覚まさなくてはなりません。さもなくば、彼らは"Uber"されるか、あるいは"Amazon"されることになるでしょう。UberやAmazonが市場を握ってしまえば、もはや取り戻すことはできないのです。
企業間統合の複雑性に関する第３の側面については、問題そのものに関する、極めて興味深いケーススタディが、Scrum@Scale Webサイトにあります。スマートホーム用IoTに特化したあるイタリア企業のケースでは、ローカルとリモート、３つの外部ベンダを合わせた複数のチームが、ハードウェアとソフトウェアとサプライヤの間の面倒な依存関係を廃城しながら、crum@Scaleを使ってスケールアップした様子が確認できます。約20回のスプリントを通じて、同社は、生産性を18倍に向上することができました。基本的にはScrum@Scaleの導入ですが、複数の組織にまたがっている点が特徴です。
このすべてが、優れたスクラムをベースとした、組織レベルのScrum@Scaleによって推進されることで、プロダクトのより早い、より高品質で、より低いリスクでの提供という目標に、人々を集結させているのです。
Alvares: 組織内でScrum@Scaleを実践し、フィードバックを集めることによって、リーダ、特に戦略や報告を推進する幹部層の、考え方やアプローチのあり方が大きく変わっていきます。それに伴って、一般的なアジャイルの指標も再考するべきでしょうか？指標として使用すべきなのは何で、もはや適切でなく、使用すべきでないのは何でしょうか？
Sutherland: 数年前に、Ciscoの経営陣に会ったことがあります。同社のシリコンバレーの事業所には、約1,000のスクラムチームがありました。彼らはベロシティに関するデータを見せてくれましたが、どのチームも改善されていませんでした。私は彼らに、"Scrum@Scaleのデリバリが改善されていないのは、正しくスケールアップできていないから"だ、と言いました。経営陣はすぐに、いくつかの変更を決定しました。まず、スクラムマスタ全員をトレーニングすること。次に、チームが継続的改善に投資していることを確認することです。
最初の重要な指標は、チームのベロシティです。これは、どのように機能しているのか、プロセス改善とどのように結び付いているのか、どのように改善されているのかを知る上で重要です。
2番めに重要な成功指標は、幸福感の指標(happiness metric)です。私は自身の会社をスクラムで運営していますが、幸福感の指標を使っています。今の働き方について、皆が幸せだろうか？ベロシティが向上しても、幸福感が下がるようでは、結局は行き詰まってしまうのではないでしょうか。望んでいるのは、幸福感を高く保ちながら、ベロシティを改善することなのです。
第3の指標は、非常に重要であり、かつ誰も注目していない、収益です。チームが大量のポイントを提供するのに対して、プロダクトオーナがポイント毎にどれだけの収益をあげられるのか。その数値を高くして、増加させたいのです。プロダクトオーナのパフォーマンスも測りたい部分です。チームがポイントを倍増し、プロダクトオーナがポイント当たりの収益を倍にすれば、収益は400パーセントになる計算だからです。
ですが、私が現在注目している計測値は、2019年3月にこの話題で論文を発表したばかりなのですが、プロセス効率(process efficiency)です。ベロシティの問題のひとつは、チーム間での比較ができないことです。私たちは昨年、Toyotaと仕事をしたので、同社が生産システムで使用している測定値をいくつか試してみることにしました。プロセス効率は、理想的な作業時間を実際の時間で割ったものです。理想的には1日でデリバリ可能な作業が、さまざまな待ち時間のため、完了までに20日を要したとしましょう。この場合のプロセス効率は、1日を20日で割った値、すなわち5パーセントになります。ほとんどのスクラムチームのプロセス効率は10パーセント未満です。例えば、General Electricsのマネージャは、同社のプロセス効率が5パーセントであったということを、私たちに伝えてくれました。プロセス効率の数値を上げることができれば、生産性は飛躍的に向上します。プロセス効率の便利なところは、チーム間での比較が可能なことです。さらに、リーンの定義によれば、プロセス効率は最低でも25パーセントなくてはなりません。従ってほとんどのスクラムチームはリーンではない、ということになります。これは問題です。私は現在、チームレベルでクライアントと協力して、彼らのプロセス効率の解析と向上を支援しています。プロセス効率に注目することで、一部のチームは1回のスプリント内でその向上を実現しました。１スプリントでベロシティを倍増できたチームもあります。
ベロシティ、幸福感、そして１ポイント単位の収益、あるいはプロダクトオーナに対する１ポイント単位の提供価値という、私たちがいつも使用している３つの指標を紹介しました。現在は特に、プロセス効率の向上に注目しています。Toyotaにおいて最高のチームが実現しているように、価値を提供するにはどうすればよいか、ということです。
Alvares : Sutherlandさん、あなたのアジャイル業界で達成した成果は、本当に素晴らしいものです。新たな考え方や働き方、コラボレーションの方法を紹介して、世界中で何百万の人たちに影響を与えました。それとともに、行動の活発さも非常に印象的です。何時に起きて、朝食には何を食べているのですか？
Sutherland (Laughing): 朝はいつも防弾コーヒー(bulletproof coffee、バターコーヒー)で始めるようにしています。新陳代謝の向上や、体重の減少あるいは維持に効果があるからです。朝の始まりにはこれが一番ですね。日中は、ケトダイエット(keto diet)のように、高タンパク高脂肪な食事をしています。エネルギーを高く維持し、行動し続けられるようにしてくれます。
ですが、私の本当のモチベーションとなっているのは、数多くの優秀な企業やチームが、Scrum@Scaleの導入に成功していることです。500のスクラムチームを擁しているIntelの事業部長と話をした時には、同社では"スクラムとScrum@Scaleを使用したこの10年で、生産性を18倍に向上することができた"、と教えてくれました。スクラムが生み出されたのは、このためなのです。このようなサクセスストーリを祝福し、共有することが、私の行動の原動力なのです！
Alvares: スクラムマスタにインタビューした時に尋ねた質問です — スクラムのイベント(セレモニ)の中からひとつ選ぶとすれば、何を選びますか、それはなぜですか？
Sutherland: ひとつに絞るのは難しいですが、最も行うべき重要なことは、バックログを高い準備段階にすることです。その次には、レトロスペクティブでしょうね。私たちは先頃、スクラムガイドで、レトロスペクティブの目的を明確化しました — レトロスペクティブは、次のスプリントで実装されるプロセス改善を確認するためのものです。バックログを準備することができて、スプリント毎に改善を実行できるならば、優れたスクラムチームであると言えるでしょう。
インタビュー回答者について
Jeff Sutherland氏は元米空軍の"Top Gun"で、スクラムフレーム開発者のひとりです。Ken Schwaber氏と共同で1993年に開発され、1995年になって正式化されたこのモデルは、それ以来、世界中で数多くのソフトウェア開発会社によって採用されてきました。Sutherland氏は、今日のビジネスにおけるニーズを満たすために、フレームワークの進化する方向をリードする、中心的な専門家です。そのメリットの実現は、ソフトウェア開発に限定されるものではありません。氏はこの戦略を、金融やヘルスケア、テレコムといった他の産業にも適応させてきました。スクラムとScrum@Scaleは現在幅広く採用されており、生産性の極めて高い開発チームを実現しています。Scrum Inc.の創設者兼代表者として、Scrum@Scaleの開発者として、OpenView Venture Partnersのシニアアドバイザ兼アジャイルコーチとして、Sutherland氏は幹部社員をトレーニングし、世界中の組織とベストプラクティスの共有を行っています。