i-plug Advent Calendar 2019 の【4日目】の記事です
さて、弊社では、今年の４月から、スクラムでプロダクト開発に取り組んでいます。
個人的には、スクラムは２社目です。
スクラム導入辺りの出来事でもまとめようかと思いましたが、そんなものは世間に溢れているので、2社通しての失敗経験でお茶を濁します。
ついでに、今の自分ならこうするよ、っていうのも合わせて載せるので、同じような境遇の方がいれば（いるのか？）、参考にしてもらえれば。
スクラムに関する用語の解説はここではしないので、必要があればGoogle先生に聞いてください。
ちなみに、タイトルは、失敗例をピックアップしたときに「いやいやスクラムやれてないし」と思ったので、付けました。釣りです。
でも、１つ１つは、あるあるだと思うんだよなぁ。
（会話内容などはわかりやすく再構成しています。当時はもうちょいまともな会話をしている、はず）
失敗１：「プロジェクト期間＝スプリント」だった
A「今度やるプロジェクトでスクラムやるで！」
B「ほうほう。どうやってやるん？」
A「プロダクトバックログリストっていうのを作って、上から順番に作っていくんや！リストの中はこれとこれとこれな！」
B「よっしゃ！！スプリント期間どうするよ？？」
A「カットオーバーが3ヶ月後だから、3ヶ月な！」
B「・・・」
何が問題？
- そもそもスクラムに何を期待している？
- 一発勝負
どうしたらよかったか？
- チームみんなで、スクラムへの期待と、それぞれの役割をすり合わせよう
- 必読：スクラムガイド
- プロジェクト期間内で、小さく期間を区切って、定期的に方向性を確認しよう
失敗２：過去はふりかえらない
B「残業だらけでなんとかリリース出来た・・・。どうしてこうなったんや？」
A「うまくいったな！よし、今度はもっと時間のかかる激重プロジェクトや！！今日からプロダクトバックログリスト作っていくで！！！」
B「・・・」
何が問題？
- 残業ありきの計画になっていた
- チームをマネジメントをする人（Aさん）が状況を共有できていない
- スプリントの終わりにふりかえりをしない
どうしたらよかったか？
- スクラムは継続可能なリズムを繰り返すことを推奨しているので、ちゃんとPBIに順位をつけ、無理のない計画としましょう
- あぶれる分は、早めに早めにステークホルダーと調整して、MVPを見極める！
- Aさんの立場次第
- ステークホルダーの場合：チームに判断を任せてもらえるような関係を作る。そして無理なものは無理と言う。
- チームの一員の場合：マネージャーといえど、開発に置いてはフラットという関係を作る。そして無理なものは無理と言う。
- ちゃんとふりかえりを行う時間をとる
失敗３：スクラムマスター兼プロダクトオーナーが、devチームにPBIをアサインする
A「今回のスプリントで何やるか決めるで！」
B「スプリントプランニングやね」
A「Bは機能１、Cは機能２、Dは先週のお残しの続きな！仕様は後でそれぞれに伝えるわー」
B「・・・」
何が問題？
- スクラムマスター（SM）とプロダクトオーナー（PO）の兼任
- ↑のよくわからない存在が、devチームに指示をしている
- devチームが仕様を知らない
どうしたらよかったか？
- SMとPOは、違う人が負うようにする
- プロジェクトマネージャー≠SM、プロジェクトマネージャー≠PO
- SMは、チームがスクラムを推進することに責任を持つ人
- POは、チームが生み出すプロダクトに責任を持つ人
- プロジェクトマネージャー≠SM、プロジェクトマネージャー≠PO
- PBIで作るものの仕様や作り方を決めるのはdevチーム自身になるようにする
失敗４：自分だけをふりかえる
B「KPTでふりかえり、やるようになったで！」
C「K『ない』、P『体調不良でタスク進まなかった』、T『体調管理』」
D「K『ない』、P『仕様が分からなかった』、T『Aさんに聞く』」
A「K『ない』、P『質問攻めで仕様考える時間がない』、T『集中時間を作る』」
B「・・・」
何が問題？
- ふりかえりへの期待値がばらばら
- チームのことをふりかえっていない
- 課題に対するアクションが、不明瞭
どうしたらよかったか？
- 期待値の擦り合わせ、なんのためにやるのかを明言/言語化
- チームで議論できるようファシる
- スプリント内の出来事をチームで共有し、何をすると、次のスプリントがよりよいものになるかを考える
- SMARTの原則
まとめ
ひどいね！
でも、今はもうちょい良く状態に出来ているので、これらは、ただの失敗ではなく成功への軌跡だったのです(ﾄﾞﾔｧ