スクラム実験室：「相互依存最大化のすすめ」に参加しました
だいぶ間が空いてしまいましたが、9/11に行われたこちらのイベントに参加しましたのでその参加レポートになります。
相互依存最大化のすすめ - connpass
LeSS開発者の1人であるBaS Vodde氏がLeSSの研修を日本国内で実施するために来日されており、その来日に合わせて世界中で行われているBas氏の「Maximizing Dependencies with Interdependent Teams」の講演が今回スクラム実験室で行われるということで参加してきました。
なお、当日のスライドはこちらからダウンロードできます。
Scaling Scrum, Scaled Agile - Large Scale Scrum (LeSS)
いくつかこちらのスライドからも抜粋して記事を書いております。
かなり長文になってしまいましたが、イベント参加前の私のように「相互依存を最小化ではなく、むしろ最大化するってどういうことだろう」と興味を持たれた方は是非最後までお読みいただければと思います。
冒頭のエピソード
以前高速道路で大渋滞に巻き込まれた時の話し。
子ども：「隣のレーンが渋滞なく車が流れているのを見てあっちのレーンがいい！」
バス：「そのレーンは誤った方向に向かう道だが、それでもいいのかい？」
子ども：「それでも空いている道がいい！」
と言われたというエピソードから始まりました。
プロダクト開発では本当に重要なものが進んでいることがスピードよりも重要。速さよりも正しさに注力すべきという話しをされていました。
とある大学のマネジメントシステムを5つのチームでLeSSで開発していく話し
このストーリーが当日の講演のメインエピソードになっていました。
5つのチームにはそれぞれ以下の名称が付いています。
3つの大きな機能がリファインメントの結果、分割してバックログとして存在しています。
・コース登録
・外部のスケジュールサービスとの連携
・マイグレーション
このLeSSチームでは以下のような状況を観測することが出来ます。
今後を見通して知識の少ないドメインのバックログに積極的に挑戦していくチーム
Team Criminalsは元々コース登録について詳しいのでそれに関連するバックログを待っていきます。
それに対してTeam Haloweenから「コース登録に関する機能が今後も沢山見越しているから他のチームもできるようになるべきでは？、Team Haloweenが今回コース登録について学ぶためにのに適切なバックログはどれ？」という意見が出ます。
そうしてTeam Haloweenは今回のスプリントで新たにコース登録に関するバックログに挑戦することになりました。
同じスプリントで共通のコンポーネントを複数チームで変更を加える
異なる機能だと思っていたバックログだが、外部のサービスを使うバックログを開発するにあたり、共通のコンポーネントを複数のチームで触る必要がありました。
Team SpaceとTeam Lakeはコミュニケーションを取りながら開発を進めていきます。
ミックスグループで作業を行う
チームごとに5つのテーブルを用意していますが、スプリントが開始するとどのチームのテーブルか分かりづらくなることが多くありますし、それは仕方ないことと考えます。また、多くの人はペアで仕事をしています。
例えば、先ほどのTeam Haloweenは新たにコース登録のバックログを進めることになったのでそのドメイン知識が豊富なTeam Criminalsとコミュニケーションをとりながら進めています。
また、Team SpaceとTeam Lakeは共通のコンポーネントを修正することになったのでチームを横断した何名かでモブワークを行っています。
リファインメントについても同様です。複数チームでのリファインメントを行う際のアプローチとして、最初からこのバックログはこのチームで行うというのを決めることはしません。
ミックスグループを作り、各チームから一人ずつ参加したバーチャルチームにてリファインメントを行います。
そうすることでチームメンバーの誰かしらはそのアイテムについて知っている状態を作っているのです。
リファインメントをバーチャルチームで進める中で、ビジョンに対する説明はプロダクトオーナーが行いますが、基本的に一個一個のアイテムに関する説明はしません。
また、ユーザーやステークホルダーをリファインメントに巻き込みながら進めていきます。
このような働き方をするためにどうすればいいのか
ここまで見てきたLeSSで観測できた3つの状態。
このようなLeSSが出来るようになるために我々はどうなっていけばいいのでしょうか。
2つの道程があると説明されていました。
・支持されるチームから自己管理するチームへ
・プログラマーからプロダクトディベロッパーへ
特に後者のプロダクトディベロッパーへというところに講演では時間を割いて話をされていました。
プログラマーとは、私の仕事はコードを書くことだという姿勢で何を作るかは他の人が指定するもので言われた通りにコードを書くという状態のことを意図している。
一方でプロダクトディベロッパーはユーザーや顧客の課題を解決したいと考えている人です。
要求の明確化のためにコラボレーションして、ビジネス領域のことについての理解しなければならないと考えています。
ユーザーの問題を理解し、マーケットのビジネスを理解し、解決策を考えるのがプロダクトのデベロッパーです。
この道のりを辿るのに多くのLeSSチームでは時間がかかります。
少なくとも半年は必要になります。
チームはプロダクト全体思考になろう
自分たちのドメインだけではなくチームはプロダクト全体を見るようにしましょう。
そのためにLeSSではプロダクトオーナーも１つでプロダクトバックログも１つにしていて、事前にバックログをチームへアサインすることもしないようにしています。
LeSSチームが全体思考出来ているかについては、スプリントプランニング1に参加することでわかります。
チーム全体でどのようにプロダクト開発するかを考えての発言があるかどうかに注目するのです。
また、ミックスチームでのリファインメントでは自分達が開発しないもしれないバックログについてもリファインすることです。
そうすることでプロダクト全体思考につながります。
フィーチャーチームを目指す
フィーチャーチームとコンポーネントチームは大きく異なります。
コンポーネントチームはアーキテクチャにリンクしています。
コンポーネントチームというのは例えば、フロントエンドを担当するチームとバックエンドを担当するチームに分けるようなイメージです。
フロントエンド、バックエンドに完結した機能がそれなりにあったり、それぞれのチームにちょうど同じ量の割合のバックログが毎回あればまだ問題になることは少ないかもしれません。
でも、実際は優先順位が高いのはフロンエンドばかりで、フロントエンドのチームはバックエンドチームががかなり前のスプリントで作った機能のフロントエンド部分をつくるみたいなことが起こり得ます。
そして残念ながら結合してもうまくいかないのです。
バックエンドチームに確認を依頼しますが、バックエンドチームはそんな前に対応したものを触りたくないという話しになってしまいます。
依存関係が非同期であることが問題なのです。
だから衝突が生まれます。
LeSSではフィーチャーチームに移行しましょう。
やり方は簡単です、フロントエンドとバックエンドの技術者をミックスするだけです。
そうしてチームでフロントエンドとバックエンド両方ともできるようにしていくのです。そこから先のより良い進め方はチームで考えます。
そうするといつかそれぞれのフィーチャーチームは、フロントエンドの共通部品やバックエンドの共通部品といったように同じコンポーネントを同じスプリントの中で触ることになるでしょう。
つまりこれはチーム間の依存関係からコードベースでの依存関係に変わったのです。
但し、これは同期できる問題で非同期で進むものではありません。
相互依存の最大化
コンポーネントチームは非同期の依存
フィーチャーチームはコードベースで同期での依存
同期での依存は協働する機会が生まれたとも言えます。
フィーチャーチームになると協働でやる仕事という依存にが生まれます。
複数チームで仕事をする際にはお互いのチームで学びを最大化したいと考えるべきです。
この種類の依存関係の最大化によって、我々は学び・協働の機会が最大化されるのです。
チームが意図的にその機会を増やしていくことができます。
それは楽しく、学びが最大化されるのです。
どの種類の依存関係を最大化するかが肝になります。
CIサーバがあることが継続的インテグレーションではありません。
常にインテグレートして結合していくこと、小さな変更をして常に結合することこそが継続的インテグレーションです。
一回の変更を大きくしてはいけません。
チームはコミュニケーションをし続けることも求められます。
チーム間の協働機会の最大化をしていきましょう。
Q＆A
最後にQ＆Aタイムがありましたが、答えと質問を全てメモすることはできなかったのでいくつか気になったフレーズを書き出していきたいと思います。
プロダクトを定義する際には顧客の視点で見てほしい。エンドユーザーは何をあなたちから買っているか。顧客視点で2つのプロダクトでなければ1つのプロダクト
LeSSの観点ではプロダクトを細かく分けることのメリットはありません。webアプリに関連する申し込みサイトがあればそれも同じプロダクトと言えます
プロダクトデベロッパーになるために有効なアクティビティとしては、リファインメントがキーになると考えます。ユーザーやステークホルダーにすぐ聞くのではなく先ずチームでソリューションを考えましょう
リファインメントにプロダクトオーナーは一言書いてあるぐらいの雑なストーリーを持ってきて全員で議論を通して分割なり、明確にしていけばよいと考えます
マイクロサービスではコンポーネントチームになっていると思います。マイクロサービスはほとんどのプロダクト開発において必要ないと思うので、他の人が採用しているからという理由だけで採用しないことを勧めます。独立したデプロイが必要な時だけ選択すべきです。
最後に
前回のスクラム生誕30周年記念ウェビナーの感想にて、スクラムのシークレットソースとして「チーム全員がシステムをメタ認知してカオスの縁で小さな変更が連動して大きな進化が生まれる」という話しを書きました。
小さなチームだけではなく、5チームでLeSSをやる時には5チーム全体でプロダクト全体をメタ認知すべきという考えだったので、「なるほどなぁ」と思わされました。
これまで大規模な開発では10人以下のチームをマイクロサービスのチームのように扱って、チームの責任・責務を明確にすべきという考えをしていたので逆にチームの依存関係を最大化すべきというのは目から鱗が出るような話でした。
イベント参加からそれなりに時間は経ったものの、まだ自分の中で大規模アジャイルにおいて、どういうチーム構成で、チーム間がコラボレーションしていくべきかというところ考えが整理できていない（絶対の答えもないような気もする）ので、一つ今回のイベントに参加したことで引き出しが増えたのかなと思いながら、これからも考えていきたいと思います。
最後にBasに持って行ったLeSS本にサインを貰いました。
