マネジメントがアジャイルを受け入れない理由とそれに対してあなたができること
私の業務における最初のアジャイルへの移行には、会社のトップマネジメントの全面的なサポートがありました。 経営陣は、必要なすべてのトレーニング、ツール、およびコンサルティングに資金を提供しました。
リーダーは会社の全従業員と会議を開き、そこで新しい働き方や、文書化、開発、チーム構造の変化について説明しました。 真実は奇妙なことの1つでした。プロジェクト計画、ポートフォリオ管理、および予算編成は、人事や財務はもちろん、同じままである必要があります。 それ以来、私はこの話を何度も聞いてきましたが、違いは細部にあるだけでした。 同時に、うなずきに応じてすべて（多分2人のエグゼクティブを除く）。
私たちのトップは、多くの場合、アジャイルに多くの時間とお金を費やしますが、同時に、促進するイニシアチブを信用しません。 これは単なる一般的な問題ではありません。 これはほぼ普遍的な問題であり、普遍的な問題は体系的な原因を持つ傾向があります。
トップがアジャイルにならない5つの最も一般的な理由と、その対処方法を説明します。
エンタープライズアジャイル：急いで加速する
1.経営陣は、アジャイルを専らチームレベルの活動とみなしています
状況を考慮してください：通常のアジャイルな「変換」は、スクラムチームの人員の編成から始まります。 これにより、要件を開発に、開発からテストにコードを転送する時間が短縮されますが、チームのIT、運用、またはHRへの外部依存の問題は解決されません。
Mike Cottmeyerが最近Agile＆Beyondカンファレンスで指摘したように、外部の依存関係はチームの安定したパフォーマンス（速度）を破壊します。
そして、チームのパフォーマンスが不安定な場合、プロジェクトがいつ完了するかを言うことは不可能です。
コットマイヤーは、アジャイルコーチがリーダーを「チームを信頼し始める」よう説得しようとして問題を抱え始めたのはその瞬間だったと指摘した。 チームを信頼することは素晴らしいことですが、経営陣には答えのない質問があります。 例：「いつ新しいプロジェクトを開くことができますか？ マーケティング予算をいつ、どのように向けるか。 次のことを行うために予算はいくらですか？」
コットマイヤーは、チームの依存関係が重要なハードルだと言います。 彼は、アジャイルの適応または「実装」への道を進んでいる企業に、依存関係を除去し、回避策を探し、サービスレベル契約（SLA）を見直して機能チームをより予測可能にすることを推奨します。 スクラムとXPは、チームの相互依存の問題を解決するようには設計されていませんが、3つ以上のチームを持つ組織ではこれらの問題を認識しています。
ほとんどの場合、本当に狭い喉はチームの相互依存です。 そして、アジャイルなコマンドレベルのテクニックは役に立たず、マネージャーは望みの結果が得られず、不快な質問をし続けます。
2.経営陣が必要なレベルのトレーニングを受けていない
最近、私の同僚は、非常に収益性の高い会社の上級管理職向けに2日間のトレーニングを実施しました。 トレーニングは「アジャイルフォーエグゼクティブ」と呼ばれていましたが、これはよりスクラムトレーニングであることが判明しました。スプリント、ストーリー、自己組織化されたチームに関するものでした。 トレーニング後、経営者は「彼ら」がどのようにプログラムを「作る」べきかについて多くのアイデアを持ちましたが、依存関係を管理したり、ポートフォリオと予算をどうするかを理解するための本当のツールを手に入れませんでした。
ほとんどの経営陣は忙しすぎて2日間のトレーニングを受講できません。 とにかく、トレーニングスクラムは役に立ちません。 実際のところ、チームが通常読むソフトウェア開発に関するすべての本があまり役に立たないわけではありません。 管理の変更方法に関するサイトには、「研究と適応」や「迅速に学習」などの有意義なヒントがたくさんありますが、これらのヒントは、大企業でのプロジェクトの管理方法を管理者に伝えません。
CA TechnologiesのCorporate Flexibility AdvisorであるEric Willekeは、ほとんどのアジャイルコーチレベルのチームおよびプログラムが、管理のために日常的なレベルで決定を下したことはないと主張しています。 そして、この絶対に必要な経験がないという事実は、経営者が必要とするトレーニングを提供する準備ができていないことを意味します。
3.ウォーターフォールモデルは非効率性を管理から隠します
ウォーターフォールが一般的な慣行であったとき、組織は2ダースのイニシアチブを1回ずつ、もう1回、リードしようとしました。 最初の8つは高優先度で、次の8つは中優先度で、残りの8つは低優先度でした。 計画の日付は過去の経験と行われたコミットメントに基づいて表示され、PMOは約束を果たすために仮想チームを作成しました。
このアプローチの良い点は、何かが引っかかった場合、チームは優先順位が高いとマークされたものに簡単に切り替えて集中できることです。 これにより、Brooks法の悲しい結果（プロジェクトの最終段階に人を追加すると延長されます）が回避されます。これは、単に作業時間または既に関与しているプロジェクト参加者の参加割合を増やすからです。はい、「もっと」人を追加しません。
その結果、ウォーターフォールを使用する一部の企業は、プロジェクトの遅延による問題の一部を回避することができました。
もちろん、優先度が低いとマークされたものは、たとえあったとしても非常に長い時間がかかりますが、それらは優先度が低いことがわかっています。 組織はそれを取得します。 予定された時間に必要と宣言されたもの。 そしてもちろん、隠された滝の非効率性のすべての既知のタイプがここに存在します。すべては長い時間がかかり、突発的な決定、相互依存、および変更に満ちています。 しかし、プロジェクトは完了しているため、管理にとってこれはそれほど重要ではありません。
完成したプロジェクトは、組織がアジャイル開発に入るときに失われるかなりまともな圧力解放バルブであり、ジョブ内のタスクの数を制限します。 なんで？ チームが1つのプロジェクトに割り当てられている場合、チームから絞り出せる時間の割合はないので、損失を補うためにシャーマンを演じる方法はありません。 したがって、管理者は期限までにタキシングするための1つ少ないレバーになります。
もちろん、コースを継続することは常に困難ですが、一部の組織は、滝の助けを借りてそれを隠すことを学びました。 これを必要とするマネージャーは、ウォーターフォールで利用可能なツールがアジャイルエンジニアリングで消えることに気付くでしょう。 組織が複数のチームの相互依存関係によってブロックされていて、チームのパフォーマンスが不安定な場合、結果は依然として遅れます。
そのような企業の経営陣にとって、すべてがアジャイルに切り替えたときにのみ悪化したように見えます。
4.リードリーダーは1つの側面に集中しすぎています。
DevOpsは非常に魅力的で、多くの理由で人気があります。 トップマネジメントは本当にDevOpsを望んでいますが、DevOpsを購入して「インストール」できると考える人もいます。
最新のバージョン管理ツールを入手し、少し継続的な統合、自動テスト、ワンクリック計算を追加した場合、リクエストから実装までのパスを魔法のように数か月から数分に短縮できます。
これはすべて真実かもしれませんが、本当に強力なツールがありますが、組織はツールを入手するのではなく、それ自体で効率を高めて、はるかに多くを得ます。 ScotiaBankがアジャイルな実験を実施したとき、彼らは本番環境を変更するための7つのレベルの調整を発見しました。 このプロセスを立ち上げたコンサルティング会社は、開発と並行して承認作業を行った人をより多く雇用しました。 これは実を結び、また、コンサルティング会社のアカウントを補充しました。 このプロジェクトに携わったDave DameとAaron Sampsonは、異なる戦術に従いました。コントロールがリスクに対応するようにプロセスを変更する（現在は削減されています）。
同時に、管理者が関心を持っているのが継続的デリバリーの立ち上げ状況だけであり、彼らが目にする唯一の障害が「サーバーファームのDokerization」である場合、リスクを軽減することはできません。
完全なアジャイル変換には、組織構造の変更、技術的能力の開発と構築のプロセス、文化、製品管理、調達、契約慣行、さらには人事さえ含まれます。 これらの領域の1つまたはいくつかに焦点を当てると、多数の閉塞、ひざ、その他の問題を抱えたパイプラインのようなものが作成される可能性があります。
5.リーダーシップレベルでの多くの相反する目標
アジャイルアプローチは、それ自体のためではなく、望ましい結果を得るために適用されます。 CA TechnologiesのWillekeは、「目標のない柔軟性は無意味である」と急ぐ。 彼の意見では、アジャイルの実装は、市場投入までの時間の短縮、コストの削減、顧客サービスの向上、顧客ニーズへの製品コンプライアンスの向上、品質の向上と密接に関連している必要があります。 しかし、目標または「理由」が十分に明確でない場合、「何」と「方法」が混同されます。 この非常に「何」が最終的には、経営陣がそれ自体に必要だと考えたものとは完全に異なることが判明する可能性があります。
アジャイルでの移動の唯一の目標を特定することは非常に困難な場合があり、実際、それは必要ではありません。最終的に、経営者は上記のすべての利点を約束されました（ポイント1を参照）。 しかし、何でも可能です。
修正方法
何かが壊れている場合、それを修正するのに手遅れではないかもしれません。 破損を防止するよりも破損を修復する方がはるかに難しいことに注意してください。 大規模な組織では、すべての議論は上記のエラーに帰着します。 そして、これらの根本的な原因（不安定なパフォーマンス、リーダーシップのためのトレーニングの時間不足、「以前はそのようなことはありませんでした」、アジャイル開発の1つの側面のみへの過度の注意など）を見つけた場合、リーダーシップレベルでは、アジャイルとは何か、そこに到達する方法について明確な誤解があります。
そして、経営者がどのように「購入しない」かについてクーラーとチャットしても、これを修正することはできません。 そして、それに直面します。会議中の人々を正すことは、どこにも行かない素晴らしい方法です。
それどころか、最も不快な根本的な問題を見つけて対処してください。 これらがトレーニングである場合は、参考にしてください。 問題が理解を平等にしている場合、矛盾を特定するために明確な質問をしてください。 インプレースウォーターフォールが問題を隠し、アジャイルの問題を提起する場合、履歴データを取得して、予測可能性の問題を解決します。
「彼らは買わない」ことを制限として認識せずに、リーダーシップの問題を考えてください。 彼らと議論しようとしないでください。 独自の機能を拡張する方法を見つけてください。