スクラム失敗談 | みんなで話そうとするレトロスペクティブ

スクラムチームが、自分たちのコミュニケーションやプロセスを改善し、より生産的に価値を届けるためのふりかえりの場であるレトロスペクティブ。

今回は、私がスクラムマスター(兼エンジニア)を務めるスクラムチームでのレトロスペクティブでの失敗例を紹介します。

失敗:専門職で分かれてるのに一度しかしないふりかえり

「レトロスペクティブの場でチームメンバーみんなで話すことの何が問題なのか」と思われるかもしれません。ここには前提が入っていません。より詳細に書くならば、「異なる専門を持つメンバーで構成されているのに、レトロスペクティブの場がスプリント中に一度しかなく、その状態でみんなで話し合おうとすると、話し合いの密度が薄くなる」が失敗談です。特に、チームがまだ成熟しておらず、課題が山積みの状態ではこの失敗が顕著になるのではないでしょうか。

具体例をご紹介します。

私がいるチームでは、以下のようなメンバー構成になっています

- PO 1人
- 開発メンバー 7人 (デザイナー1人、エンジニア4名、QAエンジニア2名) 
- スクラムマスター 1人

開発メンバーは、デザイナー、エンジニア、QAエンジニアという異なる専門分野を持つメンバーで構成されており、互いに作業領域は独立しつつ、日々連携して協力し合いながらスプリントゴールの達成を目指しています。

そして以前まで、スプリントレトロスペクティブはスプリントの最後に一度、全員で集まって、1時間このスプリントについて振り返りをしていました。

そして何が起きたかというと、エンジニア中心の技術的な振り返りの議論が話題が多くなり、エンジニア以外には理解できず、他のメンバーはただ傍観しているだけの時間が毎回ありました。

エンジニア側からすると、自分たちが一番時間を費やした実装面の出来事について振り返りたくなるのは分かりますが、そうした話ばかりに目が行くと、専門を超えたメンバー間の協力関係や、スクラムのプロセスについての振り返りが疎かになり、チーム全体としての振り返りの密度が薄くなってしまいます。また、流石にみんながいる中で技術面のみ十分に議論することもできないため、実装面の振り返りという観点でも密度が薄くなっていました。

それでも、しばらくはそのような状態のレトロスペクティブを続けていました。なぜなら、スクラムガイドには”スクラムチーム内には、サブチームや階層は存在しない”とあり、それを私は「スクラムチームはなるべくみんなで議論すべきで、エンジニアだけで集まって議論するのは良くない」と解釈していたからでした。また、会議体を増やしてエンジニアの作業時間を減らすことにも抵抗がありました。

しかし、流石にこののままのレトロスペクティブだと生産性が低いため、やり方を少し変えてみました。

改善:専門職ごとのふりかえりと、チーム全体のふりかえりの二段構え

私のチームでは、まだジュニアなエンジニアが多かったり、なかなか見積もりと実態が合わなかったりなど課題が割と多かったため、エンジニア用のレトロスペクティブと、スクラムチーム全体のレトロスペクティブとで、二段階に分けて振り返りの場を設けることにしました。その上で、以下のような方針を設けました。

1. エンジニア用のレトロスペクティブでは、エンジニアにしか関係ない話のみをする。デザインやQAにも関わる話はここではしない

2. チーム全体のレトロスペクティブでは、チームメンバーみんなに関係ある話のみをする。一部メンバーにしか関係のない話は別途話す。

3. エンジニア用のレトロスペクティブの内容はチーム全体のレトロスペクティブでもシェアし、自分たちがどんなことを振り返ったのかの透明性を担保する。学びを抽象化し、エンジニアリングに限らない汎用性のある学びとしてシェアできれば、他のメンバーにも役立つかもしれない。

このように、敢えて専門職で分けてふりかえりをすることで、チーム全体のレトロスペクティブでは、それぞれの専門職内での話ではなく専門職間のコミュニケーションについて話す時間が格段に増えましたし、心なしか、みなさんがより積極的にチームに対して意見を出すようになった気がし、レトロスペクティヴの密度を以前より濃くすることができました。

スクラムチームの状況はチームによりかなり異なるでしょうし、このやり方がみなさんのチームにも当てはまるとは限りませんが、参考になれば幸いです。

また、みなさんのチームで工夫していることも教えていただけると嬉しいです。


補足:エンジニア用のレトロスペクティブで話していること

エンジニア用のレトロスペクティブは、まだまだ改善途中なのですが、以下のような話をしています

- 見積もりの規模と実際作業していての規模は合っていたか?合ってなかったとしたらなぜか?
- このスプリントではどのくらい差し込みがあり、残業時間はどのくらいだったか?
- 差し込みがスプリントゴールを脅かさないようにするにはどうすれば良いか?
- 次スプリントで残業なしで終えるには、ベロシティをどのくらいにするか?
- 実装プロセスでどんな困難があったか?


この記事が気に入ったらサポートをしてみませんか?