大きな組織はScrumをチームを超えた大きさに適用したいと考えている。この記事では、Scrumを拡大適用して組織全体にアジャイルを導入するための方法についていくつかの例を紹介する。
maximizing scrumと題した記事で、Gunther Verheyen氏はScrumの拡大の仕方について書いている。氏はScrumをスケールする場合に組織が考えることについて説明する。
長年の間、既存の仕事では、質と量を増加させることによってのみ成長(例えば‘スケーリング’)を達成できるという考えが浸透しています。‘Scrumをスケールさせたい’という考えは、成長は数を大きくすることでのみ達成できるという過去の考えを反映しています。
氏は組織がこのような考えに基づいてScrumをスケールするときに直面する課題について説明する。
組織は既存の構造に手をつけるのを嫌がり、既存のオペレーションを維持したがります。それゆえ、既存の構造にフィットする方法でScrumを実装しようとします。その結果、Scrumをひねって実装することになり、Scrumの原則と基礎は修復できないくらい壊れてしまいます。そして、Scrumの利点が制限されてしまうのです。この問題はほとんど手がつけられていません。表面的に触れられているだけです。
氏は組織がScrumをスケールするための別の考えを提示する。
Scrumをスケールすることの第一の可能性は、能力や質や量を増大させることではありません。既存の能力を改善することなのです。スケーリングはチームの中で行われます。チームを増やしたり、役割やフェーズを増やしたりすることではありません。
氏によれば、組織にScrumを展開する前に、Scrumについて完璧に理解し、完璧に実践しなければならない。氏はこの記事で、Scrumをチーム内でどのように活用するか、Scrumの実践を改善することの利点について例を示している。氏はひとつのチームでプロダクトオーナの役割をスケールする方法について説明する。
- IT系の人物、たいていの場合はアナリスト、がプロダクトオーナになるのは、利点が限られます。開発部門にとっては主導権を握る手段ではあります(‘ビジネスサイドの人間を信頼するな!’)。しかし、多くの意思決定にとって、アナリストはプロダクトマネジメントやビジネス開発について十分な知見を持っていませんし、プロダクトマネジメントに立ち返る必要があります。これによって、無駄が生まれ、待ち時間が生まれ、タスクに切り替えが頻発します。流れがありません。価値が生まれません。
- ビジネス側にとっての代理人がプロダクトオーナになると少しましになります。主導権はIT側に残ります(‘まだビジネスサイドの人間を信頼するな’)が、ビジネス側により強い結びつきがあるプロダクトオーナであれば、無駄な時間も少なくてすみます。しかし、多くは変わりません。
- プロダクトマネジメント(‘ビジネス’)の代理人がプロダクトオーナになると劇的に改善します。機能の知識や利害関係者の期待が直接的にわかるようになります。しかし、時間の無駄はまだ残っています。
- ビジネス側の人間であるというだけでなく、信頼があり、意思決定ができる人物がプロダクトオーナになるのがいいでしょう。文脈の切り替え、タスクの切り替えが少なくなり、流れが改善します。開発チームは集中力が上がり、成果が出やすくなります。
- プロダクトオーナが製品のミニCEOだととてもすばらしいでしょう。製品の真の所有者なのです。完全な(機能的かつ予算的)責任を持ち、プロダクトマネジメントのすべての側面(マーケティング、コンペ、ユーザ、法務、ファイナンス)に積極的に関係します。職業人としてその製品がすばらしくなることに全力を傾けます。
Scrum doesn't scale! really?というブログ記事で、Steve Crago氏はScrumをスケーリングするときに使えるアドバイスを書いている。ひとつはチームメンバの変化に準備しておくことだ。
どのようなタイプのスケーリングであれ、チームのメンバの入れ替わりがあることを理解しておくことが重要です。やめる人、解雇される人、休暇をとる人、病気になる人、さまざまです。毎日このような出来事に対処する必要があります。それゆえ、チームの構造を柔軟で最悪のケースに対応できるようにしておく必要があります。私がチームを作るとき、私はこのことを念頭におきます。そして、ひとりでもかけてしまうと困る状態にならないようにします。クロストレーニングが重要なのです。
もうひとつのアドバイスは、Scrumをスケールするときに複数のScrumチームを協調させる方法だ。
自己組織できているチームはほかの自己組織できているチームと協調して、依存性や優先順位、特別なスキル要件などを決めます。ScrumのScrumミーティングで決まることもあります。このミーティングは各チームのメンバが集まり、チームで何をしているのかを話します。必要であれば、ほかの会議も実施します。
Tirrell Payton氏はscaling Scrum: 4 tips to help with organizational changeと題したブログ記事を書いている。氏によれば、アジャイルは実践すれば、利点を享受できるというソフトウェア開発のモデルではない。
Scrumは開発を素早くしません。なぜ遅いかを教えてくれるのです。なぜ遅いかがわかったらどうするかは実践者次第なのです。
Scrumを大きな組織で実践するのは、小さなチームで実践するのとは違う、とTirrell氏は説明する。
小さなチームに導入するときは、問題と解決策は局所的です。それゆえ、組織がフラットで小さい場合は、問題はその組織と同じレベルで解決されます。しかし、大きな組織の場合、問題や完全な変形を妨げる弱点は組織自体の構造やレイヤの問題点を表しています。Scrumはこれらの組織的な問題や弱点を目に見えるようにします。そして、よりよく見えるようになると人々は不愉快になる場合があります。
氏は組織にScrumを導入するときに実行することをいくつか例示する。
- プロダクトの周辺で行われている努力に方向を与えます(…)。プロダクトをアイディアの状態から市場へ投入できるようにするために必要なあらゆることを実施し、単一の着目点に注力するチームを作ります。
- 企業のリーダーシップがアジャイルのビジョンを補強するようにします。リーダーシップが進むべき方向に対して強いビジョンを持っているとき、組織全体のアクションを誘発するようになります。
- コミュニケーション、コミュニケーション、コミュニケーション(…)。アジャイルのビジョンとなぜそのビジョンを実現することが重要なのかを明確にする必要があります。言葉と行動で示し、行動がビジョンを維持するということを示すのです。
- 短い期間の成功する機会を作ります(…)。"成功"を体験することで、すべての人のフォーカスを維持し、努力に必要なエネルギーを新たにします。こうすることで、Scrumへの転換の進捗を計測するときの論点が生まれます。
Stephen Younge氏はZDNetのゲストブログで大企業のプロジェクトでアジャイルを成功させる方法について書いている。氏はアジャイルの原則を異なるレベルで適用することでアジャイルをスケールする方法を説明する。
企業、あるいは、プロジェクトが成長するについて、アジャイルは大きな目標を見失ってしまうと言われています。需要の管理や、設計、データベース標準、依存性、戦略の立案などです。しかし、アジャイルは再帰的であり、成長を可能にするスケーラブルな特性があります。アジャイルでは、異なるレベルで同じトレードオフと手法が適用される場合があります。例えば、単一のScrumチームが7から9人で構成され、ユーザストーリーに対して2週間のイテレーションを計画します。一方、単一のアジャイルプログラムは7から9のチームで構成され、顧客のフューチャーに対して四半期の計画をします。
あなたは、組織の大きさにScrumを拡大することにどのような知見を持っているだろうか。