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