スクラムを最小で実施するために、やったこと&やめたこと

Transcript

1. スクラムを最小で実施するために、 　　　　　　　　　　　やったこと&やめたこと 株式会社タイミー　阿部 勇一郎
2. スクラムって難しいですか？
3. なぜスクラムは難しいのか？
4. 難しいのは、本当にスクラムですか？
5. そもそも、プロダクト開発は難しい
6. ちなみに、スクラムガイドを見てみると
7. スクラムガイドによると、 スクラムは軽量級フレームワークらしい スクラムガイド 2020: https://scrumguide-ja.kdmsnr.com/
8. さらに、以下のように述べられている スクラムガイド 2020: https://scrumguide-ja.kdmsnr.com/
9. 最小の仕組みで、最大の価値を生み出す
10. 最小の仕組みからスタートできているだろうか？🤔
11. 実際、そんなことは難しい
12. • 長い年月を書けて作られた会社の規則 • 既存の仕組みに慣れすぎた社員 • 積み上がった様々な負債 • etc…
13. スタートの時点で、抱えてる物が多すぎる
14. 結論... 「スクラムはスタートアップ向きだ。 　我々には合ってない」
15. fin. 〜　さらばスクラムよ永遠に 〜
16. ちょっと待ってください
18. 今やってることが必要なのか見つめ直す 不要なことを捨てる勇気を持つ
19. ということで、本日話すこと スクラムを最小に実施するために、 　　　　　　　　　　　やったこと&やめたこと
20. 阿部　勇一郎( Yuichiro ABE) @razpy 株式会社タイミー - スクラムマスター
22. スクラムを最小に実施するために、 　　　　　　　　　　　やったこと&やめたこと
23. ※ 弊社は設立5年未満のスタートアップなので、 　そもそも、しがらみが少ない & 捨てやすい環境です
24. スクラムを最小に実施するためにやったこと
25. 1. スクラムガイドを読み、守破離の守を大事にする 2. 困った時に最小限
26. 1. スクラムガイドを読み、守破離の守を大事にする
27. • スクラムの骨格について共通理解を育む • 抽象的な表現が多いスクラムガイドでお互いの理解を確認し あえる • よくわからなかった部分を共有しあい、やりながら理解を深 めようという話をしやすい まず、チームメンバーでスクラムガイドを一緒に読む
28. • 弊社はフルリモートなので、miroを使ってます 実際の風景
29. • この疑問を持つために、書かれてることを意識する • 最初から「自分たちにはいらなそう。」っと決めてイベントを実施しないを 選択すると、本当にいらないものを見失う • スクラムが上手くいかないときに、自分たちの既存の仕組みによって上手 くいってない可能性がある ◦ なぜ必要なのか？ ◦ ないことで顧客やステークホルダーへの影響は？ それはスクラムガイドで示されてますか？
30. • 守から外れそうになったときに、スクラムガイドを参照する動 きをする 「でも、スクラムガイドにはこう書かれてるよね」 「スクラムガイドは、具体的なこと指示してないよ」 • スクラムガイドの解釈が不安になったら、認定スクラムマス ターを受講したり、外部のスクラムマスターに相談するのが おすすめ
31. 2. 困った時に最小限
32. 最初のころは、 課題が山積みであれもこれも解決したい！ となりやすい
33. 課題を全部をまとめて解決できる 魔法のようなソリューションがほしい！
34. そんなものは存在しないと諦める
35. 課題を分解して、 なるべく簡単に小さく試せる 解決策を試してみる
36. 思いついた解決策が 上手くいくかもしれないし、上手くいかないかもしれない
37. 世の中にあるプラクティスは、 役にたつかもしれないし、たたないかもしれない
38. 自分たちで実験してみて、 上手くいかなくても、どうやったら上手くやれるか 繰り返し対話と実験して、解決策を見つけるしかない
39. • 実験の試行回数を増やせる • 失敗しても気になりにくい スプリントは短くしており、自分のチームは1週間です
40. スクラムを最小にするためにやめたこと
41. 1. PdMがチームをマネジメントする 2. プロダクトバックログアイテムのフォーマットに拘 る
42. 1. PdMがチームをマネジメントする
43. PdMがチームメンバーと1on1を実施してメンタリングしたり、評 価者になっていた
44. • PdMがプロダクトと向き合う時間が減る • PdMが不在のときに意思決定できないメンタルになる • チームの改善をチームが実施しない
45. 「PdMがマネジメントする」をやめた
46. • チームで意思決定しやすいように、プロダクトゴール&スプリ ントゴールなどで方針を伝えてもらうようにす 　「ゴールで方向性は示されてるから、自分たちで決めてみよう」 　「間違えても、どうすれば認識あわせれるか新たに実験してみよう」 • チームの改善はチームで実施していくように促す 　「その改善アクションは、開発者でもできるよね？」 • PdMに、プロダクトに向き合う以外の時間をさせない 　「ユーザーインタビューに、ステークホルダーとの対話と、プロダクトバックログの検査 など、あなたにしかできあに重要な仕事があるので、それ以外のことに時間を使う余裕 なんてないはずですよ」
47. チームは自分たちで意思決定できるようになった PdMは顧客価値創出のための、ユーザーインタビューなどに時 間を使えるようになった
48. 2. プロダクトバックログアイテムのフォーマットに拘 る
49. 新しいアイディアや課題があったとき 「PBIを起票するのは、なんか重いので書かずに自由にやりたいです」 ※PBI = プロダクトバックログアイテム
50. 「重い」とはどういうこと？🤔
51. PBIがドキュメントのように扱われ、事前に色々な情報を書かされる テンプレートが存在することで、テンプレートを埋めないといけない こんな空気感になっていた
52. 「起票時にテンプレートを埋める」をやめた
53. 「PBIを付箋に書くとして、こんな複雑なこと書ける？」 っという問いかけから、PBIの在り方を考えてもらった
54. PBIを書く際に必須事項を撤廃 テンプレートはリファインメント以降で書く物として活用
55. 活発にPBIを通じて議論が行われるように 何かあればPBIを通じて話が始まるようになった
56. まとめ ・スクラムは、スクラム以外のことのによって難しくなっている ・捨てる勇気を持って、最小限になってるか考える ・スラムガイドは最小限の基本が全て詰まっているので上手く活用する ・守破離の守を示す ・それは守の外側の物だが、本当に必要なのか？考えるキッカケを作る ・勇気をもって「捨てる」 ・「今までこれでやってきた」を如何に捨ててもらえるか ・本当に必要なら、また拾えるはず
57. 上手くいっていることは良いこと スクラムに使われず、スクラムを活用する 間違いを発見する機会をスクラムは提供してくれている その機会を見逃さず、カイゼンを促していく