(導入結果)csチームのスクラムにプランニングは機能しなかった話
概要
csチームにスクラムを導入して、半年が経ち、（自分は別部署だが）スクラムでのプランニングが亡くなったとのことだったので改めてプランニングの意義とcsチームには適用できなかった理由を雑書きする。
経緯
などでcsチームにスクラムを導入する際の難しさ、得にプランニングの難しさに関しては別途記事も書かせていただいていたのですが、どうやら自分が別部署に行ってから数ヶ月後、
プランニングって意味なくない？ってレトロスペクティブにて意見がでた結果無くなったらしいです。
レトロなどは定着しているのですが、プランニングは不要になったとのことでしたので原因を知り、今後に活かしたい（切実）
スクラムガイドを遵守することが効力を最大限発揮させる第一歩という思想に則りcsチームのスクラムでも取り入れていたのですが、機能しなかった理由をまとめたいと思います。
考察
csチームにプランニングが機能しなかったのは主に以下3つが中心なのかと考えております。
- サポート課題とプロダクトゴールが直接的に結びつかない
- プランニング通りにうまく行くことがほぼない
- 未知の課題が多く、工数予想ができない
- デイリーとレトロでプランニング要素を話せている
1. サポート課題とプロダクトゴールが直接的に結びつかない
以前、Q毎の目標をプロダクトゴールにして、そのプロダクトゴールを達成するためにすべきことをタスク単位まで落とし込む作業をスクラム導入時に行ったのですが、その中の一つに入れていた日々のサポート課題というのは、開発と違って、終わりがなく、その課題をやったらプロダクトゴールへどれだけ近づいたかが見えないからプランニングの意義が薄れてしまったのではと思います。
2. プランニング通りにうまく行くことがほぼない
開発のプランニングとは違い、予定外のタスクが入ることがほぼ確実であるcsチームでは、バッファを取ることでプランニングの役割を持たせていました。
しかし、そもそも優先事項の高いものからリリースするとかではなくて、全ての課題に期限日までに答える必要のあるcsチームにおいて、プランニングから外れていて他メンバーに頼っても他メンバーも課題を引き取れず結局プランニングから外れて作業...
などなど、前もって次スプリントのタスクの肌感と引き取り状況などを感じる以前に外れることの多いプランニングをするメリットがないという風になったのだと思います。
3. 未知の課題が多く、工数予想ができない
未知の課題が多く、肌感でも工数をつけることができず、一律同じように工数をつけるなどをしたり、本人達にプランニングポーカーなどを行い、工数管理をするなどの作業が広まらず、なんかついてるけどこれ何？みたいになってそもそも工数管理の重要性が浸透させれていませんでした。
4. デイリーとレトロでプランニング要素を話せている
cs課題は期限日があるのでプランニングというより、デイリーで課題の引き渡しをやったり、レトロで今後の方針を話し合ったりなど、プランニングで行う作業の大抵が他イベントで賄えてしまっているので、プランニングの存在意義がなくなったのだと思います。
今後
csチームのスクラム導入にて、プランニングがなくなったことは何も失敗とかではなく、新たな導入の結果、何が必要かを認識するための時間として、有効だったのではと思います！
その証拠に、レトロとデイリーは今もイベントとして実施されていますし、サポートチームにて少なくとも今は必要ないとなっただけで工数管理をどう行うかの一案にはなったのではと前向きに考え、次に活かせればと思っております！
Discussion