「スクラム現場ガイド」を読みました

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

私がスクラム開発を始めて3年弱。この本は「1年目にスクラムとアジャイルで『どんなことが起きるか』についての本」との位置付けですが、会社でこれからスクラムを学んでいこうとする仲間にオススメする前に自分でも読んでみました。

大半のエピソードは自分でも体験したり、よその事例で聞いたことがあるものでしたが、それでも心に残るものがありました。ある程度スクラム開発を経験した人なら誰でも学びがある、オススメの本です。

以下私の印象に残ったエピソードのご紹介です。

2章 仲間とともに旅立つには

アジャイル開発を知り、新プロジェクトでスクラムを取り入れようとした主人公が上司のバックアップは得たものの、仲間探しに苦労する話でした。上司は主人公の支援は約束したものの、チームメンバは主人公が自ら集めることと伝えます。読んでいて「なんでメンバーをアサインしてあげないのかな」と思いましたが、「新しい取り組み・変化に前向きな人を集めないとうまく行かないからだろうな」と、当初は思っていました。

主人公は休暇中にアジャイル開発に関する書籍を読み漁って知識を得たことになっていますが、誘ったメンバには即座の参加を要求していました。これに対して上司が主人公がアジャイル開発を受け入れるように変わっただけの時間が他のメンバにも必要だと諭します。実際のプロジェクトではスムーズな立ち上がりを目指すあまり、「やりながら良さを勉強してよ」というアプローチを取りがちですが、きちんと理解するだけの猶予と用意を与えることは大事だよなと感じました。

21章 文化の衝突

すでにスクラム開発が軌道に乗っているチームに、リソース増強のためチーム文化に合わないメンバーがアサインされるとう話でした。チームは新メンバーを頑張って受け入れようと対話を重ねたものの、新メンバーはスクラムのやり方をどうしても受け入れず、最終的にスクラムマスタはメンバーをチームから隔離し仕事を与えず、元のメンバだけでプロジェクトを進める決断をします。

プロジェクト終了後に上司から呼び出しを受けた主人公は追加リソースを活用してプロジェクトを進めなかったことについて叱責されますが、プロジェクトの完遂をリスクに晒してまで仕事を作ってやるべきだったのかと逆に反論します。スクラムに後ろ向きなメンバがいつまでもチームに残るのは、現実でも割とよく直面する悩みだと思います。

29章 巨大なバックログの見積もりと優先順位付け

スクラム開発をこれから始めようとするプロジェクトが巨大なバックログの作成まではこぎつけたものの、優先順位づけも見積もりもどこから手をつけて良いか分からず途方にくれるという話でした。これに対して経験豊富なコーチが以下の手法を提案します。

1. 広く壁を使える場所を確保する
2. チームにバックログの項目を5つずつ渡し、開発規模の順に左(開発規模が小さい、作るのが簡単)から右(開発規模が大きい、作るのが大変)へ並べてもらう。最終的に全ての項目を並べてもらう。
3. チームに見積もり規模が変わる間を決めてもらう。ストーリーポイントが1と2の間、2と3の間、3と5の間、5と8の間、8と13の間に線を引く。
4. ステークホルダーを全員呼び、線で区切った枠内で優先順に上下で並べてもらう。枠外を超えた移動は無しとする。
5. 開発規模が小さく、優先順位が高いものをバックログの上位に置く。開発規模が大きく、優先順位が高いものは早めにバックログリファインメントに回して分割を試みる。

見積もりの数値はいつも問題になりやすいと感じていましたが、このやり方ならスクラムを始める時でも相対比較ができ、かつ数字を意識する必要がないのですぐにでも取り入れようと思いました。* The Big Wall: Prioritizing and Estimating Large Backlogs - Mitch Lacey & Associates - Scrum and Agile Trainingという手法だそうです。