Global Scrum Gathering 2014 に来ている。Scrum Gathering Tokyo の実行委員を３回つとめさせていただいたが、本家のScrum Gathering には未参加だったので、雰囲気を知らないといけない、ということで、遅ればせながら、今回初参加した。
冒頭の主催者のセッションによると、今回のカンファレンスは、 これまでで最大の規模になったとのこと。目分量でAgile Conferenceの半分くらい、500-700人くらいの規模ではないかと思う。23カ国から参加者が来ていて86%は米国からだそうだ。５並行セッションで48セッションが行われる。
基調講演 : Ken Rubin "Economically Sensible Scrum (経済合理性のあるスクラム)"
Essential Scrum の Ken Rubin の基調講演。Kenは以前 Scrum Alliance の理事をしていたそうだ。Essential Scrumは、もうすぐ日本で発売される予定だ。
今回はチームレベルのスクラムができている状態で課題になる、その外側の話。チームレベルの開発にスクラム適用がうまくいくと、次は組織に必要な価値との擦り合わせが課題になる。そこには３つの阻害要因があるという。
- 開発時に、アジャイルの基本原則を無視する、または、間違って適用する
- アジャイル原則をバリューチェーン全体に適用することに失敗する
- チームを組み合わせるにあたり、経済的に合理性のある組織構造を作ることに失敗する
一つ目のアジャイル原則の適用については、Antifragileという本を紹介していた。状況が混乱したときにどのような影響があるかで、３つのレベルに分類すると、Fragile(うまくいかなくなる) - Robust(影響を受ける) - Antifragile(混乱から利益を得る) となる。ウォーターフォールはFragileで、アジャイル原則の適用によってRobustやAntifragileの実現を目指す。
二つ目のバリューチェーンは、複数チームが関わる場合にバリューチェーンを意識するということだ。開発チーム以外にもマーケティングやインフラ、運用チームなどがある場合に、要望が来てからリリースされるまでのサイクルタイムをいかに短くするか、というリーン原則を実現するようにチームを組む。
ここで重要なのは、各チームの稼働率を最大にすることは意味がないということだ。消防署で例えると、稼働率100%の消防署ばかりでは、いざ火事が起きた時に対応ができない。ビジネス要望に即応することと、稼働率を高めることは、稼働率が一定以上になったときに矛盾が生じる。ここでは70%弱くらいで待ち行列の大きさが倍になる例を示していた。開発チームがなかなか要求した仕事をしてくれないのは、だらだらしているのではなく、むしろがんばりすぎていて、稼働率が高すぎるからかもしれない。
三つ目の組織構造については、専門別の部門、地域ごとの部門、コンポーネントごとの部門、フィーチャーチームという４つのパターンを示した後、フィーチャーチームとコンポーネントチームの組み合わせがよいのではないかという結論だった。コンポーネントチームの代表がフィーチャーチームにも属し、花粉を運ぶ役割をもつ、ということだ。
軍隊や消防署のように、長く続く小隊はすでに過去の経験を共有しており、経済合理性がある。
うまくいっているチームが、「スクラムなんだからチームメンバーの変更は受け入れない」といいはじめて、各チームが同じことを言うと、組織全体としてはデッドロックに陥ってしまう。そうではなく、全体のフローの視点で考えようというのが印象的だった。
Coaches Clinic
休み時間にコーチに相談できるCoach's Clinicで、いまちょっと悩んでいることを相談した。
内容は割愛するが、個人的にすごく有益なアドバイスをいただいた。
Chris Sims "How to estimate Business Value"
ビジネス価値を導きだすワークショップ。Agile Conferenceでもやられているようなので、有名なのかもしれない。一般的にビジネス価値といえば金額を想定することが多いが、実際は金額以外の価値がたくさんあり、多面的な価値を考えなければならない。そこで、多様なステークホルダーが集まってさっと相談する。並べ替えと相対見積りを使ってビジネス価値をつけていく。ポイントはこの課程で共通認識ができるということだ。
ここでできた共通認識を外の人に伝えるのは難しいので(見積り結果は伝えられるが、多面的な議論のすべてを伝えるのが難しい)、ステークホルダーに集まってもらう必要がある。
結果として、複数の利害関係をゲームによって調整した結果のビジネス価値つきバックログが作られる。ビジネス価値は変動するものなので、スプリントごとに見積りをやり直す。
ビジネス価値がスプリントとともに変化する例の一つは次の通りだ。出荷可能な単位の機能の価値が300として、そこに３つのバックログ項目が含まれる場合は一つあたり100と考えられる。スプリントが一つ終わって一項目実装が終わると、残り２つ作れば300の価値が実現できるので、残り２項目の価値は100から150に上がる。
この方法が今のチームで使えるかどうか、ちょっと試してみたいと思う。
