一見したところ、組織の問題は「タスクが多すぎる」、「リソースが足りない」、「不安定な市場状況」のように見えます。 よく調べてみると、主な理由は「反射」と妄想によって形成される悪い習慣であることが判明します。
非常に有名な企業の1つは、1997年にスクラムが成功した例であり、Danube Technologies、Inc.に支援を求めました。 2009年には、「市場」が競合他社よりも柔軟性が低いことが示されたためです。 1997年に開始されたスクラムの展開は、大企業に固有の問題との10年間の共存に耐えることができなかったようです。 残念ながら、大規模な組織でスクラムを実装しようとするほとんどの試みは、長期的な変革にはつながりません。 スクラムの実装に対する障害は、通常、ビジネス全体の成功を妨げることもあり、確立された組織は通常、それらを取り除くことに消極的です。
障害＃1：単純なリソース管理
PMBOKガイドには次のように書かれています：
「より多くのリソースを追加して、より短い時間枠で同じ量の作業を実行するために予算を増やす必要があることがよくあります。」ソフトウェアに関して、Fred Brooks（Mythical Man-Month）は、前のものと矛盾する声明を出しています。
「プロジェクトが期限に間に合わない場合、労働力の追加によりさらに遅れるでしょう」
このパラドックスを解決するために、「リソース」の定義を見てみましょう。
仕事が新製品の開発である場合、対応するリソースは無形です。タスクの理解、トレーニング、対人コミュニケーション、革新。 スクラムチームは、個別およびグループの「フロー」状態を作成して、それらを最大化しようとします。 心理学者のミハリー・チクセントミハリイによると、「[ストリームで]あなたは完全にタスクに没頭しており、すべてのスキルを最大限に活用しています 。 」
スクラム開発チームのメンバーは、製品所有者と常に話し合っている目標に従って製品を作成するために、互いに集中的に対話します。 プロダクトオーナーは、チームとしてビジネス上の意思決定を行う責任があります。 結果は、一定の期間（たとえば、2週間ごと）の各スプリントの最後に表示されます。 スプリント中に、チームメンバーは共通の目標に興味を持ち、それらを達成するためにお互いを管理することを学びます。 理想的な状況（チームが働く施設について話すことを含む）でさえ、チームは成功を達成するためにいくつかのスプリントに参加する必要があります。 この有機プロセスの説明は広く知られています-ブルースタックマンモデルの「形成、攻撃、配給、実行」。 （ ブルース・タックマン、「フォーミング、ストーミング、ノーミング、パフォーマンス」 ）。
人をリソースとして話すのは単純です。 新しいチームメンバーは、「チームリソース」の概念の増加を保証せず、それを減らすことさえあります。 スクラムで1年間働いた後、クライアントの1人が次のように語っています。 スクラムチーム自体が新しい従業員を採用することを決定した場合、まったく異なることになります。その場合、新しいチームメンバーを追加することが適切なソリューションになります。 ただし、チームが従業員を独立して雇用できる場合でも、チームの規模を7人以上に増やすことは不適切です。
場合によっては、これらが無形で数え切れないリソースであることを考えると、チームが増えると作業が速くなる可能性があります。
障害＃2：機能別に編成されたチーム
スクラム-チームは機能横断型のチームであり、スプリントごとに徹底的にテストされた製品の増分を作成し、徐々に機能を増やします。 最も人気のあるスクラムの書籍では、「潜在的に出荷可能な製品の増分」というフレーズを18回使用しています。 それにもかかわらず、プロジェクトの最初に「分析スプリント」または「設計スプリント」を使用し、統合とテストを後の段階に延期し、作業の各部分を完了するために異なるチームを巻き込む「スクラムを実践する」と主張する人々に会います。 ウォーターフォールプロジェクト管理モデルから取得した習慣は、何かを行うには手遅れになるまでリスクを隠します。
スクラムでは、各スプリントには開発に固有のさまざまなアクティビティの組み合わせが必要です。 継続的な要件分析、継続的な設計、継続的な統合、継続的なテスト、チームメンバー全員による柔軟性を獲得しています。
障害＃3：コンポーネントアーキテクチャ別に編成されたチーム
1つのコンポーネントで作業するために作成されたチームは、製品機能の方向を変えるビジネスチャンスを減らし、製品マネージャーや所有者とのコミュニケーションのボトルネックの数を増やし、追加の統合リスクをもたらします。
新製品の開発が生産と同じくらい予測可能な場合、そのようなチームは効果的です。 実際には、優先順位が変わり、見積もりが間違っていることがわかります。 したがって、複数のコンポーネントに影響を与える可能性のある開発をリードするために、適切なタイミングで適切な人々を引き付けることは困難です。
コンポーネントチームの反対は、新しい製品機能の開発に特化した機能チームです（ 機能チーム ）。 機能チームは、コンポーネントと分野の両方をカバーしているため、ビジネス向けの機能タスクを、製品の薄くて完全にテストされた「垂直スライス」で実装できます。 このアプローチは、チームの自律性、自己組織化、および責任の概念に基づいて、前世紀の概念を置き換えることを目的としています。 機能チーム製品のバックログは、テクノロジーの依存関係ではなく、ビジネスニーズに基づいています。 ガントチャートをまだ使用している場合は、機能コマンドをまだ整理していない可能性があります。
機能チームの作成にはコストがかかります。開発者は新しいスキルを習得する必要があり、最初はスキルが低下します。 幸いなことに、ほとんどの開発者は新しいスキルを学ぶのが大好きです。 技術的な「 コンポーネントガーディアン 」を各エリアに割り当てるなどの方法は、チームが学習するときにアーキテクチャの整合性を保護するのに役立ちます。 他の大規模開発と同様に、継続的な統合（1日1回よりも頻繁に実行される自動化されたテスト）は、製品の全体的な状態で検出されない欠陥を防ぐために重要です。
組織が機能チームの管理を学んだ後、次のステップは、機能分野への依存を最小限に抑えた汎用機能チームを作成することです。 このプロセスには、組織内での長年の継続的な学習が必要になる場合があります。
障害＃4：気晴らし
典型的な大規模組織は、タスク間の不要な切り替えのために数百万ドルを費やしています。 チームは、高いパフォーマンスと品質に必要な自己組織化の状態を達成するために、チーム構成の面で焦点と安定性の月を欠いています。 一部の人々は、常にいくつかの「クリティカルパス」を常に使用しているため、全体的な生産性が大幅に制限されます。 効果的にスケーリングするには、これらの人々はタスクの実行者ではなくメンターにならなければなりません。 彼らの影響力を高めるために、彼らは何らかの制御をあきらめなければなりません。
専門性を高める従来の管理手法は、問題を悪化させるだけです。 スプリントプランニングミーティング中に、スクラムチームに作業を提供する必要があります。 マネージャーがこれを考慮せず、特定のパフォーマーにタスクを割り当てた場合、スペシャリストは他の人に重要なスキルを指導し教える機会がありません。 スプリントプランニングの会議の1つで、最初に尋ねられた質問は「このスプリントで誰が私たちのために働くのか」という事実に出会いました。 スクラムチームから期待されるものの、常に引っ張られている人々は、残りを訓練しません。 そして、組織はこれらの問題を日々ますます掘り起こしています。
より高い位置では、マルチタスク、注意散漫、不安、および何が起こっているかを制御できないことに関連する問題がさらにあります。 プロダクトオーナーは同じ会議で1時間遅れてイライラし、10分後に再び逃げました。 そして、彼らはこれが常に起こると私に言った。
また、昼食後、彼は60人の従業員との会議に専念することができませんでした。彼は電話のサービスを通じて別の問題を同時に解決しようとしていたからです。 これらのシーンの偶然の観察者は、これらの猛烈なイベント駆動型の奴隷がさらなる発展のための戦略に責任があると示唆することはできませんでした。
スクラムチーム間の効果的な水平コミュニケーションは、プロダクトオーナーが作業の優先順位付けや最終要件の決定などの責任に冷静に集中するのに役立ちます。
障害＃5：製品バックログを継続的に確認、優先順位付け、およびドリルダウンしたくない
製品を開発する場合、通常、実行する必要がある新しいタスクを発見する速度は、開発自体の速度よりも先です。 これに対処するために、プロダクトオーナーは洗練ミーティングを実施して、スプリントごとにプロダクトバックログのタスクを確認、優先順位付け、および洗練する必要があります。 バックログに含まれるタスクが大きすぎる場合（「叙事詩」）、重要な側面を見つけて、それらを小さなサブタスク（通常「ユーザーストーリー」と呼ばれる）に分割する必要があります。 製品所有者は作業量を管理し、リリースに含めるタスクを決定し、開発の速度とスプリント中に実行された作業量に関するデータを考慮します。
障害＃6：技術的負債
組織管理の問題は、最終的にソースコードで確認できます。 そして、「技術的負債」は、製品に問題を引き起こし、変化のコストを高くしています。 理想的には、回帰テストは、特定の知識への依存度を高める専用ツールを使用せずに、製品の開発に使用されるのと同じプログラミング言語を使用して自動化できます。 テスト駆動開発（TDD）などのスキルは、20世紀にその価値を証明しました。 21世紀には、どの開発者も柔軟な方法論のスキルを持つことが期待されています。 そして、これらのスキルをまだ持っていないチームは、学習するまで「垂直タスクカット」で作業を試みる必要があります 。
障害＃7：変更への抵抗
スクラムは、チームごとに1人（ScrumMaster）を割り当てて、 このような障害の特定と克服に専念します。 勇気、想像力、リーダーシップのサポートが必要です。 そのような問題に注意を払うスクラムマスターが少なすぎると、管理者はこれを行う人をサポートしないことがよくあります。
「タスクが多すぎる」、「リソースが足りない」、または「不安定な市場状況」は、これらの問題を解決するために特別に設計された柔軟な方法論を導入しないことの良い言い訳にはなりません。 また、変更の責任者は、柔軟な方法論の実装に関する障害を克服するための準備を整え、問題の主な原因が悪い習慣の維持、形成された「反射」およびエラーであることを認識する必要があります。
元の記事のテキスト： 企業の敏Ag性に対する7つの障害
投稿者： Michael James
翻訳： ダニエル・チェルニーシェフ
著者の同意を得て翻訳。