nDiki : スクラムマスター

2016年11月17日 (木)

ふりかえりで Lean Coffee やってみた

ふりかえりといえば KPT がメジャーですがスクラムマスターによると「難しい手法だと感じている」とのことで、せっかくなので他の手法をいろいろトライしてみています。今日は Lean Coffee をやってみました。

http://leancoffee.org/

今回のやり方

  1. 話し合うトピックを明らかにする。
    1. 5分間で各自付箋紙に話し合いたいトピックを書く。ふりかえりだけれど内容はプロセスにかぎらずプロダクトの事でも良いとする。
    2. 順番に付箋紙を出して話し合いたいことを簡単に説明する(ここでは議論まで入らないようにする)。
      • 同じトピックを書いた人がいればまとめる。
    3. 付箋紙を眺め、話し合いたいと思ったトピックを各自2つ選び、それぞれしれっとその付箋紙にドットを書く。
    4. 付箋紙をドットの多い順に並べる。
  2. 話し合う。
    1. ドットの多いものから順に1つ取りで7分間話し合う。
    2. 時間になったらそのトピックを続けたいか親指で続ける(上)・終わる(下)・どちらでも(横)で投票する。
    3. 続けるが多いようなら2分延長する。今日は延長は1回まで。
    4. 時間がきたら途中でもそのトピックはいったん終了する(必要があれば別の機会に議論することとする)。
  3. まとめる
    1. 全体の残り時間が無くなってきたところで、今日話し合ったものをふりかえる。それぞれ今後どうするかさっと決める。

雑感

  • 良い点
    • 全員の参加意識と議論への集中度合いが高まる。
    • 決める意欲の多い人がいればその場で何か決まる可能性が高い。
  • 懸念点
    • 検討する時間が短いので、ぱっと出た意見の影響力が強くなりがち。

参加意識が高くなるというのがいいですね。

「時間内で話せるだけ繰り返す」という手法でその時間目一杯使うことになるので、他のミーティングの一部として軽くふりかえりたいというのは向かないということもわかりました。

何回か続けて他の利点・欠点も体感したいと思います。

スポンサード リンク
[ 11月17日全て ]

2016年12月6日 (火)

第7回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログ見積もり

プロダクトバックログアイテム(PBI)の見積もりプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント。

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。

[ 12月6日全て ]

2016年12月20日 (火)

第9回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会9回目。今日は第9章 プロダクトオーナー。

自分がプロダクトオーナーをしていることもあり発表担当をしました。

受け入れ条件の定義と検証

受け入れ条件が満たされていることを確認することがプロダクトオーナーの主な責任の1つにあげられています。これはスプリントレビューで行うのかなと勘違いしていたのですが、プロダクトオーナーによる受け入れ条件の検証はスプリントレビューまで待たずにスプリント実施のときに行うとあり、ここは学びになりました。スプリントレビューでデモが許されているのは完成した機能だけとのことです。

ただ CSM によるとプロダクトオーナーが忙しくスプリントレビューのタイミングになっているところも多いらしいです。

誰がプロダクトオーナーになるべきか

ネットサービス開発は商用開発にあたるので「顧客の声を代弁する社員(プロダクトマネージャーなど)がなる」に相当しますね。

その他の役割と組み合わせ

プロダクトオーナーとスクラムマスターを兼任するのはよくないという点については、それぞれ違う行動指針で動くものだからと CSM がいっていました。確かに。

プロダクトオーナーとして余裕があれば複数チームを担当するのもありと本書には書かれています。私はいま3チームをみているのですが、スクラムのアクティビティにかかる時間的に3チームが限界ですね。2チームまでが適切な感触です。

プロダクトオーナーチーム

チーフプロダクトオーナーという役割が出てきますが、チーフプロダクトオーナーは直接開発チームを見ないようなのでそれってもはやプロダクトオーナーじゃないんじゃないかと思ったのですがどうなんでしょうか。

プロダクトオーナー? プロダクトマネージャー?

勉強会ではプロダクトオーナーとプロダクトマネージャーの違いについてディスカッション。個人的にはスクラムだとスクラムマスターという存在がいるので、プロダクトオーナーの方が少し楽なんじゃないかと思っています(スクラムではない体制におけるプロダクトマネージャーに比べて)。

勉強会参加者にプロダクトオーナーになりたい人はと聞いたところ、やりたい人・やりたくない人双方いました。 CSM は(決して軽視しているわけではないけれども)「プロダクト」よりも「プロセス」の方が面白いからプロダクトオーナーになりたいとは思わないとのことでした。なるほど。

