アジャイルは製品を台無しにしている

小さく、速く、自律的なチームの探求は、断片化された、混乱し、ばらばらの経験を生み出しています。

イラスト:Joan LeMay

楽園でのトラブル

製品コーチおよびコンサルタントとしての私の仕事で、私がよく聞かれる最初の質問は、「どうすれば[有名なテック会社X]に似せることができるか?」です。この質問は、 Amazonの「2つのピザチーム」、Spotifyの「分隊、部族、章、およびギルド」モデル、およびFacebookのそれ以来定年退職した「速く動き、物を壊す」というマントラ。全体として見ると、これらのストーリーは、クラス最高のデジタル企業である製品開発がどのように見えるかという、魅力的な全体像を描いています。

現代のテクノロジー企業が使用する多くのアジャイル手法の中核である、小規模で自律的なチームのアイデアは、企業の世界を依然として支配している官僚的な指揮統制構造に代わる魅力的な代替手段を提供します。しかし、このアプローチには大きなリスクも伴います。小さな自律的なチームによって作成された製品が、小さな自律的な機能の接続されていないセットのように感じるということです。

Facebookのメインナビゲーションの「探索」セクション(左)、およびGoogleのG-Suite(以前のGoogle Apps)製品の管理者が利用できる多くのわかりにくい機能リストの1つ(右)。

このアンチパターンの実際の例については、これらの非常に「クラス最高」のデジタル企業によって作られたフラッグシップ製品よりも遠くを見る必要はありません。 (特にりやすい例については、Facebookのホームページの「探索」セクションを参照するか、かつて「Google Apps」と呼ばれていた製品間をシームレスにナビゲートしてみてください。)デジタル製品がより大きく、より複雑になるにつれて、個々の機能を超えて、それらの機能を組み合わせてシームレスでまとまりのあるエクスペリエンスを作成する方法を検討します。そのためには、小規模で自律的なチームの作業を遅くする依存関係が、最終的にそれらのチームが最終的にサービスを提供する顧客に役立つ場合があることを認識する必要があります。

運用速度と顧客のニーズ

アジャイル運動の原則と実践は、急速に変化する世界に歩調を合わせたい組織にとって特に魅力的であることが証明されています。そして、間違いなく、大規模で相互に依存しているチームを小さな自律チームに分割すると、各チームが担当する製品の特定の部分に対する改善をリリースできる速度が向上する可能性があります。

問題は、小さな自治チームによって取り除かれた内部摩擦が外部の顧客によってまだしばしば感じられることであることが判明した。 2013年のハーバードビジネスレビューの記事「カスタマーエクスペリエンスに関する真実」は、小規模で自律的なチームについての会話でしばしば失われる重要なポイントです。むしろ、これらの機能がどのように連携してシームレスでまとまりのあるエクスペリエンスを作成するかを示しています。

このような作業をスコーピング、優先順位付け、および実行するには、必然的にチーム間およびチーム間の高度な調整が必要になります。その調整には時間と労力がかかります。各チームの成功を作業の運用速度で評価する組織にとって、これは、顧客にとって最も重要な作業と、各自治的な小さなチームが優先する可能性が高い作業との間の明白な切断を作成できます。これは最終的に疑問を招きます:自律は本当に私たちが目指している目標ですか?

一緒に戻す

大きな製品を小さく管理しやすい部分に分解するのは簡単なことではありませんが、それらの部分を元に戻すことははるかに困難です。多くのスケーリングされたアジャイルフレームワークは、小規模な自律性と大局的な調整のバランスをとるために部分的に設計されています。しかし、最新のAgile for Everybodyの研究中に発見したように、小さなチームをつなぎ合わせて調整するための最も重要なステップは、組織図とフレームワークの問題ではなく、コラボレーションと文化の問題です。 Spotifyの成長およびマーケティング担当副社長Mayur Guptaが私に言ったように:

