スクラム開発での立て直し振り返り

ごあいさつ

DWSのみやたんでございます。

以前に記事冒頭で少し触れていた、スクラムマスターとしての立て直しプロジェクトが概ね完了して、大きく体制を変えて次のフェーズへ移って行きました。

今回はその振り返りをしながら、修正して効果があったことをまとめていこうと思います。

私の投稿するブログでは、定期的にスクラムに関連する記事を作成していこうと思います。

スクラムにつきましては、以前に記事を作成しておりますので、「スクラムって何？」という方は、ぜひ以前私が掲載した記事をご覧ください。

立て直しプロジェクトの背景

あるプロダクトのシステム開発を継続して実施しておりましたが、開発担当者がアジャイルでの開発が推進しづらく開発作業に集中できないという状況でした。

そこで、私自身がスクラムマスターとして参画しました。
状況をみて、手法や修正対応を見直しして、立て直しを行なっていきました。

立て直しで効果があったこと

現場で発生していたことを見直しました。
見直しはたくさん実施しておりますが、その中で特に効果的だったものを振り返ってみたいと思います。

1. スクラムイベントにプロダクトオーナー(PO)参加を必須とした
   POが多忙で時間が合わない時はスキップされていた状況でした。
   これを時間を予め確保して必ず参加してもらいました。
   特にレトロスペクティブにおいては、チーム内でPOを含み透明性のある意見交換をすることで、課題のキャッチアップやその対策が進んで、改善に大きく貢献したと感じました。

2. 作業優先順位の調整
   これまでスプリントプランニングがスキップされたり、PO不在であったり、明確な作業優先の決定がなかったものを是正しました。
   スプリントプランニングの実施と、その際にどの作業を優先的に取り組むのかを明示するようにしました。
   これにより、開発者が作業期間で何をやるべきか迷わず、集中して対応できるように改善できました。(実施していない時はタスクが完了後に「次何をやるべきか」という部分で無駄な時間が発生していたように思います。)

3. 別チームとの連携強化
   同じプロダクトを開発する際に、フロントエンド、バックエンド、インフラのチームがわかれておりました。
   いきなり1つのチームにすることが難しい状況だったので、毎日15分間で、各チームの優先順位と技術的な連携会議を実施しました。
   お互いのチームの状況が見える化でき、より優先順位が明確化できたり、早期に課題をピックアップできたことで、プロダクト開発が大きく推進できたと感じました。

まとめ

改善を進めた結果、現場の開発者からは改善されて作業が進めやすくなったという声を聞けました。
また、POからも見えなかった課題やプロダクト開発が大きく進んだと評価をいただけました。
スクラム開発の原則や一般的なルールは大事にしながらも、チーム状況に合わせて改善をするのはとても難しいと感じます。しかし、試行錯誤することを(あえて)楽しみ、失敗しながらも、たくさんの経験を積んで今後も良いプロダクト開発ができる環境を常に追い求めたいと考えています。

最後までご覧いただきありがとうございました。

miyatan