背景

新しくアサインされた案件がスクラム開発で進行していた。
開発チームもそのタイミングで作られ、既存の開発メンバーから引き継ぎを受けて、徐々に一週間単位のスプリントでやれることを増やしていった。
開発チームはスクラム未経験のチームで、社外にスクラムマスターとプロダクトオーナーがいる状況。

遭遇した６つの問題

1．最初のスプリントで生産性が発揮できない

スクラム自体未経験だったり、チームとしての連携や、プロダクトそのものへの理解の無さなど、
さまざまな要因で生産性が発揮できませんでした。
スプリントの振り返り時に、そのスプリントでのタスクを十分にこなすことができない、ということが多かったです。

スクラム開発としては、これはしょうがない、というか、そういうものだと受け入れて、
なるべく１スプリントの流れを作れるように集中するべき時期ではあるそう。

2．ベロシティ(生産性)に焦点があたってしまう

どうしても生産性を出さないと、チームとしては居心地が悪いのか、
スプリント内のタスクをすべてそのスプリント中に終えようと、
残業したり、テストなどが不十分の状態でフィードバックを得る場に持っていったりなど、
不健全な状態になってしまいました。

残業したら、体調崩す人や寝坊する人も出てきたり、
テストや動作確認などが不十分だと、あとでまたバグを直すことになるなど、
出戻りが多くなってしまいました。

3.完了(Done)の定義が弱い

PBIsがスプリントバックログにてタスク化され、開発チーム内で割り振られるのはいいのですが、
それらの完了の定義が明確化されていないことで問題が生じます。

何をもって完了したか、が不明確だと、
開発メンバーの作業に品質的な差が出たり、
最終的な成果物が、『顧客が触れる状態』ではなくなってしまい、価値が提供できない可能性があります。

エンドポイントをたたいて結果が返ってくればOK？
テストは？ドキュメントは？

これらが決まっていないと、上述のようにあとでバグを直すことになったり、
不必要な出戻りをすることが起こりえます。

4.チーム内にいるリーダーという存在による不和

リーダーが存在すると、責任の大きさがメンバーごとに差が出ます。
リーダーの働きが悪いと、「なんでリーダーなのにooをやってくれないんだ」
などとメンバーから文句が出たりして、雰囲気が悪くなったり、連携が取りにくくなったり、余計なことで開発に集中できなくなる原因にもなったりしました。

スクラムチームに上下関係は持ち込むべきではないというのはよく言われますが、そういった余計な問題が発生するからとのことらしいです。

5.チーム内でのスクラム開発に対する漠然感

最初、開発チームは、優先順位が暴力的に決まった(かのように見えていた)PBIsに対し、スプリントでそれをこなすだけの機械のようになっていました。

リモートワーク推奨の組織なだけに、Face to Faceのスプリント計画は行きたがらず、特定のメンバー(PMとPL)のみが赴いたり(そもそもPMやPLがいることがスクラムで推奨されていないことはいったん忘れて)、自分たちがこのスクラム開発をやるにあたってどうあるべきか、プロダクトに対してどういうスタンスで立ち向かうべきか、という部分がまとまっていなかったです。

不透明な部分が多いと、「スクラムってなんだっけ」、「どうするのがいいんだっけ」と、開発に集中できないので、
指針となるスクラム開発をやる意義を考えることは、チームとして必要だなと感じました。

それらを助けるのはスクラムマスターの責務でもあるのでしょう。

6.スクラムマスターの存在している意味がわからない

スクラム開発におけるよくある問題として、『スクラムマスターの存在意義がわからなくなること』というものがあります。
チームマネジメントをする存在ではないし、「MTGのファシリテーションくらいしかしてないんじゃないか？」
みたいな声が、実際にチーム内から出たりすることもありました。

スクラムマスターは、スクラム開発がうまくいくよう、
プロダクトオーナーと開発チーム、また、組織に対し責任を負います。

チームメンバーが自己管理し、各々でリーダーシップを発揮できるように、
サポートすることがスクラムマスターの役目です。

つまりチームがスクラム開発において集中できてないようであれば、その障壁を取り除いたり、
スクラム自体やツール導入の支援を行わなければなりません。

逆にそれらが行われていないのであれば、スクラムマスターは機能していないとも言えるでしょう。

おわりに

アジャイル開発宣言のうち、『顧客との協調』という部分が個人的には一番本質的な部分なんじゃないかと思っており、そんな中、『生産性(ベロシティ)』や『上下関係』、『責任の所在』などに意識が向いてしまうと、アジャイルに則ったスクラム開発からは遠ざかってしまう気がします。

スクラムの背景にあるアジャイルの考えを確認し、自分たちのチームがどうあるべきなのかを、スクラムチーム全体で考えていけたなら、よりよい価値を提供できるのではないかと日々思っています。