キーポイント
- Over the years, the Scrum Guide started getting a bit too prescriptive. The 2020 version brings Scrum back to being a minimally sufficient framework by removing or softening prescriptive language.
- The 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex statements as well as removing any remaining inference to IT work, and is now only 13 pages long.
- The 2020 version brings together everyone as one team, the Scrum Team, while previous versions had the Development Team within the Scrum Team.
- The three artifacts, Product Backlog, Sprint Backlog and Increment now contain ‘commitments’ to them. For the Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done.
- It is important for teams to remember that Scrum is still Scrum. Scrum is a framework. It describes the bare minimum to enable a team to work on complex work.
スクラムガイドは、より多くの読者に対応するために、より単純な言語を使用して、より指示的でないように更新されました。これらの変更は、スクラムを「複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワーク」にするために行われました。
2017年と2020年のスクラムガイドの変更点は次のとおりです:
- より指示的でないように
- ひとつのプロダクトに焦点を当てたひとつのチーム
- プロダクトゴールの導入
- スプリントゴール、完成の定義、およびプロダクトゴールの居場所
- 自己組織化よりも自己管理
- 3つのスプリントプランニングのトピック
- より広い読者のための文章の全体的な簡略化
InfoQは、ガイドの変更点と、これらの変更が必要な理由について、Ken Schwaber氏とJeff Sutherland氏にインタビューしました。また、ガイドへの変更のいくつかをより詳細に検討しました: 確約 (コミットメント)、ひとつのチーム、自己管理、プロダクトゴール、およびレトロスペクティブアクションです。
InfoQ: スクラムガイドの2020年バージョンの主な変更点は何でしょうか?
Ken Schwaber氏: このバージョンでは、使用する単語の数を増やす (増やすと事態が複雑になります) のではなく減らしました。また、あまり多くのアイデア (これは混乱を招きます) を絡ませないように努めました。最初のガイドを作成したときは100ページを超えていましたが、現在は13ページであり、ソフトウェア開発者だけでなく、誰でも使用できます。また、指示的でないようにしました。デイリースクラムの3つの質問のようなものは、それらを使用して他の人の混乱を助けるだけであったので、削除しました。業界全体のすべての人が簡単に使用できるように、簡素化に多大な努力を払っています。
主な変更点には、スプリントゴールと完成の定義が作成物 (アーティファクト) になることを含み、プロダクトゴールも追加されました。3つの作成物それぞれに「確約 (コミットメント)」が含まれるようになりました。プロダクトバックログの場合はプロダクトゴールであり、スプリントバックログはスプリントゴールであり、インクリメントには完成の定義があります。
Jeff Sutherland氏: スクラムガイド 2020はより短く、より焦点を絞っており、ひとつのチームがあります。3つの作成物を確約 (コミットメント) のあるゴールに結び付けることに加えて、業界で最大の2つの困難に取り組みました: リードしないサーバントリーダと、確約 (コミットメント) を達成せずにやりたいことを行う自己組織化した開発者です。
サーバントリーダシップと長い間取り組んだ後、私たちはついに語順を変更しました。スクラムマスタは、奉仕するリーダです。Harvard Business ReviewのThe New New Product Development Gameの1986年の論文でスクラムという言葉を使用した野中 (Nonaka) 教授は、上下へのマネージングによる組織変化の触媒であるスクラムマスタが責任を負うと一貫して指摘しています。これにはリーダシップが必要です。
自己組織化は、インテリジェントシステムがゴールを達成するために自己組織化する複雑系理論の概念です。そのため、現在、自己管理という用語を使用して、確約 (コミットメント) を回避するためのツールとして自己組織化を武器にするチームを回避しようとしています。チームは、ゴールを達成するための確約 (コミットメント) を実現するために自己管理します。
InfoQ: スクラムガイドの変更が必要なのはなぜでしょうか? 何がそれを駆り立てたのでしょうか?
Sutherland氏: 私の見解では、新しいガイドは、世界中のスクラムの実施で見つかった最大の問題に対処しています:
- スクラムは現在、ソフトウェア以外で使用されているため、ガイドはソフトウェア固有のものを超える必要があります。
- スクラムチームと開発チームがありました。これはしばしば、プロダクトオーナがチームの一員であると感じず、チームがスプリントゴールを達成するのを助けるチームメンバではなく、ストーリーが完成していないことでチームを批判する状況を生み出しました。また、ソフトウェア以外のチームは、開発チームと呼ばれることを好みませんでした。
- 何百万ものプロジェクトに関するStandish Groupのデータによると、サーバントリーダではスクラムマスタは優れたサーバントであるとの結果になりましたが、58％のリリースできないアジャイルチームの状況を作り出したリーダではありませんでした。スクラムマスタを役に立つリーダとして紹介できることを願っています。
- 自己組織化は、アジャイル開発者が確約 (コミットメント) を達成する必要がないことを意味するように広く誤解されていました。自己管理が組織のニーズを達成することに対してより成熟した態度を生み出すことを願っています。
Schwaber氏: 世界が変化し、はるかに複雑になるにつれて、その複雑さの範囲はますます大きくなっています。スクラムガイドのこの更新されたバージョンは、指示的な文章を削除または緩和することにより、スクラムを最小限の十分なフレームワークに戻すことを目的としています。スクラムガイドを簡略化することで、最終的には人々が使いやすくなります。私たちは、複数のドメインにわたるコミュニティ内の多くの人々と協力して、この点に到達しました。
InfoQ: スクラムガイドの2017年バージョンでは、チームの確約 (コミットメント) が削除されました。2020年版では、ゴールへの取り組みが追加されました。理由を詳しく説明していただけますか?
Schwaber氏: 確約 (コミットメント) は、ガイドとしてではなく武器として使用している人々やチームをよく見たため削除されました。これを2020年に再び追加することは、スクラムチームがこれらの3つの領域 (プロダクトゴール、スプリントゴール、完成の定義) により大きな焦点を当てるために行われました。
Sutherland氏: 早い段階で、チームにスプリントバックログの提供を約束してもらいました。残念ながら、一部のマネージャはチームの速度を武器にしました。彼らは、Edward Demming氏が日本人に教えたことに反して、ポイントをより少なく、時にはより直接的にポイントを提供することで、チームを非難しました。システムには変動性があり、通常の変動性に制御しようとすると、システムは制御不能になります。
そのため、スプリントバックログを提供するために、2017年にスクラムガイドから確約 (コミットメント) を取り除き、見積もりに関する予測を挿入し、スクラムのコアバリューとしてスプリントゴールと確約 (コミットメント) を強調しました。
スクラムガイド 2020では、作成物をゴールに結び付けるために確約 (コミットメント) を使用することにより、確約 (コミットメント) を強化しました。これは、問題をフレーム化するためのシンプルで明確な、より論理的な方法だと思います。
InfoQ: 2020年版では、開発チームについては言及されていませんが、ひとつのチーム (スクラムチーム) について説明しています。この変更は何をもたらすことを意図しており、スクラムを使用しているチームや組織で何が起こることを期待していますか?
Schwaber氏: 目標は、別のチームの概念から開発チームを排除し、代わりにひとつのチームが価値の提供に集中することでした。開発とは別のチームは、プロダクトオーナ、スクラムマスタ、および開発者の間で「私たちと彼ら」の行動を生み出すことができます。開発チームを削除することで、同じ目的に焦点を合わせたひとつのスクラムチームができました。3つの責任は、その目的を達成するためにすべてがどのように連携するかを説明します。
Sutherland氏: Scrum Incのすべてのスクラムチームには、チームに完全に専念し、チームがスプリントゴールを達成するために必要なバックログを実行するのを支援するプロダクトオーナとスクラムマスタがいます。繰り返しの実験を通して、これが最も効果的であることがわかりました。これは、ソフトウェア以外のチーム (運用、販売、マーケティング、サポートチーム、法務チーム、財務チームなど) にとって特に重要です。スクラムガイド 2020のひとつのチームの概念は、この仕事の仕方を反映しています。
InfoQ: 2017年版で説明したように自己組織化されるのではなく、スクラムチームは自己管理することが期待されています。違いは何でしょうか、なぜそれが必要なのでしょうか?
Sutherland氏: スクラムガイドの更新に取り組み始めたとき、自己組織化は業界で最も広く乱用されている用語だと思いました。すべての企業が、自己組織化して自分のやりたいことを実行し、チームのスプリントゴールを達成するのを助けていない開発者がいると言っていたからです。典型的な開発者は複雑適応系理論 (Complex Adaptive System Theory) のトレーニングを受けておらず、その用語を理解していないことに気づきました。自己管理が彼らがよりインテリジェントなシステムのように振る舞うのに役立つことを願っています。
Schwaber氏: 以前のスクラムガイドでは、開発チームを自己組織化と呼び、誰がどのように作業するかを選択していました。ひとつのチームであるスクラムチームに重点を置いて、自己管理型のスクラムチームに重点を置き、誰が、どのように、何に取り組むかを選択します。
InfoQ: プロダクトゴールの意図は何でしょうか? コンセプトはどのように見えますか?
Schwaber氏: プロダクトゴールは、プロダクトバックログのコンテキストを提供します。これは、プロダクトバックログが存在する「なぜ (Why)」と、スクラムチームが作業を行っているなぜ (Why) と考えることができます。優れたプロダクトゴールは、達成に努めるものであり、測定可能であり、スクラムチームとそのステークホルダに可視化されます。
スクラムガイドは、プロダクトゴールの詳細が何であるかを規定しておらず、スクラムチームが状況に合った正しいゴールを形成することを奨励しています。たとえば、一部のスクラムチームは、非常に焦点を絞った四半期ごとのプロダクトゴールに向けて取り組む場合がありますが、別のスクラムチームは、非常に意欲的で焦点が絞られていないプロダクトゴールを持っている場合があります。重要なのは、プロダクトオーナが、作業の明確さとコンテキストを提供し、スクラムチームとステークホルダが理解しやすいプロダクトゴールを形成することです。
Sutherland氏: 私はヨーロッパのトレーナと仕事をしていましたが、彼らは、なぜチームにバックログを与えているのかについてのビジョンがないプロダクトオーナに大きな問題があると言いました。これは、チームにとって重要な意欲を削ぐものです。私がKenとこれについて話し合ったとき、彼はそれを処理する方法は、プロダクトバックログとプロダクトバックログのゴールをさらに具体的にすることで、それは確約 (コミットメント) と結びつけることができると感じました。これは問題の良い解決策だと思います。
InfoQ: 2017年版では、継続的な改善を確実にするための変更が導入されました。これは、プロダクトバックログの前回のレトロスペクティブ会議で特定された優先度の高いプロセス改善が少なくとも1つあることを期待しています。この追加は2020年版で削除され「最も影響力のある改善はできるだけ早く対処されます。次のスプリントのスプリントバックログに追加される可能性もあります」と記載されています。これを変更することにした理由は何でしょうか?
Sutherland氏: Kenはこれをあまり指示的ではないようにしたかったので、私はこの教えをチームのパフォーマンスに不可欠なスクラムパターンに移すことに同意しました。「スクラムのスクラム」というパターンは、すべてのスプリントバックログでレトロスペクティブからひとつの改善があり、チームの失敗を回避するために不可欠です。スクラムガイドにはルールがありますが、プレイブックにはありません。私は10年間、The Scrum Book: The Spirit of the Game に取り組んだので、世界的に合意されたプレイブックを手に入れることができました。
Schwaber氏: スクラムはチームの改善を促します。レトロスペクティブイベントは、彼らがどのように働いているかを見て、改善を提案する時間を提供します。ただし、毎回のスプリントにプロセスの改善を含めることで、スクラムチームに他の形式の価値よりも改善を優先させるようにしています。これは、スクラムチームの残りのメンバと協力しているプロダクトオーナにとって正しい選択ではない可能性があります。これはあまりにも指示的だと感じました。ただし、これは優れたプラクティスであると引き続き信じており、すべてのスクラムチームがそれを検討することをお勧めします。スクラムガイドに記載する必要がないというだけのことです。
InfoQ: チームがスクラムガイドの2020年版に適応するための提案には何がありますか?
Sutherland氏: 私の見解では、スクラムの本質は何年にもわたって変わっていません。スクラムガイドを更新して、問題を明確にし、どの国やドメインのチームでも理解しやすくしました。スクラムガイド 2020は、何千ものスクラムチームがスプリントの最後にインクリメントを提供できなかった原因となったいくつかの誤解に対処しています。私たちの希望は、スプリントの最後に、確約 (コミットメント) - プロダクトゴール、スプリントゴール、および完成の定義 - を達成する成功したスクラムチームの割合を大幅に改善する役に立ちたいことです。
Schwaber氏: チームにとって、スクラムは依然としてスクラムであることを覚えておくことが重要です。スクラムはフレームワークです。チームが複雑な作業に取り組むことができるようにするための最低限のことを説明しています。検査、適応、進化するには柔軟である必要があります。チームは、スクラムガイドで定義されているようにスクラムに従います。もちろん、時間の経過とともに新しいバージョンに移行する場合もありますが、スクラムはまだスクラムであり、変更されていません。今日、何千ものチームがスクラムを補完する手法を使用して、スクラムを自分たちのために機能するように適応させています。
InfoQ: ガイドで行われた変更に基づいて、スクラムトレーナとアジャイルコーチにどのようなアドバイスをしますか?
Schwaber氏: スクラムガイドを読み、それを使用して、顧客が直面する複雑さに対処できるようにします。スクラムはまだスクラムであり、基本は変わっていません。それは依然として、検査と適応の経験主義的思考に基づいてプロセスが進化するフレームワークであり、組織全体の信頼が必要です。いくつかの追加アイテムが追加され、混乱が生じた可能性のあるいくつかの領域が削除されました。変更に関する追加のガイダンスについては、スクラムガイドの変更履歴を確認することをお勧めします。また、基本に焦点を当て、チームに新しい要素を導入することをお勧めします。コーチ、メンター、トレーナなどとしてチームと協力し、チームがチームへの影響とその仕組みを理解できるようにします。トレーナまたはコーチとして、チームがスクラムのアプリケーションを理解し、チームが価値を提供するためにどのように編成するかについてチームが協力するのを支援するのはあなたの役割です。
25年以上前、Jeffと私はソフトウェアプロダクトの提供を支援するためにスクラムを使い始めました。誰もが成功していることに驚いていますが、スクラムを使用して世界をより良い場所にすることができることを願っています。
Sutherland氏: 私は、スクラムトレーナやアジャイルコーチと協力して、トレーニング資料の更新に取り組んできました。スクラムガイドの現在重要となったリーダ、自己管理チーム、および作成物に関連付けられた3つの確約 (コミットメント) を反映するために、プロダクトオーナおよびスクラムマスタクラスのスクラムの表現に小さな変更がありました。プロダクトゴール、スプリントゴール、およびインクリメントの完成の定義を達成するための取り組みは、ますます重要視されます。これにより、人々が最初に優れたスクラムプラクティスをより簡単に実施し、後で多くのことを修正する必要がなくなることを願っています。とはいえ、アジャイルジャーニーは進行中であり、改善は継続しています。それは止まることは決してなく、スクラムガイドの結びの言葉は聞いていません。
インタビュイーについて
Ken Schwaber氏は、Scrum.Orgの会長、創設者、およびスクラムの共同作成者です。Ken Schwaber氏は、複雑な開発プロジェクトに奮闘している組織を支援するために、1990年代初頭にJeff Sutherland博士とスクラムフレームワークを共同開発しました。2001年のアジャイルソフトウェア開発宣言の署名者の1人であり、その後、Agile AllianceとScrum Allianceを設立しました。彼は、ソフトウェア開発の専門性を向上させるという使命を遂行するために、2009年にScrum.orgを設立しました。
Jeff Sutherland博士は、Scrum社の会長、創設者、およびスクラムの共同作成者です。Jeff Sutherland博士は、スクラムの共同作成者であり、Scrum@Scaleの作成者であり、アジャイルソフトウェア開発宣言の署名者の1人です。彼は1993年に最初のスクラムチームを立ち上げ、ほぼすべての業界でその成長を導いてきました。Sutherland博士は、IEEE Digital Libraryに70を超える研究論文を発表し、ベストセラー本 Scrum: The Art of Doing Twice the Work in Half the Time (スクラム 仕事が４倍速くなる“世界標準”のチーム戦術) を共著しています。彼の最新の本は A Scrum Book: The Spirit of the Game です。