[ 12月20日全て ]

2017年1月10日 (火)

第10回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会10回目。今日は第10章 スクラムマスター

「私は 問題を解決するためにいるわけではない。あなた方が問題を解決できるようにここにいるのだ」

チームに作業を依頼したり、仕事のやり方を指示したりすることもできない。スクラムマスターには仕事を完成させる責任はない。

スクラムマスターコーチのように振る舞いプロセスのリーダーとして支援する役割の人です。

スクラムマスターの存在はスクラムのかなり大きな特徴といえる要素だと思っています。スクラム以外の開発プロセスで同様にコーチ的な役割の人は定義されているのでしょうか。そんな特筆すべきスクラムマスターですが、期待よりかはちょっとあっさりな説明だった感じはします。

誰がスクラムマスターになる?

スクラムマスターの経験豊かな人がいる場合は別として、多くの場合は今いる人の中の誰かになってもらうことになるのでしょう。その場合は

  • ビジネスドメインの専門家の必要はないが技術的知識を理解していること
  • コーチとして質問力がある・辛抱強いこと

が良い条件のようです。

人が少ない場合はどうでしょうか。その場合は複数のチームのスクラムマスターを兼任する形が良く、そうでなければ(有能な人であれば)開発チームメンバがスクラムマスタを兼任するのが良いとのことでした。前の章でも書かれている通りスクラムマスターとプロダクトオーナーの兼任はやめた方が良いとmもあらためて述べられていました。

スクラムマスターはとても1章で全てを語れるものではない奥が深いものなのでしょうね。もし担当することになったら沢山学ぶべきことがありそうです。

[ 1月10日全て ]

2017年3月28日 (火)

第21回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。

スプリントレビュー

スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。

不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。

という、ちょっと最初は勇気が必要なアクティビティです。

この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。

スケジュールの調整

スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。

スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。

きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。

スプリントレビューのアウトプット

リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。

ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。

これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。

デモ

デモが難しいからといって、それはデモをしない理由にはならない。

プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。

スプリントレビューはスクラムマスターと協力してきちんと設営していく必要があるなと感じました。

[ 3月28日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ 4月14日全て ]

2017年7月10日 (月)

スクラムマスターのいるチーム 【日記】

Fire HD 8 タブレット (Newモデル) 16GB

暑いのでお昼は社内販売の弁当

スクラムマスターのいるチーム

やはりスクラムマスターがいるのといないのとでは、スプリントの回しやすさ・プロセス改善のしやすさが全然違うなと感じています。スクラムをやるまでは謎な存在でしたが偉大さがわかってきました。

Prime Dayセール

安くなっていた Fire HD 8 タブレット (Newモデル) 16GB を購入。

シューズ25%オフにつられてニューバランスのウォーキングシューズも買い足し。

[ 7月10日全て ]

2017年8月2日 (水)

何もコミットしないスプリントで各自好きなことをする

インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。

リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。

普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。

ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。

今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。


[ スクラム ]

[ 8月2日全て ]

2017年8月31日 (木)

今日のさえずり: PLAZA をソニプラと呼んじゃうの、オッサンですね

2017年08月31日

  • 12:48 PLAZA をソニプラと呼んじゃうの、オッサンですね。
  • 19:34 「一日ずれていて」「確保できた時間が少なくて」「スクラムマスターが不在で」「新しいメンバがいて」「リファインメント不足で」今日はぐだぐだなスプリントプランニングなってしまった。
  • 23:55 Remember The Milk に Alfred からタスクを追加できるようにした。良い。
[ 8月31日全て ]

2017年10月5日 (木)

見学者がチームに来ることに慎重になった理由

プロセスについて意見が欲しいということでスクラムマスターが別のチームから見学者に来てもらおうとしていたのですが、今回はちょっと気になって反対しました。

一つはまだチームがプロセスを大きく変更したいと思っていないから。チームが大きな課題感を感じていない状態で、変更を前提とした意見をもらっても受け入れられないように思えました。

それからふりかえりの場も見学ということだったのですが、チーム外の人を安直に呼ぶと心理的安全ではない場になって正常なふりかえりにならなくなる恐れが強いも今回は感じました。

まずはチームとして受け入れられるようにしてからのタイミングがいいんじゃないかと今日は思った次第です。

[ 10月5日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.090631s / load averages: 0.38, 0.38, 0.42
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker