7月16日（水）に開催された、Scrum Boot Camp The Book 読書会 in 札幌 7/16に参加しました。
今回は、Scene 18～20。
チーム内で発生した問題の解決・プロダクトバックログのメンテナンス・Readyについて、と実践編の中でも「現実に問題になりそうなこと」を取り扱う章が多かったです。
“こうすればもっと良くなるのに”を実現するために
「理想のスクラムチーム」と現実とのギャップを把握し、ギャップを埋めるためにスクラムマスターが日々の作業として問題解決をしていこう、という話。
ここを読んで感じたのは、
- 良い状態を知っていないと、理想を描けない
- 一つのやり方しか知らないと、”より良い”という方向に目が行きにくい
- 近づけたい理想を知るためには、良い状態・悪い状態を含め情報のインプットや経験が必要
ということ。
そういう意味で、スクラムマスターはたくさんの経験を積んでいることが強みになると思います。
「妨害リスト」を皆が見えるようにする重要性にも似たようなことが言えます。
“何が大変だと思っているか見せる” 事により、「これって妨害なんだ（改善できることなんだ）」という気づきを周りに与えることができると思うのです。
今まで当たり前にやっていることの中から妨害を探すのって難しかったりするのですよ。
（バグはExcelで管理、とか、ビルドに10分かかるからお茶いれてきます、とか、ウィルススキャンで金曜の午後2時間は作業を止めます、とか）
それが誰かによって「妨害リスト」に上がってくることにより、（あ、これって今より良くすることができるんだ…..!!）って思える人が増えるんじゃないかなあ。
もちろん、各自が自主的に学習することで情報をインプットし、現場が改善されていくことがのぞましいのだけれど、最初の最初のきっかけって自分より広い世界が見えている人の何気ない指摘だったりすると思う。
そういう意味で「見せる」ことはとても大事。
プロダクトバックログを最新に保つコスト
本書では、プロダクトバックログは誰でも（プロジェクトに関わっている人ならば誰でも）自由に書けるようにしておき、こまめに再計画して生きた状態を保つのが良い、と書いてあります。
生きた状態というのは「見積りを最新に」「優先順位をつける」、つまりは「プロジェクトの今の状態が反映されていること」なのですが、通常のスプリントを回しながらプロダクトバックログを最新に保つのって、かなり負担になるのではないか？という印象を受けました。
自発的にやる必要があること、で最も大変なのではないか？と思うのです。
実際に、ホワイトボードでタスク管理（かんばんっぽいもの）を行ったとき、手元の作業にいっぱいいっぱいになってしまい、更新を忘れ、気がついたら設置したボードが死んでしまっている…という経験をしたことがあったから、というのもあります。
この疑問をディスカッションでぶつけてみたのですが、それぞれに負担が少なくなるよう工夫をしている話を聞くことができました。
定期的なイベントに組み込む・常に見える場所に置く・プロダクトバックログを綺麗に保つことを目的にしない等、参考になりました。
意識せずに普段やることとして体に組み込む、慣れの力が大切なのかもしれない。
Readyのこと
Scrumだけじゃなく、タスクに着手するときに「Ready状態」になっていることはとても重要。
曖昧なまま開発を進めるのは、不安だし、手戻りが発生するかもしれないし、できる限り避けたい。
そのために、次のスプリントの準備を一つ前のスプリントの中でやる必要があります。
プロダクトバックログの整備やReady化も行うと考えると1スプリントの中で、純粋にプログラミングをしている時間ってそんなにないのかもしれないなあ。
集中力・瞬発力・タスクの細分化が求められますね。
今回のディスカッションログはこちらです。
https://github.com/ScrumBootCampTheBook-Sapporo/reading/wiki/2014-07-16
次回は8月、終盤に差し掛かってきました。
完走できるよう頑張りたいです。