弊チームのスクラムのモヤモヤ

この投稿について

今のプロジェクトのスクラムに悩みを抱えており、日々問題は大きくなっていると感じる。タイトルに「スクラム」って書いたが、現状スクラムではないと思っている。

具体的な解決には至っておらず、モヤモヤを吐き出すだけのエントリ。

今のプロジェクトについて

新規案件で、立ち上げから1年未満。案件規模はでかい。私には想像できないくらいのお金がかかっているらしい。

私について

2年目。フルスタックエンジニア（...なのか？）
今のプロジェクトには開発初期から関わっている。スクラム歴は1年くらい。

チームの構成

開発者8人、スクラムマスター1人、PO 5人くらい(？？？あとで説明する)

今のチームの課題

ストーリーポイントの誤用
リリース時期と、リリース間でに必要な開発要件がかっちり決まっており、変更が許されない。ちなみにこれは開発者が口出しできない天上人で決められた決定事項である。これがあるため、本来ベロシティを図るための指標であるポイントが、ノルマとして使われている
（例「このスプリントでは何がなんでも〇〇ポイント消化してね」）。
厳格な時間管理
上述した厳格なスケジュール管理が起因して、厳格な時間管理をしている。どういうことかというと、タスクばらしの時に見積もったタスク単位の時間と、開発者が開発に充てられる時間を日々比較して、ノルマを達成可能かを見ている。
時間管理に関しては、目安として使うのであれば悪くはないと思うが、大きく2つの問題を生み出している。
1つは、タスクバラシ時点で明らかに時間が足りないと分かっていても、ポイントは減らせないので、後述する必要な作業時間を削って時間を捻出したり、過度な残業でリカバリしていることである（ちなみに、計算時の稼働時間自体も残業前提で計算）。
2つ目は、進捗が芳しくないと、1日の終わりにPOに対応策を伝える会を開催しなければならず、それ自体が無駄である。

セレモニーに全員で出ない
残業前提でも時間が足りないので、どうするかというと、セレモニーの参加者を一部メンバーに限定するということを行なっている。
特に、リファインメントに一部のメンバーだけが参加しているのが問題を産んでいる。というのも、一般的なリファインメントは2〜3スプリントのポイント見積もりだが、上述したようにリリース時期が決まっているため、リリースまでのバックログ全部のポイント見積もりをしている。
それにはそれなりに時間を要するが、それも一部の開発メンバーで行なっているため、開発者間でも凄まじい情報格差を生み出している。
共有をしなければならないが、厳密な時間管理をしているせいで、その時間がどこにもない。

レトロスペクティブを2スプリントに1回しかやらない
贅沢なことに、一つだけ全員での参加が許されているセレモニーがある。レトロスペクティブである（当たり前）。しかし、残念ながら、これもスケジュールの観点で、2スプリントに1回しか許されていないし、その1回も1時間でやらなければならない。だから、問題が生じていても、改善が遅れるし、改善できない。

POが実質ステークホルダ
POがプロダクトバックログを管理しておらず（システム知識がなく、できないためだと思われる）、バックログ開発者が管理して、POに説明をする。POは要望を言う立場（＝ステークホルダ）。
また、なぜかPOが5人くらいいて、あまり連携が取れていないのか、要件を質問してもスムーズな応答がないことがしばしばある。