Re: スクラムを大人数で運用したところ💩な結果になった。
はじめに
スクラム導入の成功事例は近年よく目にするようになり、最近ではLeSS導入の事例も増えてきました。 でもLeSS導入の難しさを紹介した事例はこれまで見かけたことがなかったので、自分がプロダクトオーナー/スクラムマスター/アジャイルコーチの立場ならどうしたかなと思うところをまとめてみました。
私のLeSS経験は1年半ほど、開発者が20〜30名の開発で、チーム数は2〜4チームの間を変動しています。 LeSS Hugeは導入したことがありません。 LeSS実践者研修は2018年の5月に受けました。
気になった点
ベロシティは生産性の指標では無い、チーム間で比較しちゃダメ
ベロシティ(達成pt数)という形でチームの貢献度が表されて、みんなが働いている状況を数字で共有できる
スクラムにおけるベロシティは「あるチームがスプリント内に提供できる要求の量」であり、次回以降のスプリントの参考にする指標でチームの成長や生産性をはかる指標ではありません。下記に詳しく紹介されています。
LeSSでは1つのプロダクトバックログを全チームで共有するため、「チーム横断で見積もられたストーリーポイントを比較に使えるじゃないか」と思うかもしれませんが、そもそもストーリーポイントは規模の相対比較の指標であり、正確なものではありません。 また作業を担当する人・経験によって工数は変わってしまいます。
LeSSにおけるストーリーポイントの利用方法は、複数チームでのストーリー分配時の目安です。各チームのスクラムマスターが自分のチームにとってこなせる作業量であることを判断するのに使います。チームにとって得意なストーリーが多ければ全員で見積もりして合意したストーリーポイントは過大評価になりますし、苦手なものが多ければ逆になります。とはいえチーム分配後にストーリーポイントを見積もり直すようなことはしません。LeSS実践者研修で講師だったBas Vodde氏は「やりたければやっても良いが、何の意味もない。」と質問に答えていました。
2つの大きなプロダクトをグロースさせるために、トライアンドエラーとリリース速度をあげたかった。
スクラム/LeSSの生産性を測りたいのであれば別の指標を用いるべきです。例えば…
- リリース/デプロイの回数、頻度
- ストーリーが積まれてから顧客に届けられるまでの期間
- スプリント完了後に見つかったバグ、バグ発見から修正までの期間
関係者と責任者は別、全チームがプロダクトの全部分をさわれなくても良い、調整はチームにやらせる
関係者が増えたおかげで、責任が不明瞭になり物事の決めごとに労力と時間がかかる。
複数チームで1つのソースコード・コンポーネント・ソフトウェアを開発することになるので、設計・機能・品質に関して人ごとのぶれが発生します。この問題の解決策としてコンポーネントコミュニティ & コンポーネントメンターを設置すると良いです。決め事は代表者で決めれば良いし、相談が必要なほど皆が関心があるならコミュニティが機能するはず。
プロダクトの定義とDoneの定義は少しずつ拡大していく
1週間のスプリントで、見たこともないプロダクトの見積もりと学習をし、数チームと合意し、複数のSMと合意するのは無理ある。
全部のプロダクトを全チームが同じようにいじれることは理想かもしれないが、現実的には少しずつ増やしていくしかない。
- システムに含まれる全てのコンポーネント→プロダクトの定義
- システムのリリースまでに必要な全ての作業→Doneの定義
を書き出し、縦軸にプロダクトの定義に照らし合わせて大きいものから並べ、横軸にチームができるようになるべきリリース前作業を優先順に並べる。チームの現在位置を皆で確認し、数ヶ月後・半年後・一年後といったスパンでチームの将来位置をみなで話し合うとチームの成長に必要な要素(扱えるようになりたいコンポーネント、スプリント内でできるようになるべきリリース前作業)が差分として明らかになる。LeSS実践者研修では「Doneの拡張ワークショップ」として行なった。
チームは変えない
スクラムに不慣れな人間がたくさんいる状況は仕方がないが、習熟と効率化が発揮されるのが遅い。 人の入れ替え、組織変更を挟むと初期化される...
スクラムの目的が「チームを成長させ、自律的に動き価値を提供できるようにする」です。メンバを変えるとチームの文化が変わってしまうので入れ替えは基本行いません。 プロダクトに合わせてチームを構成するのではなく、チームにプロダクトを与えます。チームと技術分野が噛み合わないプロダクトだったとしてもチームが技術を学び、不足を自分たちで補えるようにすることで、自律的なクロスファンクショナルチームができます。
振り返りはできるものを少しずつ
トップダウンで案件が降ってくる形になり現場での改善活動ができなかった。
開発がどんなに忙しくとも、スプリントの終わりに振り返りを必ず行い、少なくとも1つは改善を行いましょう。 やりがちなダメな改善は「次から気をつける。次は頑張る」です。気持ちの問題にするのではなく、プロセスの問題として捉えましょう。 振り返りの最中に答えが出なくても、状況を1歩進める行動を明確にするだけでも違います。例えば「XXXについてYYさんに話す」とか。
LeSS導入とは組織変革である
普通の話だけど、権限と責任の移譲をしっかりやって、コンパクトな組織を維持できるようにしたほう良いと思った。
LeSSの思想は「1つの大きなプロダクトに対して、1つのスクラムチームで取り組むことを考える。その時にボトルネックとなる事項は分散させる。」です。基本的に全体で1チームとして考えます。SAFe/Nexusなどのスケーリング手法は統合チームを置いたり、調整役(XXXリーダーとかプロジェクトマネージャーとか)を置くことで対処していますが、LeSSは調整をチームに委ね、調整役を置きません。したがってLeSSの導入が進むほどに、過去の組織にあった「プロジェクトマネージャー」などの調整役が不要になり、組織構造がコンパクトになります。
LeSSの導入には組織変革が避けて通れないため、LeSS研修には管理職向けのものも用意されています。
LeSS導入は組織変革を伴うので、少しずつ進める必要がある
私の経験を振り返ると
- 1チームでスクラムがきちんと回せるようになる
- 人数が増えたチームを分割し、2〜3チームでスクラム/LeSSが回せるようになる。
- 8チームでLeSSを回せるようになる。
- 4チーム x 2エリアでLeSS Hugeを回せるようになる
- LeSS Hugeが回せるようになったので必要なだけスケールさせる
だと思います。いきなり4、5は無理です。
LeSS実践者研修オススメ
上記の内容を3日間で学べるLeSS実践者研修オススメです。次回は2018年3月12〜14日です。
