自分とスクラム開発について

Scrum Boot Camp OSAKA in June 2018に参加しましたブログを書こうと思い、 序章として「自分とスクラム開発」についての振り返りを書こうとしたら、やたら長くなり、イベント参加ブログどこいったんや状態になりそうなので、分離しておく。

---

• 認定スクラムマスターは取ってない、それ以外の研修も受けてない。
• アジャイルサムライ等のそれ系の書籍は読んだことがある。

上記状態でメーカーのお客さんからの請負で以下２種類のプロジェクトのスクラムを経験した。

１．開発メンバーとして2week*15スプリント

• 顧客がPO,弊社がSM,開発
• 協力会社との混合開発チームかつ、メンバー内のスキル差も大きかったため、開発リーダー的なポジションをすることに
• SMが所謂PL業務も兼任かつ、他プロジェクト兼任だったため、パワーが足りなくなりフォローすることに
• POもスプリント途中からリファインメントのパワーが足りなくなり、開発側でバッグログの詳細化や優先度順まで決めることに

詳細は割愛するが、プロジェクト管理方法も含め上記のような典型的な受託なプロジェクトにスプリントの要素を混ぜ込んだ結果、 タイムリーにプロダクトそのものや開発チームの軌道修正ができたが、非常にシンドい思いをした。

２．POサポートとして1week*4スプリント

• 顧客がPO, 別会社(顧客オフショア先)がSM,開発
• バックログ作成支援ぐらいの気持ちで参画
• しかし自分以外だれもスクラム開発の経験おろか理解していない状態だった。
  • こちらでスクラムイベントの定義をした
  • 開発側での見積もりが完了しないままスプリントがはじまった。見積もりを理解していない
  • 開発側はどの機能が実装できたかを管理できていないままレビューに突入し、デモ発表というよりヒアリング大会になってしまいストーリーが完了したか不明
  • 開発側の技術的な課題も解決しなければならず、何故か実装まで確認することになってしまった

このような状態で強引にスプリントを進めた結果、当然のようにスクラムは崩壊し、中止となった。散々な大失敗であった。

---

振り返ると、変化に適用しながら開発を進めるということは相当高いスキルが求められるものだし、それを遂行していくにもパワーがいる。 そういうことを理解しないまま、スクラムだと後から見直しができるから手戻りが減っていいじゃん、ぐらいの軽い気持ちでやってみると当然失敗する。

なので、スクラムの本質とは何かや、実際の現場で使いこなしている人がどういうことを考え、実践しているのが気になりScrum Boot Camp に行こうと思ったのでした。