見出し画像

スクラムガイド2020版での変更点 ~何を変えないといけないか?~

2020年11月に3年ぶりのスクラムガイドの改定がありました。
変更点を自分なりに整理しておきたいと思います。今回のスクラムガイドの改定は、私自身がスクラムで経験し、感じたこととと重ね合わせると実践者の振り返りが反映されたとつくづく感じます。この記事では、私にとってのすっきり腹落ちポイントを中心にまとめます。

スクラムガイド(2020年版)
(英語) https://scrumguides.org/scrum-guide.html
(日本語)https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

2020年版での変更点

すでに2020年版の解説をされているサイトも増えているので、個人的にうれしかった内容での変更点への考察と説明を試みます。

・スクラムの定義

新しくなったスクラムの定義の記述は、”おお、誤解の元になるわかりずらかった点をちゃんと書いてくれた!”と思いました。特に気に入った部分を太字にしてみます。

スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは
詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

スクラムは、フレームワークであることを忘れないようにしたいです。PMBOKも同じくプロジェクトマネジメントのフレームワークであり、スクラムと対立するすものでは全くありません。この辺は、誤解が多いところです。
たとえば、ユーザーストリーもXPもスクラムを実践するためのプラクティスの一つです。”プロダクトバックログアイテム(PBI)は、ユーザーストーリー形式”という決まりはどこにもありません。

・作成物の確約(コミットメント)の明示

確約(コミットメント)が登場しました。ゴールを定義することにより、プロダクトとチームが目指す方向(WHY)がより明確になると思います。

画像1

プロダクトゴール:これは、以前より私が最重要だと思っていたことです。ゴールがないと検査、適応できないことは当然の話ですよね。私が執筆した社内の「アジャイルガイドライン(スクラム)」では100ページ中、50ページはスプリントが始まるまでのゴールと計画策定について解説しています。プロダクトゴールの設定はそのくらい重要だと考えています。

画像2

上の図のように、どの港に向かっているかのゴールが明確になっていないといつまでたっても価値を生み出すことができません。プロダクトゴール自体も、常に最新の状況により更新されることはお忘れなく。

・スクラムマスターとチームの役割の再定義

スクラムマスターの役割が、「サーバントリーダー」から「チーム・組織に奉仕する真のリーダー」というふうに表現が変わっています。これは、サーバントリーダーシップを発揮することで、チーム・組織に奉仕する真のリーダーとなる問うことだと思います。

画像3

要は、プロダクトの価値、プロジェクトの成功/失敗の責任はスクラムマスターにもありますよ。そのために、必死でスクラムチームを誘導してくださいね。ということだと考えています。
また、開発チームという言葉がなくなり、”チーム”は、PO、SM、開発者の3つの異なる責任を持ち、同じ目的を共有するひとつの「スクラムチーム」だけになりました。今まではスクラムチームと開発チームで不毛な定義議論を考えなくてよくなったのはうれしいことです。

結論:今やっているクラムのやり方を変えろというものではない

自分たちのスクラムチームを新しいスクラムガイドで振り返ってみるとよいでしょう。新しいスクラムガイドでのふりかえりとアップデートをしてみたらよいと思います。
スクラムガイドが新しくなったから変えるというものではないです。あと、自分たちが”スクラムあるある”になっていないか?もう一度、胸に手を当てて振り返ってみましょう。

あなたのチームは、”スクラム(アジャイル)あるある”とか”ゾンビアジャイル”になってませんか?
1. スクラムという開発方法論=スクラムイベントがプロジェクト管理、形式的になっている
スクラムマスターがPMとして開発チームに指示出しをしていたり、スプリントバックログがワークパッケージになっていませんか?
そこまででなくても、プロセスに従うことにこだわっていませんか?

2. スクラムマスターがリリースされるプロダクト、インクリメントに対する責任を放棄
リリースされるプロダクトはプロダクトオーナーと開発チームの責任で、スクラムマスターの私には責任がない。ほんとでしょうか?
スクラムマスタのサーバントリーダーシップとは何でしょうか?

3. プロダクトオーナーと開発チームが交渉相手
プロダクトオーナーと開発チーム間の緊張が、けんか腰のやれ、やれないの交渉となっていませんか?

今回のスクラムガイドの進化は?

今回の改定は、どのように・何を(How,What)を削いでより何のための理由(WHY)にフォーカスしたフレームワークとして改良されたものです。全体的には、”スクラム(アジャイル)あるある”とか”ゾンビアジャイル”にならないよう(誤解を排除するために)に、内容がより研ぎ澄まされたのだと思わないですか?

(参考)スクラムガイド2020のアップデートについて (Scrum Inc. Japanの記事)

この記事が気に入ったらサポートをしてみませんか?