Spotifyモデルに言及するとき、彼らは通常、ギルド、部族、および章について話します。しかし、それらは単なる儀式です。レポートの行を変更することで障壁を打破するとは思わない。真にクロスファンクショナルなチームがいる場合、レポート行は無関係になります…。人生とキャリアを続けていくと、これらの変化を本当に推進しているのは文化だということに気づきます。

言い換えれば、単に「Spotifyモデル」(またはその点でのモデル)に従うように組織図を再描画しても、Spotifyまたはそれらの「クラス最高の」企業を達成した文化を実際には再現しません。その最大の勝利。すぐに採用できる単一の運用モデルに従うのではなく、Agile for Everybodyを調査するときに聞いたほぼすべての成功事例は、3つのハイレベルな指針原則に従っています。

  • 企業中心の目標ではなく、顧客とそのニーズから始める
  • 大きな機会と戦術的な依存関係を特定するために、複数のチーム間で(多くの場合、それらのチームの正式な編成方法に関係なく)早期かつ頻繁にコラボレーションする
  • プロジェクトの進行に合わせて実際に新しい情報を組み込むための不確実性の計画

これらの原則を真に受け入れていたチームや組織は、大きな課題を小さな断片に分解するだけでなく、それらの断片がどのように元に戻るかを動的に再考することができました。彼らの目標は、運用速度や純粋な自律性を達成することではなく、顧客が直面する最大かつ最も重要な問題の解決に向けて協力することでした。

前進の道:銀の弾丸から弾力的な組織へ

この記事のタイトルは挑発的なものですが、重要な真実も語っています。スピード、自律性、「アジャイルフレームワークのルールに従う」など、運用中心の企業中心の目標に焦点を合わせすぎている組織は、顧客から遠ざかるリスク。内部摩擦を除去することは価値のあることですが、顧客が経験する外部摩擦を理解することから始め、その摩擦を最小限に抑えるためにたゆまぬ努力をしなければなりません。

カスタマーエクスペリエンスを犠牲にして速度と自律性を追求することを回避するために組織が実行できるいくつかの手順を次に示します。

  • 動作速度(つまり、リリースの頻度またはコードの行)によって厳密に進捗を測定する衝動に抵抗します。代わりに、顧客の観点から速度について考えてください。顧客が目標を迅速かつ簡単に達成できるように支援していますか?または、複雑で断片化されたエクスペリエンスでそれらを遅くしていますか?
  • 個人およびチームのインセンティブがローカライズされていないことを確認して、チーム間で作業するための時間と労力を暗黙的に落胆させないようにしてください。
  • 「良い依存関係」(つまり、努力や機能をシームレスに組み合わせて顧客に提供する機会)と「悪い依存関係」(つまり、組織が顧客のニーズを満たす能力を不必要に遅くする依存関係)を明確に区別する複数のチームが重複または冗長な作業を行っている状況を探す際には、特に注意してください。これは、依存関係を排除して自律性を促進しようとする組織に共通する問題です。
  • 接続されていない機能のゴミ捨て場になる可能性があるキャッチオールメニューおよびリスト(Facebookの「探索」など)には注意してください。顧客の前に配置する新しいアイテムはそれぞれ、時間と注意を犠牲にすることに注意してください。
  • 「俊敏性」を超えて、最も成功している組織は本当に弾力的です。つまり、大規模で形式的な再編成を行わなくても、新しい組織のパターンと構造をすばやくスピンアップできます。この弾力性を構築するための1つの即時的な方法は、複数のレベル、機能、および機能ベースのチームの代表者と一時的な「SWATチーム」を形成することです。追加のボーナスとして、そのようなチームに、既存の機能セットに関係なく、製品全体を一から完全に再発明するタスクを割り当ててみてください。 (今後の記事では、弾力性のある組織と「SWATチーム」アプローチについて詳しく説明します。)

このテーマの詳細については、私の新しい本「Agile for Everybody」をご覧ください。いつものように、考え、ヒント、提案がある場合は、matt @ mattlemay.comに直接お気軽にお問い合わせください!