本記事ではスクラムとチームビルディングについてまとめます。
スクラムチームの立ち上げを含めなんどもチームの立ち上げをしてきた経験も踏まえお話ししていきます。
スクラムとチーム
スクラムガイドにあるようにスクラムにおいてはチーム人数について以下のように記載されています。
開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが 3 人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが 9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。 出典：スクラムガイド
3人未満は相互作用が少なく生産性につながらない、また、9人を越えると調整が多くなり調整の機会が多くなる、と書かれていますね。
この辺りについてはチーム開発の経験がある方であれば感覚的にも理解できる点でしょう。
なお、スクラムガイドに記載されているようにスクラムにおいてはプロダクトオーナー、スクラムマスターはこの人数に含まれません。
それでは以降ではスクラムにおけるチーム、チームビルディングについてお話ししていきます。
スクラムチームのチームビルディング
スクラムにおいては3〜9人の1チームでチームが構成されています。そして前述したようにプロダクトオーナー、スクラムマスターは人数に含みません。
スクラムチームの立ち上げについてはチームメンバーがどの程度スクラムの経験があるかでチームビルディングにかかる時間、コストも変わってくるように思います。そのためスクラム経験者が多いケース、少ないケースに分けて考えてみます。
スクラム経験者が多いケースのチームビルディング
例えばスクラムの経験者が多いチームにおいてはスクラムというフレームワークを理解している方が多いことがあり、新しいチームが始まる際に実際に必要な準備などを簡単に分担できると思います。例えば下記のような形でしょうか。
- セレモニーの日程決め
- Doneの定義の準備
- Readyの定義の準備
- プロダクトバックログの準備
- ・・・
他にもいくつかあると思いますが、こういった準備はスクラムを始めるにあたって必要なことと理解しているため新しいチームではあるものの比較的早くチームが走り始めることができるように思います。
これはフレームワークならではのメリットですね。
そしてこれも大切なポイントですがスクラムを経験している方々はまず始めることが大切だと理解しているためアクションが早いです。曖昧なままでもアクションを取れますし、決まっていないことも受け入れつつ、少しずつよくすればいいよね、という共通理解があります。
そのため個人的にはスクラム経験者が多いチームはチームが走り始めるまでは非常に早い印象です。そのあとの改善はまた別の話ですがチームが立ち上がるのは早いでしょう。
スクラム経験者が少ないケースのチームビルディング
この場合はやはり時間がかかることが多いと思います。理由としては大きく以下だと考えます。
- スクラムを理解することに時間がかかる(概ね3〜4スプリントでなれるはず)
- 曖昧なまま進めることに抵抗があるメンバーのフォローが必要
- 議論に時間がかかる、議論が空中分解するケースが多い
アジャイルソフトウェア開発宣言にもあるようにスクラムにおいても会話を重視しています。セレモニーでも振り返りをするスプリントレトロスペクティブがありチームメンバーと会話をする機会は非常に多いです。
チームメンバーと会話をする機会は非常に多いのですがはじめのうちはそういった機会を上手に使うことができないことが多いでしょう。その結果、チームが空中分解したりちょっと気まずい、なんていう状況になるかもしれません。そういった状況でこそスクラムマスターがうまくリードできるといいですね。
スクラム経験者が少ない場合のチームビルディング時はプロダクトバックログなどスクラムを始めるために必要な物を用意することももちろんですが、こういった各セレモニーでのチームの会話をうまく進めることが大事だと思います。
それでは以上です。
スクラムについては下記記事でもまとめていますのでぜひご覧ください。
