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は、チームが生み出すプロダクトに責任を持つ人
PBIで作るものの仕様や作り方を決めるのはdevチーム自身になるようにする

失敗４：自分だけをふりかえる

B「KPTでふりかえり、やるようになったで！」
C「K『ない』、P『体調不良でタスク進まなかった』、T『体調管理』」
D「K『ない』、P『仕様が分からなかった』、T『Aさんに聞く』」
A「K『ない』、P『質問攻めで仕様考える時間がない』、T『集中時間を作る』」
B「・・・」

何が問題？

ふりかえりへの期待値がばらばら
チームのことをふりかえっていない
課題に対するアクションが、不明瞭

どうしたらよかったか？

期待値の擦り合わせ、なんのためにやるのかを明言/言語化
チームで議論できるようファシる
- スプリント内の出来事をチームで共有し、何をすると、次のスプリントがよりよいものになるかを考える
SMARTの原則

まとめ

ひどいね！

でも、今はもうちょい良く状態に出来ているので、これらは、ただの失敗ではなく成功への軌跡だったのです(ﾄﾞﾔｧ