2016年10月から2017年4月にかけて行った『エッセンシャル スクラム』の輪読会。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。
スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。
スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。
今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。
もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。
完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。
スプリントのキャパシティ = PBI にかけるキャパシティ + スプリントバッファ + それ以外
予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。
今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。
作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。
基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。
完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。
ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。
自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。
スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の20回目。今日は第20章 スプリントの実施。すでに前の章で説明されていることもまた出てきて、そのあたりはおさらいとしてさらりと読むことができました。
誰がどのタスクの作業をするのかはチームメンバの共同責任。どの作業から始めるか開発チームに選択する能力が必要。どの作業から完成させていくかはチームが決めること。開発チーム自身が考えてねという感じです。がんばれ開発チーム。
実際に作業を完成させていくにあたっては「スウォーミング」という聞きなれない言葉が出てきました。
新しいアイテムに着手する前にキャパシティのあるチームメンバが集まって、すでに誰かが着手したアイテムを完成させること。
ということで、動けるメンバで順にアイテムを完成させていきましょうと書かれています。ただ完全にシングルタスクで進めていけばいいかというとそうでもなく「すべてのチームメンバーが同時にひとつのアイテムに取り掛かるのは危険だ。」と書かれており、いい感じに絞ってやりましょうということでした。
ちなみに巻末でのスウォーミングの説明には
ある程度のゆとりと適切なスキルを持ったチームメンバーが集まって、ある項目に対して共同作業(スウォーミング)を行い、新しい項目に着手する前に、すでに進行中の作業を完了させること。
と一見 GNU 的な説明になってました。
デイリースクラムのところには
チームメンバーの最適な作業配分についてみんなで理解する
とありました。「昨日やったこと・今日やること・困っていること」という型ついなぞるだけになりがちですが、きちんとチームとして誰が何をどうやっていくかを共通のものにすることを意識していくことが大切ですね。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。
スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。
不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。
という、ちょっと最初は勇気が必要なアクティビティです。
この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。
スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。
スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。
きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。
リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。
ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。
これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。
デモが難しいからといって、それはデモをしない理由にはならない。
プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。
プロセスをスクラムチームが調査するためのものだ。
2月の第15章 さまざまなプランニング以来、4回目の発表担当です。
半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。
本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。
と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。
付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。
ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。
改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!
なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。
スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。
そんなメッセージを本章から受け取りました。
第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。
「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。
エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。
ふりかえって出てきた話題としては
などが上がりました。
また実際に読む会と並行してスクラムを行ってきた中で
などの話が出ました。
スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。
ストラテジーグループという新しい3人チームでプロセス作りをしています。
3人のうち2人は「エッセンシャル スクラム」を読んでいて例えば「経済的フィルター」と言えばアレのことねとなるのですが、もう1人には今は通じません。「エッセンシャル スクラム」を読んでいないのが悪い、あるいは「エッセンシャル スクラム」用語で話す2人が悪いという話ではなく、同じ言語を共有していると楽だし誤解が無くていいよねという話になりました。
アジャイルサムライでは
11.4 プロジェクトで使う言葉を共有する (pp.228-229)
で説明されていますね(原著だと Create and Share a Common Domain Language)。
そういえば以前部署で「エッセンシャル スクラムを読む会」を続けているうちに例えば PBI で話が通じるようになったりして楽になったなと感じました。
プロセスについてでもプロダクトについてでも、共通の言語をもつ(作る)というのは大切だなとあらためて感じた次第です。
[ opinion ] [ Naney の行動原則 ]
今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャル スクラムの「16章 ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャル スクラムを読む会をやって以来なので久しぶりです。
今回の自分のパートは以下。
「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は
がポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。
仕掛品の戦略は作業中のプロダクトについて
を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。
16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら
だとのこと。参考にします。
やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。
読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。
今のチームでのエッセンシャル スクラムを読む会2回目は技術的負債。
いま対峙しているプロダクトが長期運営されてきた大規模サービスなので、すでに多くの技術的負債・技術的課題を抱えているので、発生の管理もそうですがどう返済していく(あるいはしていかない)かが目下意識していかなければならないことの一つだなと改めて感じました。
知識と共通言語をチームで獲得し事業推進につなげるのを目的に『Hacking Growth グロースハック完全読本』を輪読する勉強会を部内の関係者ですることにした。輪読形式の勉強会はエッセンシャル スクラムを読む会ぶり。
今日は参加者で集まってキックオフミーティング。顔合わせと勉強会の趣旨を確認したあと、進め方を打ち合わせた。各回担当者が事前にまとめたサマリーを発表し、事前に読んできている参加者全員で内容について話し合うオーソドックスなスタイルに決定。
初回は来週から。楽しみ。
ちなみに『Hacking Growth グロースハック完全読本』の新品単行本(紙)はいくつか通販サイトを見た限り品切れになっていた。増刷予定はないのかな?
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。