スクラムによるプロダクト開発の進め方について話せます

■背景
直近の会社ではエンジニア兼スクラムマスターとして、チームメンバーが全員が未経験の中、0からスクラムの導入を行いました。
プロダクト開発を進める上で、なぜスクラムを導入するのか・スクラムの特徴・今のチームに導入した後どう変化するのかなど、共有会を実施しました。その後も随時、プロダクトマネージャー・デザイナー・エンジニアを対話を続けることで納得感を持って業務を行えることを重視しました。
日常業務ではスクラムイベントのファシリテーションや妨害リストの運用を実施、また移譲していくことで自律的なチームを作っていきました。
チームのフェーズに応じてアプローチを変えたり、カルチャーやチームビルディングの重要性についても話してきました。

その結果、以下の変化が起きました。

・企画と開発のフェーズが別れていて受託っぽさがあったのが、プロダクトマネージャーとエンジニアの壁が薄くなり、相互で納得感を持って開発できるようになった
・期限に迫られる開発だったのが、ストーリーポイントやバーンダウンチャートの導入などにより、進捗やペースが見える化されて課題の検査や、その対応が定量的に判断できるようになった
・振り返りの文化が全くなかったのが、レトロスペクティブやインペディメントリスト（妨害リスト）の導入により改善が進むチームになった
・「楽しくなかった」開発が「楽しい」開発に変わったとフィードバックをもらえた！

■話せること
＜なんちゃってスクラムではなく、守破離の守を守ったスクラムの導入を支援できます＞

最初にスクラムに出会ったのは2019年で、外部から優秀なスクラムマスターの方に入ってもらって開発をしていました。
始めはエンジニアとしてスクラム開発に慣れていく日々でしたが、その後、新規チームの立ち上げ時にスクラムの推進役として２チームの立ち上げを行いました。
その後の会社でも、エンジニア兼任で開発プロセスの改善や推進を期待されて実施してきました。

＜開発のボトルネックを特定し、改善に向けた支援ができます>

今まで、エンジニア（バックエンド・インフラ・フロントエンド）・スクラムマスター・プロダクトマネージャーと複数の役割を経験してきました。
混沌とした状況であっても、多角的な観点から本質を見極め、その会社やチームに合った改善案を一緒に考えることができます。

（エピソード・うろ覚えなので抽象的ですが、、）
以前、別チームで開発がうまく進まないという相談がありました。
ヒアリングしてみると、フルタイムの正社員と業務委託の方が混ざったメンバー構成で、リードタイムが長かったり着手すべきタスクの選定が難しいことがわかりました。
提案として、フルタイムのメンバーが着手すべきタスクと、リードタイムが長くてもいいタスクを切り分けたり、メンバー構成の変更を検討することを提案しました。
その結果、フロー効率が向上し、メンバーの認知負荷も減り改善が見られました。

■その他
・チームメンバーが書いてくださった記事
https://note.com/waaaaall/n/nd93c6b56edd7