はじめに
今回はサービスインの日程が既に決まっている新機能があり、新機能の開発はチームの全工数を投入しても間に合わない。
そんな状況において、スクラムマスター私氏がどんなアプローチをしたかを書いてみようと思います。
結果的には無事サービスイン出来たのですが、スクラムにおいてアンチパターンとされる対応もあり改善点は幾らでもあります。
読んでいただいた方に自分だったらこうするのに、みたいなことを考えるきっかけになればと思ってます。
状況の説明
プロダクトの大まかな状況は以下みたいな感じです。
- プロダクトの開発体制はScrum of Scrumsを採用し３チームで運営
- 3rdParty製アプリとコラボした新機能を初めて開発
- 新機能のサービスインまで2.5ヶ月(2週間スプリントなので5スプリント)
- 新機能の見積り結果はざっくり8スプリント
- 着手時点で3rdPartyとの契約は完了しておらずTBDも多数
着手時点で炎上の気配。🔥
やったこと
スクラムマスターとしての仕事もそうでない仕事も含まれていますが、時系列に書いていきたいと思います。
バックログを細分化してみた
8スプリントかかるバックログにも関わらず、最初は1つのバックログでした。
これだと開発時に混乱することが明らかなので、バックログを以下のように15個に細分化。
良かったこと
- サービスの中機能以下が見える化され、プロダクト内で共有(共通言語化)できた
- 機能の実装漏れを防ぐことができた
- サービスイン可能な状態を明確化する際に役立った
悪かったこと
- この作業をスクラムマスター手動でやってしまった
取り組み自体は良かったんですが、この作業をプロダクトオーナー主導ですべきでした。名義上はバックログ管理者をプロダクトオーナーに引き継いだんですが、実情はスクラムマスターの私が管理する形に。
これによって後々弊害が出てきます。
サービスイン可能な状態を明確化した
細分化してみると「これってサービスイン後でも良いよね」みたいなのが結構あることが見えてきました。
ということで、サービスインに必要なものとそうでないものに分け、そうでないものをリリース時期で更に2つに分類。それぞれのバックログの数は以下となりました。
1. サービスイン時に必要なもの：6個
2. サービスインの1ヶ月後に必要なもの：7個
3. サービスインの2ヶ月後以降に必要なもの：2個
良かったこと
- サービスインに向けてやることが明確になった
- (なんとなく)サービスインさえ乗り切れば何とかなると思っていたが、その1ヶ月後にも山があることが分かった😞
悪かったこと
- 特になし
強いて言えば、この時点でそれぞれのバックログの管理者をプロダクトオーナーに完全に引き渡すべきでした。ここが渡せる最後のタイミングだったかもしれない。
他のチームにバックログを渡してみた
↑の2つをやっても、まだサービスインの未来は見えてこないので、Scrum of Scrumsの他の2チームにバックログを振ってみました。
良かったこと
- 独立したバックログに関しては、並行して開発が進められた
悪かったこと
- バックログの依存関係が強くあり切り出せる部分が非常に少なかった
- バックログの実質的な管理者がスクラムマスターだったため、他チームで開発すると進め方に難あり
1点目は、ある程度想定していたことですが、同じリリースタイミングのものは依存関係が濃く分担出来る部分が非常に少なかったです。
2点目は、他チームに渡したからというと語弊がありますが、社外ステークホルダと仕様を決めていくプロダクトオーナー、バックログの実質的オーナーである私、開発を依頼した先のチーム、この3者の連携が上手くいかなかったことが問題でした。↑の方でプロダクトオーナーにバックログを引き継げなかったことが悔やまれる。
他のチームから人を拐ってみた
他のチームにバックログを渡してみたがイマイチ不発だったため、他のチームから人を拐ってみました。
良かったこと
- 人数が増えた分だけ開発が加速した
チームこそ違えど同じプロダクトを開発しているメンバなため、初期コストもなく人数を増やした分だけ開発が加速しました。チームを跨いだ時に発生していたコミュニケーションロスも同じチームなら問題なし。
悪かったこと
- チームの人数が多すぎて(MAX11人)スクラムの体をなさなくなった
悪かったことはこの一点に尽きます。
チームの人数が増えると、他のメンバーが何をしているかって把握出来なくなりますね。教科書通り8人超えたらその傾向が顕著でした。
今回の場合は、ワンチームになるのを諦めて、一番暇しているスクラムマスターがコミュニケーションハブとなって強引にサービスインに持ち込みましたが、このような状況でどうするのが正解だったのかは分からず。
多少のコミュニケーションロスは覚悟して、2チームに分けスクラムマスターを兼務する進め方にした方が良かったのかもしれないし、そもそもコミュニケーションロスが出ることになる状態な時点でスクラムを継続するには詰んでいたのかもしれない。
1人で考えても答え出る気がしないので保留。
やれなかったこと
やったことの中にやれなかったことが一部書いてはいますが、ここではそこに書き切れなかったものを挙げてみます。
スプリントレビューへの社外ステークホルダーの巻き込み
スプリントレビューはステークホルダーを集めて開催、ってスクラムの基本ですね。
当然やるべきことなのですが、今回は出来ていなかったです。
なぜやれなかったか
思い返してみると最初の頃は契約未締結で参加できないという制約があり、それを最後まで引き摺ってました。契約締結後は参加できたのに。。。
変化への対応が出来なかったということになりますね。
変化への対応。どこかで聞いた言葉だ。😅
結果
サービスイン直近に大きめの改修が入るなど開発チームにも負荷がかかり、ステークホルダからの要望も期限切れで一部取り込めないという、それぞれにとって嬉しくない結果となってしまいました。
スクラムマスターとしては大いに反省。😞
終わりに
改めて振り返ってみても、スクラムとして正しい姿になっているか確認すれば回避できる問題が殆どでしたね。
問題直面時に少しでも前進しようと足掻いてしまいがちですが、困った時ほど一旦立ち止まりスクラムの基本に立ち返るべきだと改めて感じました。
結論：スクラムは偉大なり。