スクラムガイド変わるってさ:「スクラムガイドを読み解いてみよう」に参加しました

概要

今日Ken SchwaberさんがTwitterで、今秋スクラムガイドが変更されるとのことを発表されていましたね。

発表の前々日2020年8月30日のイベント「スクラムガイドを読み解いてみよう」に参加させていただきました。

こちらのイベントでは、なんらかのコミットを参加者がするようにいろいろな項目を用意して実験されているようです。

Empirical Process Controlを重視したスクラムらしいやり方ですね。
僕はブログ書くよ枠で参加したので、記事を書きます。

どのような会か

スクラムガイドを読み、パーソナリティの皆さんが読んだ部分について議論されていました。
Zoomで行われ、参加者もチャットから質問が可能でした。

記事内容

本記事では、パーソナリティが話されていた内容と僕の感想や意見を織り交ぜて書いております。

今回のイベントで話されていたのはスクラムガイド「スクラムマスター」の章でした。

スクラムマスターの外部の人との交渉

スクラムマスターは、スクラムチームとやり取りをするとき
に役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。

ここはスクラムマスターはスクラム外の人と交渉するような役割を持つよねという話。
でも気になったところとして「役に立つこと/立たないこと」ってなんだろう？という話題に

外部の人がやって役に立つことはいろいろあるけど、役に立たないことについては以下の意見が出ました。

• ステークホルダーのフィードバックの出し方が叱責するようなやり方の場合はスクラムマスターが注意した方がいいのではないか。これはPOだとビジネス上言いにくい場合があるから
• スクラムメンバーを1日借りるねみたいなのがあったら、本当は気軽にスクラムでやってはダメなことなのだから注意した方がいいのでは。つまり、他では当たり前でも気軽にスクラムのルールを破ることに注意する

感想

アジャイルやスクラムの難しいところや肝はマインドセット,考え方だと思うので、スクラムマスターはチーム外の人がチームに対してマインドに反したことをしないか注意しないといけないですね。

チームの中に閉じがちなスクラムマスターの話も出て、チームの外にも働きかけようというのが、スクラムマスターでは大事なのではという話も出ました。
チームに閉じているのは#ScrumMasterWay Level1!。チームの初期段階で頑張っているのかもしれないです。

組織における変革は、アジャイル開発をやるということよりもアジャイルマインドセットを浸透させるということだとよく感じます。

開発手法としてのスクラム開発が容認されても、アジャイルのマインドで何かをすることは容認されていないわけではないことがあります。スクラムでの開発をしていてもビジネスはアジャイルじゃない状況になってしまいます。
例えば以下みたいな？

• 機能分割できるとしても、全ての機能を入れるまでリリースしない。しかし納期は絶対厳守である
• POは最終決定権を持たず、会議で決まった納期、機能をリリースする
• ユーザの意見ではなく会議で決まった予想を重視する
• 進捗確認の会議に忙殺されている
• 開発途中でも良いからリリースしろと言ったり、ドキュメントを早めにだせというということをビジネスパートナーに言い続ける。

アジャイルソフトウェア開発宣言に反するものが多くなりますね。

以前とある会社のイベントに参加して、お話を聞いたときに、僕から見るとアジャイルに開発をしているように見えても、「アジャイル開発をしているわけではない」との答えが返ってきて。ユーザーやビジネスのことを考えると必然的にアジャイルになってしまうのだなと思ったのはよく覚えています。

スクラムガイド読みにくいという話

スクラムガイド読みづらくね？という話に。
海外でもこの傾向があるとのことで翻訳の問題でもなさそう。

• スクラムガイドというからには全てを語っていないのでは？
• バックログと同じように議論を前提としているのでは？

というような意見が出ていました。

感想

僕も正直読みにくいなと思うことが多いですね。
ユーザストーリーのように議論を促すためにそうしているというのは、優しく捉えすぎな気もするw

Ken Schwaberはブログで

The Scrum Guide is a body of knowledge that explicitly defines what Scrum is (and, by default, what it isn’t).

スクラムガイドはスクラムは何かを明確に記した知識体系である(何でないかということも)
とおっしゃっており読まざるをえないですね。

続いて

The Scrum Guide doesn’t tell you how to use Scrum, how to implement Scrum, or how to build products with Scrum.

スクラムガイドはあなたがどのようにスクラムを使うか、実施するか、どのようにスクラムでプロダクトを作るかは書かれていない
とあり、実はここが混乱の元かもと思いました。我々はガイドを読むとき、具体的にどのようにすれば良いかを求めて読んでしまいます。スクラムガイドは使い方ではなく、スクラムのあり方だけが書かれているので、読みにくいのかも。

プロダクトオーナーの支援

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
• スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるように
する。
• 効果的なプロダクトバックログの管理方法を探す。
• 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
• 経験主義におけるプロダクトプランニングについて理解する。
• 価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握しても
らう。
• アジャイルを理解・実践している。
• 必要に応じてスクラムイベントをファシリテートする。

もうアジャイルコーチじゃんとの意見あり。

スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるように
する。

について、ビジネス知識や経験をスクラムマスターは持たなければいけないのかという話に。
でも知識がないといけないというのはティーチングの話であり、コーチングの手法を使えば知識は問題にならないのではという意見がありました。
逆に知識があることでコーチングエキスパートモードになり、余計なことを言ってしまいノイズとなってしまう考え方もあるようです。

明確で簡潔なプロダクトバックログアイテム

こちらでINVESTの話題がでました。

価値を最大化するためのプロダクトバックログの調整方法

締め切りや複雑度などいくつかの項目が決まれば優先度は付けられるのではという話がありました。

感想

