海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

スクラムマスターの成果物

スクラムマスターの成果物ってなんだろうか

個人的にはそのチームそのものかなと。

チームの熟練度?文化?意識?とかが当てはまると思うのだけどうまい単語が思いつかない。

スクラムマスターが仕事をしていくと、段々とスクラムマスターが必要とされない、というか、専任のスクラムマスターがいなくてもいいかな、って瞬間が来る。

チームが課題解決できて、解決方向もアジャイルな意識付け、方向を向いていて、専任で置いとくコストメリットが合わなくなってくる。

専任のメリットは甚だ大きいけど、いなくてもそこそこ回る。嬉しいやら悲しいやら。

お菓子デプロイおじさん、空調おじさん、Slack 絵文字作製おじさんになり始めたら卒業のサイン。

(ぶっちやけその状況だとスクラムマスターとしての学びに繋がる困難/闇/地獄と遭遇しないので、個人的にもコスパが悪かったりする。)

(居心地はいいんだけど)

そういういいチームの状態を作るために、中間成果物としての日々のファシリテーションとか、プロセスとか Teaching/Coaching がある。

けどやっぱりあくまで最終目標とするアウトプットじゃないのかなと。

この辺はスポーツのコーチや子育てと同じかもしれんね。


(追記)逆に、チームを向上させる以外のことを成果物として目標・目的にしてしまうと、絶対に良いことにならない。

手段は目的にはなり得ないし、自分のレジュメのためだけになんらかの手段(プラクティスやプロセスやツールとか)を目的にするのはご法度と思っていい。

JIRA とかにチケットを書くときに気をつける事

チケットを書くうえで絶対に気をつけたい事

実現したい状態を書く。何をやるかではない。

JIRA とかでチケット駆動開発してたりとか、まあ付箋でもなんでも同じなんですが、気をつけなきゃいけないのは、付箋に書いても大抵伝わらないので、完了条件で揉めることが多々あるということ。

依頼した A さんにとっての期待値と、依頼された B さんにとっての 予測値は大抵ずれる。

壊れるほど愛しても 1/3 も伝わらないのにチケットに書いただけじゃもっと伝わらないのが人生。

で、だいたい揉める場合は、

「***する」

みたいな書き方をされてる。

これだと、やったかどうかを評価しがちで、やった後で、出来てる出来てないといった達成度を厳密にするために中世フラスコ画もビックリなレベルで異様に細かい Acceptance Criteria を書き込む羽目になる。

f:id:Bashiko:20190612025655p:plain
中世フラスコ画の雑なイメージ

なので、そのチケットを実行した結果、どういった状態になっていて欲しいのかを明確にして、共有するのがおすすめ。

というか、それを実現するための手法は正直どうでもよくないですかね > 依頼する側の人

とはいえ、どういった状態になっているか、という話も、認識ずれがまだ起こりやすい。

作った人「僕はこれで使えると思う」

みたいな不毛な主張と戦う羽目になってつらい。

なので、誰にとって?っていう視点を明確化するために、ペルソナとかを定義しておくといい。おすすめ。

ついでに言えば、実現手法について変なデザインをしないためにも、

「なぜそれが欲しいのか?」

まで表現しておくと、効率よく伝わる。

何故ならその欲求を満たしているかが判断基準になるから。

ってな情報をシンプルに描き起こせるので、ユーザーストーリーの書き方のテンプレートは、

***として(ペルソナ)

***したい(達成したい状態)

何故ならば***(理由)

っていう形にできてて、広く使われてる。

よく一部(または豪快に全部)の要素を吹っ飛ばしてチケットを書く人も多いけど、その分伝わらないリスクがあるのをゆめゆめ忘れないようにしないと後で泣く。


相手に伝わるかどうかのリスクは、エンジニアリング組織論への招待にて、”通信不確実性” って形で紹介されてた。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

これまでだと Perfect なドキュメントを書く!みたいになりがちだけど、会話の方が情報量多いし、コスパがいいと個人的には思うので、無駄なことしないで、チケット書いて対話するのが一番。

認識する事象と表現された表記が異なるってのはソシュールシーニュシニフィアンと同じ話。

ここに書いている内容もきっと Web 経由では 1/3 も伝わらない。


1/3の純情な感情 - SIAM SHADE