チームをコーチングで導くのが良いとされるScrumMasterなので、中途半端な知識でいろいろ言うのはよくないなと反省しました。もともとエンジニアで、技術的な話題の際によく僕も話しますが、中途半端な知識でノイズにならないように心がけるのが良さそうです。

優先度付けの指標

優先度付けの指標や簡潔なプロダクトバックログアイテムの書き方は頭の中に持っておきたいですね。

4 Product Backlog Prioritization Techniques That Work, 機能する4つのバックログ優先づけのテクニック
という記事からKano ModelとMoSCoW Methodが気になったので、調べました。

狩野モデル

狩野モデルは顧客満足度に影響を与えるサービスの品質要素を分類したモデル。1980年代に狩野教授によって提唱された。世界的にはKano Modelとして知られる。

当たり前品質	Must-Be	最低限必要なもので、ないと不満を引き起こす
一元的品質	One-Dimensional	充足されると満足、ないと不満になるもの
魅力品質	Attractive	充足されると満足になるが、なくても仕方ないと思われるもの
無関心品質	Indifferent	充足、不充足で満足度に影響ないもの
逆品質	Reverse	充足すると不満になり、不充足なら満足になるもの

UXを設計するときにも使われるみたい(Kano-Modelの使い方)

MoSCow method

MoSCoWメソッドはDai Cleggさんによって開発された優先付け手法。マネジメント、ビジネス分析、ソフトウェア開発で利用される。

Mo	Must have	入らないとリリースできない
S	Should have	重要だがリリースに必須ではない
Co	Could have	望ましいが、必須ではない。時間があればやるやつ
W	Won't have	重要でなく見返りが小さいとステークホルダーと合意されたもの

英語の文法の勉強になりそう。

簡潔なプロダクトバックログアイテムの書き方

バックログというよりはユーザーストーリーの話ではありますが、INVESTは以下です。

Independent	独立していること
Negotiable	交渉可能・一度決めたら絶対ではない
Valuable	価値がある
Estimable	見積もり可能(な粒度)
Sized right(Small)	適切な大きさ
Testable	テスト可能

スクラムマスターはサーバントリーダ?

スクラムマスターをサーバントリーダと書くのはよくないのでは？という話も
サーバントリーダーの項目は最近追加されたようです。(スクラムガイドの変更履歴)

どうやらmanagement 3.0の話でそういう話があるようです。

感想

Management3.0については、Management 3.0 - マネジメントとリーダーシップのスライドがわかりやすかったです。やはりManagement2.0が「サーバントリーダー」ですね。

サーバントリーダ

結局サーバントリーダはなんなのでしょうか？

Servant leadership : How to lead with the heart ? | Liz Theophille | TEDxSaclayこちらのTEDでは、傾聴、共感できることとフィードバックを求めることと言っています。

従来の支配型との対極との視点で語られることも多いです。(BIZHINT)

greenleaf.orgによると

The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.

サーバントリーダは力を共有し、他の人が望むことを第一として、彼らが成長しもっとも高いパフォーマンスができるよう助ける。

リーダーであることよりも与えることを考えるのがサーバントリーダー！

組織へのスクラムの導入方法を計画できないとスクラムマスターじゃない？

「組織へのスクラムの導入方法を計画する」これを出来るレベルの人がスクラムマスターをするってことですか?

というものが質問され、議論が始まりました。

スクラムガイドに書かれていることをスクラムマスターの必要条件と考えると大変という話もあり。

でもそういうふうにできなくても良いと考えるとスクラムマスターの価値、イメージが下がるのではないかという話もでていました。
スクラムマスターの資格が比較的取りやすいという話もでていました。
昔は試験でもある程度の人数を落としていたようです。

なので結論としては、「組織へのスクラムの導入方法を計画する」ことができることはスクラムマスターの必須条件！

感想: 俺流スクラム導入

イメージとしてはウォーターフォール的な開発や納期が大好きで、めっちゃ上の人がマイクロマネジメントしてくるような組織へのスクラム導入をイメージしてます。そんな組織はイメージしやすい(笑)。

1. スクラムに興味を持った人に話をしてどのような思いでスクラムをしようと思ったか聞く。
2. マネジメント層にアジャイルやスクラムのマインドセットの説明をする。
3. パイロットプロジェクトをスクラムで作る。社内でスクラムに興味がある人に機能横断的チームを作ってもらう。
4. パイロットプロジェクトを成功させ、小さな成功体験を組織に作る。成功体験やこれまでの業務との違いをチームメンバーに語ってもらう。
5. スクラムを広めていく

こんな感じでしょうか。

組織導入するぞとなったからには、ある程度組織で発言力のある人がスクラムに興味を持っていると考えられます。
その人を中心としてマネジメント層に今の世の中でのアジャイルマインドセットのビジネス的な良さを少しでも多く確信してもらうのがスタートです。
有名なアジャイルコーチの方に助けてもらったり。

パイロットプロジェクトでマネジメントと協力してなるべく現在の権限や慣習から独立した状態でチームを作ると良いと考えています。
マイクロマネジメント大好き組織では、従業員を縛るルールや慣習が既に存在するため、そのルールが適用されるほどアジャイルやスクラムは失敗します。

なんとかパイロットプロジェクトを成功させたいですね。成功体験が作れればあとは少し後押しするだけで成功者に任せれば大丈夫。

簡単にうまくいくわけではないでしょうが、僕の中のスクラム導入のパスのイメージは以上です。
ポイントはマネジメントの協力と成功体験ですね。

終わりに: スクラムガイドも変わり続ける

今日Ken SchwaberさんがTwitterやブログで、今秋スクラムガイドが変更されるとのことを発表されていました。世の中に応じてスクラムガイドが適用していくのは自身の価値観を反映していますね。
現代に生きるものとして変化は歓迎です！