めっちゃどうでもいいけど、スクラムの用語は一般的に伝わりやすい言葉を使っているので、取っ付きやすい反面、誤解されてクソみたいなプラクティス運用されている場面もよく見かけるけど、これもまたスクラムガイドからは伝わりきらない通信不確実性の一つ。(スクラムマスターが機能していなともいう)

大規模にアジャイルをやるにはどうしたらいいか、に対する答え

大規模にアジャイルをやるにはどうしたらいいですか?

答え 大規模にしない

以上終わり。


先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね?って聞かれて出た感想が、「大規模にしない」だった。

ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う

そんなチームのプロセスを同期や依存させる意味あるのかと。

「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね!」

って言われたらどう考えても頭おかしい人でしょ。

依存がいらないところをわざわざ依存させない。

偉い人が同じ?組織上同じだから?

依存を増やしてどうやって変化に対応するのか?

変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか?

そんなことを感じないでもない。


アジャイル界隈で悪名高い?Scaled Agile Framework (SAFe) というものがある。

(現在バージョン 4.6) SAFe 5.0 Framework - SAFe Big Picture

エンタープライズレベルで統率されたアジャイル プロセス を適用するためのフレームワークになっている。

そもそもアジャイルを適用することが目的化している時点で怪しい臭いがプンプンしないでもない。

大抵アジャイルが目的化している組織では、アジャイルプロセスに変化したことが目的化していて、そもそもアジャイルを導入するモチベーションとなるべき、顧客への価値提供の最大化や、リスクの抑制、変化への対応といったことが考慮されず、ただただプロセスが適用されて終わる。

場合によっては、その配下の組織(トレインとかいってたりする)のドメインにおいては、PI (SAFe の計画スパン)がすでに変化に対応できないものになっていたりするがおかまいなしにプロセスが適用され、顧客やビジネスの満足度が下がる始末になるのは明白になる。だって見てないもん。

上位組織の承認がなければ自分たちの活動内容を進めることができない、上位組織の決めたプロセスに合わせることが現場の課題の解決の為のプロセス改善よりも優先される。

場合によっては現場がプロセスを ”適用された” 側となってしまい、なぜそのプロセスなのか、そのプロセスがどう機能していないといけないのかに疑問すら持てないまま、「順調に各トレインが運営されています」とか報告されるだろうと考えると頭が痛い。

まあそんな会社や組織はそのうち潰れるだろうからどうでもいいかもしれないので気にしてもしょうがないが。


SAFe でも LeSS でも NEXUS でも DAD でも Spotify モデルでもなんでもいいが、

「依存のあるチームをまとめて大規模に運営できる」 プロセスは、「チーム間の依存をどうやったら減らせるか」 という、当たり前の視点を奪ってしまいやすい。

依存が切れて独立運営できる方が効率が明らかに高いのだが、それに気づく機会を奪うのは中々罪だな、と思う。

Spotify モデルは組織の枠組みの話だし、明確に依存を減らすアクティビティを儲けると謳っているのはさすがだなとは思う)

同期を取らないと開発進めるの大変じゃん、ていう当たり前の事を知らないと、気にせずこの辺導入してしまいそう。(自戒)


(2020/10/19 追記)

Clean Agile ~Back to Basic~ という Uncle Bob の本を読んだら似たようなことが書いてあったので、参考までに追加。

大規模アジャイルはどうなのか?私はそんなものはないと思っている

大規模なチームの組織化は、小さなチームに分割する問題である。アジャイルは小さなソフトウェアチームの問題を解決する。

小さなチームを大きなチームにする問題はすでに解決されている。

したがって、大規模アジャイルの質問に対する私の答えは、「小規模なアジャイルチームを組織せよ」だ。

この本が先に出てればこんな拙稿捻らなくて良かったのでは、感ある。

スクラムマスターとしてチームの改善をどう助けるか?

スクラムマスターとしてどう改善をフォローするか?

そんな話題が出たのは、私がスクラムチームを支援するにあたり、改善ポイントを考えながらふりかえりでフォローしている、という話をしたときでした。

で、その場にいた別のスクラムマスターの方から、ある人から、ふりかえりでチームが考えた改善を進めてあげるのが大事で、事前に考えるのは違うのでは?とツッコミを受けた。

これ、スクラムマスターとして物凄いさじ加減が難しいとこだと思っている。

チームには自己組織化して問題を見つけ、改善できるようになって欲しい。

スクラムマスターとしては、スクラムマスターがいなくても(ある意味チームが勝手に)改善し続けてくれる状態に持っていくことが一旦の目標だと思う。

そのため、スクラムマスターは、チームに「どうしたいですか?」と考えることを促すことが大事。

一方で、それならスクラムマスター簡単やん!ってことで、チームが改善できる状態に持っていけないまま放置し続けるスクラムマスターも見かける。

"アジャイルコーチ" とは何か

そうですよね,話を聞くふりをして,時たま頷いてみせて,"分かりました。それであなたは今,何をすべきだと思いますか?" とでも尋ねることができれば,それだけで結構な収入になるのですから。

(認定ホニャララ資格が信用出来なくなってきたのと同じかもしれない。)

日々の仕事を思い返すと、スクラムマスターとして参画する場で、チームがスクラムについて成熟しているケースは、残念ながらあまりお目にかかれていない。

大体は2週間の目標を立ててふりかえりと朝会(≠ Daily Scrum)をやってる程度。

ストーリーはバッチリ個人にアサインするし朝会はリーダー(?)への進捗報告の場だ。

当然メンバーがスクラムに精通しているなら外部から呼ぶ必要も無いのでバイアスありありなのだが仕方ないが、そうしたケースで、「ふりかえりはチームに任せる」というのは、スクラムマスターとしてはただの責任放棄に過ぎないと思う。

なので、その状態のチームで、「自己組織化ですから(^-^)」とか言いながら放置するのはどうかと思う。

じゃあ改善点を指示してチームにやらせるのかというと、それもまた放置の次くらいにダメなやり方になる。

瞬間的には改善するがチームとしては「問題に気付く」「原因を考える」「解決策を導き出す」「やると決める」と言った一番大事な、「改善のやり方を学ぶ」機会を奪ってしまいよろしくない。

("ふりかえり" っていう、分かりやすいけど誤解を生みやすい言葉もどうかと思うんだけどね)

スクラムマスターはリーダーシップじゃない(サーバントリーダーシップ)ので、コーチングスキルをフル動員して、チームに気付かせる、考えさせる、encourage する、をしないといけないが、ふりかえりのファシリテーション?フォロー?は、メンバーのメンタルも気にしながらスイートスポットな働きかけが必要になるのでとてもセンシティブだと思う。難しい。

( ´-`)。oO(4歳児に歯磨きを教えるよりは、ラクかも)

スクラムマスターのアプローチにテンプレートが無いのは、育児にテンプレートが無いのと一緒だな、と最近よく思う。アンチパターンくらいしか決められない。

環境も直面する問題も違うのに同じアプローチなんてあるわきゃ無いのだ。

あ、一緒に気付いて考えて勇気付けてチャレンジさせて成長していった瞬間の達成感も育児と同じかな。これは個人の主観がとても入ってるけど。

日々無力感とか詐欺師症候群と闘わないといけないのも似てるな。楽しいからいいのだが。

そういえば、この辺の大事なことは書籍『アジャイルコーチング』によく載ってるから、とても参考になるので困ったら参考になるかもしれないし、ならないかもしれない。

2019/6/1 追記

Teaching と Coaching の違いなのかなと今更ながら思った。

キッズスクールのサッカーコーチと、W杯のサッカーコーチは話す内容が違うじゃん?っていうコラムを見て、まずは走る蹴るを一緒になってやらないといけないから、チームが一人でサッカーを出来るようになるまでは手放しで放置せずに手助けする方がいいという感じだろうか。

アジャイルコーチング

アジャイルコーチング

スクラムマスターを雇う時に聞いてみると良い38個の質問をやってみた

スクラムマスターを雇うときに聞いてみると良い 38 個の質問をやってみた

スクラムマスターを雇う時に聞いてみるとよい38個の質問」というものがあり、昔から知っていたのだが、改めて自分で考える機会ということで書いてみた。

スクラムマスターを雇う時に聞いてみるとよい38個の質問 | Ryuzee.com

※ あくまで自分の経験に基づく考えなので、使えるかどうか(≒採用に値するかどうか?)はわかりかねます。


スクラムマスターの役割について

Q. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

  • ツールやプロセスが大事ではないとは言っていない。あくまで比較の話。

  • ツールやプロセスは、チームが価値を生むまでの一連の作業に、より集中できる為に必要とされる場合がある。

  • 「いつまでにスプリントが終わるんだっけ?」とか、「どうやってスプリントの進捗を見えるようにすればいいんだっけ?」といったトコロにいちいちクリエイティビティを発揮しなくていい。

  • (逆に、ツール・プロセス標準化、みたいな、ツール・プロセスありきは NG だと思う。誰も使わなくなる。)

Q. 自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

  • どうやるか、どこまでやるか/出来たか、といった議論ではなく、デリバリーしたものが期待通り使われているか、デリバリーしたことからの気付きは何か、を考えるようになっている
  • そのために、組織・チームとして、どうすれば(改善すれば)いいのかを考え続けられている

の、2点は、上手く回っている状況だと思う。

Q. 追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

  • チームが直面している問題や、リスクに応じて取るメトリクスは変えるので、必ずこれ!というのはない。

  • メトリクスをとると、観察者効果でよくない影響を与える可能性があるので注意が必要と感じている。

  • ストーリーのサイクルタイムは、チームの効率的な仕事ができているか、どこを改善すれば一番チームの作業効率に効くのか、を考える上で重要な指標になる。

  • ベロシティは、サイクルタイムが改善した結果、わかりやすく表れる指標なので、チームのモチベーションや気づきの意味でも取ることが多い。

  • あとはビジネス的な KPI とかも見ることで、チームが注力すべきことに集中しやすくなる。(売上、VOC、ストアレート etc)

Q. あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

  • コミットしたタイムボックスの長さが、既に計画駆動できないドメインに置かれているため、割り込みが多い
    • 割り込みが多いのに計画でコミットしてしまうのは問題ではないですか?と聞く。
    • (ある程度の)割り込みを前提とするか、タイムボックスを短くする。
    • そもそも PO が直近必要なものを予測/計画できていない場合もあり、PO のお仕事の仕方を一緒に考えることもある。
  • 技術的に、”やってみないと分からない” ものが多いアイテムを扱っている
    • 技術的 Spike と分割することは可能か?を考えてみる。
    • 可能であれば、Sprint を半分の長さにする。(Spike → Ready になった Story としても CT を悪化させないため)
  • チームがコミットメントしないといけないという意識がそもそもない
    • ふりかえりなどで、計画でコミットしたことが終わらなかったことは、私たち/ステークホルダー から見て問題だと思いますか?という問いを投げる。
  • コミット下はいいものの、内容を詳細に見積っておらず、楽観的に開始したまま達成できず、振り返りもできていない
  • 終わるかどうかをトラッキングしていない
    • デイリースクラムで、終わるかどうかをどう考えているかを観察する。
    • どうすれば今日この時点で Sprint が終わりそうだと判断できそうですか?と聞いてみる。
  • メンバーが別の作業と兼務していて、コミットしても状況に振り回されてしまう
    • 本人ではなく、アサインしている?上司?などに、意図を聞き、ムダやコミットできない問題の温床であることを伝える。

Q. 製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

  • 当然参加してよい。プロダクトの要求が、何を狙って決定されたものであるのかを理解することは、ストーリーのカードに詳細な Acceptance criteria を書き込むよりはるかに効率が良い。
  • また、実現方法においては、チームは Professional であるので、より良い解決法が提案できる場合は、アドバイスできるとよい。
  • ただし、チームや PO らは考え方や価値観が異なる場合が多いので、主観で話してしまって対立を生むようであれば、事実ベースで話すように心がけさせる必要がある。(スクラムの話に拠らないですね、これは)

Q. 設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

  • PO が注力すべきでないことに労力を割いているようであれば、それらを分離し、PO 以外の人間でできるように整理する。
  • 学習やディスカバリーに注力できるように、実現手法においてはチームがある程度の粒度の粗さで検討開始できるように、チームのドメインに対する理解や技術レベルを向上させることも長期的には必要になる。

Q. どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

  • 難しい質問。いま接しているステークホルダーが”しかるべき”ステークホルダーであるかどうかを検証する必要がある。
  • この人に聞いても裏の決定者がいるな、とか、デリバリーしたプロダクトに対する要求や不満を発見するのに効率が悪いな、と感じれば、しかるべき人探しをするのが良いと思う。
    • エンドユーザー向けサービスなら、エンドユーザーの振る舞いやインタビューから学ぶこと!
    • 社内にエンドユーザーはいないし、PO もその代わりにはなれない。
    • 幸せの青い鳥探しにならないように。

Q. どのように複数の異なる部門にまたがってアジャイルマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

  • アジャイルを目的にする」と、迷走するし、上手くいかない。目的も共有できないのでうまくいかない。
  • 自分たちが置かれている環境と現状のやり方で、どういった課題があって、アジャイルのどんな考え方であれば、よりよくやれるのか、を説明する。 始めに課題ありき。
  • コーチの初期段階は、上記のように進めて、具体的にやっていく中で、こういった事象は、アジャイルだと当たり前のように捌けてるけど、計画駆動だったら無駄に苦労してたね、っていう点を一緒に気付けてあげられれば、彼らの気付きになる。あとは勝手に広めてくれる。

Q. 上級管理職にどのようにスクラムを紹介するか

  • 必要がないなら、しない。
  • どういう状況に対して、どういう考え方で臨むのか程度は伝えておく。
  • いわゆるスクラムってやつだとイチイチ言わなくてもいいと思う。
  • 上級管理職が 「それスクラムってやつか」と ”自分で” 気付けたら、その時点で敵にならない場合が多い。
  • 「なかま に なりたそう に、こちら を みている!」な上級管理職であれば、積極的に説明して巻き込むこともある。

Q. あなたはすでにステークホルダースクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

  • 上手くやるためにやっていることを共有する
  • そのうえで、スクラムをやる上で、何に懸念や不安があるのかを一緒に明らかにする。
  • トム・デマルコもいう通り、「怒りとは恐怖」なので、彼らの恐怖している内容を共有することが大事。
  • 分かりやすい拒絶に対して、不安を取り除くための活動をすること自体は、他のチームメンバーにとっても、不安を共有し、取り除くことの重要性が伝わるので、心理的安全性の向上に寄与できる場合が多い。
  • 逆に、簡単にその「人」を除外すると、他から見ているメンバーは…後はお察し。

プロダクトバックログのグルーミングと見積りについて

Q. プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか?

流れとしてはよいが、以下の点が気になる。

  • ステークホルダーの要求を分析する段階が無いと、PO が ROI を最大化するための情報が曖昧になる恐れがある。
  • チームのドメインへの理解度か高ければ、要求をチームが理解して PBI にする、といった形も取れる。 チームが受け取るのに Ready (Sprint Ready じゃなくて) であるかどうかは、チームの力量によるので一概には言えないが。
  • また、特にプロダクトの内部改善のための PBI はチームが作る場合もあるので、↑ の流れ以外にはない、というのは誤解を生みやすいので注意が必要。

Q. チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

  • プロダクトに関する VOC の KPI を知ることで、自分たちが優先順位付けする際の議論の情報ベースになる。
  • また、ビジネス目標や競合分析情報を知ることで、チームにいい効果が得られる場合もある。

Q. 誰がユーザーストーリーを書くとよいか?

  • 誰が書いてもよいが、コツがいるので、内容の確認のムダが多いようであれば、教育を要する。

Q. よいユーザーストーリーとはどんなものか?どんな構造か?

  • いわゆる INVEST と言われるものになる。
    • Independent: 他のストーリーと独立している
      • これがないと、優先順位等を考える際にとても無駄が増えるので大事。
    • Negotiable: 交渉可能である
      • どう実現するのか、どこまでやるのかに幅を持っておくことで、PO とチームがお互い効率よく進めるためのやり方を導く余地ができる。
    • Valuable: そのストーリーが単体で価値があること
      • ”**基本設計書を書く” みたいなストーリーの書き方をしても変化に対応できないし何も学習できないノデ、やらないようにしましょう。
    • Estimable: 見積もり可能である
      • 見積れないようなものはエピックと名前を付けて、細分化させた方が良い。
    • Sized small: 十分小さい
      • スプリントの期間内で終わるサイズでないと、レビューできないし、変化にも追従できなくなってしまう。
    • Testable: テスト可能である
      • テスト可能でない時点で、完了したかどうか判断できないので揉める。
      • テスト可能でない時点で、将来的にデグレードしているかを判断できないし、自動化もできない。

これらに加えて、よく、「状態で書くようにしましょう」 と言うことが多い。

実現手段はチーム次第。「~~を実施する」といった書き方だと、期待値を見たいしていなくても良いような書き方になってしまうし、チームも意識できない。

どういった背景で、何を実現したいのか(どういう状態になっていてほしいのか)をチームに伝え、実現手法と効率よくやる方法はチームが考える、でよいし、そこまで PO が踏み込むのはチームに対してリスペクトが無いし、チームとしても自律して考えることを放棄してしまっていてよくないと思う。

Q. 「Readyの定義」には何が含まれているべきか?

  • チームによる。
  • スクラムを円滑に運営する上で増やすこともあるし、チームの Capability が上がって減らすこともある。

Q. ユーザーストーリーを時間で見積もらないのはなぜか?

  • 時間はとても分かりやすい概念で、容易に誤用されやすいため。
    • 「なんで3日の仕事が3日で終わらないんだっけ?」→「それは理想日で、現状のチームの置かれている状況とタスク消化スタイルとしては・・・・・」みたいな不毛なやり取りをするくらいなら顧客を見てコードを書いて障害を取り除く時間に充てたい。
  • そもそも相対見積りするのに単位は必要ないため
  • 日付としての定量評価に使わない単位なら、当たり前だけど付ける理由すらない。

Q. プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

  • バックログに突っ込んで、必要な時に必要なだけ考えましょう?とするだけ。
  • 先々のことまで気を回したい人はいるしそれは性格だからいいけど、「今やるべきこと」に注力して、「今見えていないこと」に早めに気付ける方がリスクが少ない。
  • 今時点で先々まで見通して他に抜け漏れがない!という自信があるなら、計画駆動のウォーターフォールでどうぞ。

スプリントプランニングについて

Q. チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

  • PO と協力して、バックログアイテムを優先度の高い順に並べる
  • ストーリーに背景や解決したい課題を明記して、チームがそのストーリーの価値を理解できるように助ける
  • チームが気付けない・伝わらないことを察知し、改善に向けた下ごしらえを考える。または、その場で簡単な問いかけを行い、気付きを深める手助けをする(初期に2,3回やると、自分たちで気付きやすくなる)
  • 価値の低いストーリーの話題になるようであれば、時間の無駄なので、その会話を今(スプリントのスコープを明確化するための会議で)やる理由があるのか、確認する。

Q. ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

  • ビジネス KPI や VOC のコメント、ユーザーの利用ログを用いて、期待した振る舞いに改善されているかを測定する。
  • かけた工数や、コードの行数はどうでもいい。

Q. チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

  • PO とストーリーを優先順位順に並べ、チームの計画に対して、価値を最大化できるように取り組めているか?を問いかける。

Q. どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

  • チームやプロダクトの状況によるとしか…
  • 経験的に 10%は最低でも必要だと思うし、だいたい毎日1hくらいはみんなやってるんじゃないかなあ。

Q. チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

  • 自己組織化の阻害や、PO 自身がボトルネックになっていることを理解させる。
  • あなたがいなくてもチームが自分で同じ選択をできるようになったら、あなた(PO)はもっとプロダクトの価値発見に時間を割けるようになるし、そうすべきだ、という話をする。
  • 一方で、チームが良い判断をできるようには、どうしたら育つだろうか、という議論を一緒に考える、になる場合が多い。

Q. チームメンバーによるタスクのつまみ食いをどのように扱うか?

  • ムダを生んでいること、チームの生産性を阻害し、残業を生むということを理解させる。
  • サイクルタイムでも測定しておくとわかりやすい。
  • 一方で、なぜつまみ食いしたくなった?というのは尋ねておく。
  • 手が空いたので、、とかであれば、大事な取り組みはつまみ食いではなく、仕掛中のタスクを終わらせるスキルを身に付けたり、調査を進めてあげることだったりする。できることをつまみ食いすることより大事。

Q. ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

  • 終わらせることをコミットできないし、割り込むのであれば、チームのスプリントの達成に向けたコミットメントに対する挑戦行為であることは理解してもらう。
  • 一方で、なぜ1日遅れてしまうのかを共に考える。
    • ひょっとしたら、スプリント期間が長すぎるのかもしれない
    • ひょっとしたら、スプリント開始タイミングが悪いのかもしれない
    • 単純に PO のポカであれば、どうやればうまくできるかを考えた方が良いかもしれない

Q. スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

  • なぜ無駄だと考えるのかを質問する。
  • スプリントプランニングの目的が伝わっているか、確認する
  • 無駄だと感じられてしまうような、チームのスクラム状況の問題を見つけ、ともに改善する

スタンドアップやデイリースクラムについて

Q. チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

  • 推奨する。経験度合いは関係ない。
  • スタンドアップ形式による集中と、長引かせないための仕組みはどのチームでも機能しやすい。
  • タイムボックスを守れないとしたら、そのこと自体についても振り返りで考えられるように仕向ける

Q. なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

  • 期待しない。アンドンでも Slack でも StackOverflow でも Qiita の謎ポエムでもいいから最速で解決されることを望む。

Q. スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

  • デイリースクラムの目的を理解させる。
  • 自己組織化し、お互いのやっていることを共有し、お互いが今日何をやることがベストなのかを考える場であることを理解させる。

Q. スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

  • チームへの悪影響が出ているか、事実として把握する
  • 属人化したタスクの持ち主であったりする場合に見かけることがある気がする。
    • その場合は、属人化しないようなタスクの取り方になっていないことがリスクでないか、考え、属人化せずチームとして機能するようにタスクの選び方を考える場を設ける。
    • そもそもチームのメンバーである必要が無い場合、外すこともありうる。
  • チームになっていないようであれば、チーム構成として必要かを見直す。

Q. スクラムチームのスタンドアップステークホルダーは誰も参加していない。この状況をどのように変えるか?

  • ステークホルダースタンドアップに参加する必要ある?
  • 監視のために出席したいようであれば、チームの状況検査の場において、あなたがいるだけでネガティブな影響となるプレッシャーを持ちうる立場であるということは伝える。
  • それでもひつようなら、カンバンなりバーンダウンを見るように進める。
  • 見ながらも外野からピーチク言うタイプのステークホルダーであれば障壁なので排除する。

Q. 分散チーム間のスタンドアップをどのように進めるか?

  • そもそも分散になってしまう状況と戦いたい
  • 全員が状況に対して同じ認識を持てているか、無駄な時間を使っていないか、F2F なら伝わる機微に気付けないことで問題から目をそらしていないか?を観察する。
  • 可能な限り情報を短時間にリッチに伝える方法を考えると思う。

Q. スクラムチーム用の物理カンバンボードをいま書いてください

  • ストーリーカンバンとタスクカンバンはセットで必要かな。あとは各種チャートも必要なら。
  • チームのプロセスやフローによって変わるので正解はない。
  • 正解や標準があるという認識が不正解、ということだけはいえそう。

ふりかえりについて

Q. だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

  • スクラムチームが楽しく効果的に働くための改善ミーティングであるので、PO も当然参加してよい。
  • たまに PO の存在によって問題の発掘や提示がしにくいチーム状況であれば、軽減するプランを考える。
  • Sensitive な状況だと、Team building のための下ごしらえが必要だったりもする。
  • たまに、そんな下ネゴや信頼関係の醸成に向けた仕事を、酒がすべて解決する場合もある。まあ、それならそれで。

Q. チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

  • 「健全な状態」の定義が難しい気がする。
  • チームが自身で検査して、課題の発見ができているかどうか、それに向けてリーズナブルな解決策を選べているか、を「健全な状態」だと思っているのでそれを確認する。

Q. 過去に使ったふりかえりのフォーマットはどんなものか?

Q. どうやってマンネリを防いでいるか?

  • 持ちよりお菓子を変えたり、アイスブレイクで工夫したり、色々。
  • マンネリ化してきた際に、世の中のカッコイイチームはどんなやり方をしているのかな?といった、ソリューションから入って、自分たちにそれで解決できるポイントって、あるかな?といった気付きに使うチームはいた。

Q. チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

  • チケット切って次のスプリントバックログの一番上に置けって Jeff が言ってた。
  • そもそもそれで解決できると感じていないような場合は、改善策検討までの過程をサポートすることもある。

Q. どうやってアクションアイテムのフォローアップを薦めるか?

  • スプリントに突っ込んだものがやられたかどうか、チームで検査できる。

うん、長い!&タフな質問が多い!

これは確かに、Junior なスクラムマスターを炙り出しやすい気がした。

(炙り出されてるかもしれない)

炙り叉焼食べたくなってきた…