回答:
最大の問題は誤解です。一般的な障害は次のとおりです。
チームだけがスクラムを行っていますが、会社の残りの部分（営業、管理、人事など）はまだ古い方法で考えています。例：
顧客との継続的な相互作用および顧客の関与は非常に重要です。
HRは、チームのパフォーマンスが個人のパフォーマンスよりも重要であることを理解する必要があります。KPIはそれに変更する必要があります。
機能定義は継続的なプロセスです。プロジェクト定義は、顧客のフィードバックにより開発中に進化します。そのプロジェクトの期限により、必要な予算または結果の機能セットは変更される可能性があります（関係者による承認後）。
変更はプロセスの一部です。
推定は、5か月以内にすべての機能（最初は不明な機能の多く）が完了するとプロジェクトの開始時に言うことのできない連続プロセスです。
チームには決定を下す権限があります。チームは、次のスプリントで提供される機能の量にコミットしています。これは要求も命令もできません。
スプリントはチームにとって安全なゾーンです。チームが定義済みのユーザーストーリーにコミットすると、チーム外でコミットメントを変更することはできません。
古い組織構造の一部は、スクラムに移行するときには意味がありません。スクラムは、スクラムマスター、プロダクトオーナー、チームの3つの役割を定義します。他にも役割がありますが、通常、アプリケーションを配信するにはこれら3つの役割で十分です。一般的なナンセンスは、スクラムマスター、チームリーダー、製品所有者、および1人以上のプロジェクトマネージャーを持つことです。プロジェクトマネージャーとチームリーダーは、スクラムの重複した役割です。
スクラムマスターの役割を割り当てられたガイは、スクラムマスターを行っていません。スクラムマスターが障害を解決します。チームの邪魔をするものは障害であり、早急に解決する必要があります。最も一般的な失敗は、スクラムの経験がなくても、この役割を開発者に割り当てることです。この役割は、一般的なプロジェクトマネージャーを部分的に置き換えますが、スクラムマスターにはチームに対する権限がなく、スクラムマスターは実装する機能を必要としません。スクラムマスターは、実現不可能な要件を持つプロダクトオーナーに対してもチームを守ります。
編集：
重要なメモを追加しています。アジャイルアプローチを使用する場合、最大のビジネス価値を可能な限り迅速に顧客に提供することが主要なポイントです。しかし、顧客（製品所有者によって表される）は、ビジネス価値とは何かを説明しています。そのため、Scrumを使用するときに分析やドキュメントがないことが一般的に真実ではありません。顧客が分析またはドキュメントを要求し、ビジネス価値としてマークする場合（たとえば、今後数年で改善される大規模または長期プロジェクトのため）、それも作成します。最も基本的なアプローチは、ユーザーストーリーの受け入れ基準に分析とドキュメントを含めることです。このような場合の分析は、製品所有者との標準化された方法で文書化されたコミュニケーションです。
The most basic approach is including analysis and documentation in acceptance criteria for user stories.それも私の最初の反応です。ストーリーに受け入れ基準がある場合、それが最良のドキュメントになります。しかし、チームがいくつかの追加のドキュメント（トランクのREADMEや有用な情報を含むWikiを考えてください）を作成することに決めた場合、問題は発生しません。人々は、SCRUM =何も書き留められないことを恐れていると思います。
XPとスクラムの10年以上で私が気づいた最大の問題は、まだアジャイルを「あまり得られない」チームが、「アジャイルに柔軟に対応する」ことを決め、カスタマイズを開始し、特定のパーツをドロップするなどのことです。各部分が何をするのか、なぜそこにあるのかを明確に理解する。
最初に本で物事をやるとき、まだ「取得していない」ものを変更するチームよりも、スクラムでチームが成功するのを見てきました。
「最初のスプリント、すべての要件を実行します。2番目のスプリント、すべてのデザインなど、最後のスプリント、すべてのテスト」のようなものを取得するときです。滝とも呼ばれます。または、「とにかく座りましょう。このスタンドアップビジネスとは何ですか？」
Shuhariとの関係（http://c2.com/cgi/wiki?ShuHaRi）。
最大の問題は常に賛成です。いずれかのチーム、または主要な個人（プロジェクト管理、QA、開発など）が買収されていない場合、失敗はほぼ確実です。
別の関連する問題は、実際に関係する全員に、実際のスクラムとそうでないものを認識させることです。
新しいプロセスを使用しているので、プロジェクト管理が実際にこれを変更として開発者に直接届くチケットとみなし、明日行われることを期待している環境を見てきました。このような状況にあったか、スクラムを実装しようとする他の試みに失敗し、口に苦味がある人。これらの人々は、プロジェクトの脱線を試みることもあります。
私が見たもう一つの問題は、スタンドアップミーティングです。あなたはいつもスタンドミーティング中に座りたい男を取得します.... "私は悪いバックを持っている"または何でも。立ち上がった目的が何なのかわからず、政治や彼がその週末に何をしたかについて黙っていないのは、常に同じ男のようです。スタンドアップミーティングは、効果的なコミュニケーションの鍵であることがわかりました。これらの会議をだれにも毒殺しないようにすることが重要です。
management has actually taken this as a ticket to come directly to developersこれは、SCRUMプロセスが理解されていない状況の良い例ですよね？チームがスプリントの途中で新しいストーリーを受け入れられないこと。
少し前にスクラムに移行しましたが、率直に言って、それを実行する管理者は各スクラムを2週間のウォーターフォールプロセスとして扱いました。スクラムのルールを厳守し、それ自体がプロセスになりました！
これは私が見つけた問題です。すべてのアジャイル方法論は、あなたのために機能する方法で効果的に機能する柔軟性に関するものでなければなりません。プロセスによって禁止されている方法ではありません。たとえば、2週間のスクラムがあり、チームは（スクラムデモの終了と最初の要件レビューによるダウンタイムではなく）2週間では良い仕事をするのに十分ではないと感じたため、3週間。ショックホラー！スクラムあたり2週間が理想的であり、品質手順に文書化されたと判断したため、経営陣は拒否しました。
スクラムはアジャイルメソッドの中で最もアジャイルではありません。これがおそらく、その人気が高い理由です。古い警備員に売りやすいです。あなたは好きではないものを削除することになっていますが、私はそれが起こるとは思わない。私のアドバイスは、より柔軟でルールに基づいていないルールを採用し、代わりに必要なルールを追加することです。このため、クリスタルが好きです。
最終的には、半分だけアジャイルなマニフェストを覚えておいてください。
最大の問題は、クライアントがSCRUMプロセスを受け入れてアジャイルになる必要があることです。ほとんどのクライアントは、プロジェクトの開始時にこれを聞きたいと思っています。
理にかなっていますが、アジャイルとはまったく互換性がありません。ウォーターフォールの代わりにアジャイルが彼にとって良い理由をクライアントに説明する必要があります。
how much will it cost?、そして、彼らはすぐに詳細な答えを期待します。この懸念に対する私の返事は常に「最終的にあなたが望むものを正確に知っていれば、アジャイルは必要ありません。ただそれをコーディングしてください。」です。しかし、私たちは皆、それが起こらないことを知っています。;-)
SCRUMに初めて行ったとき、2つの大きな問題がありました。
1）製品所有者が実際にはいませんでした。製品の所有者であるべき人は誰も同意しないため、上司が役割を果たさなければなりませんでした。彼はいつも実際に答えを知っているわけではないので、この種のことは物事にクリンプを入れます。
2）外部コンポーネントの会計が苦手でした。最初の数回のスプリントでは、完全に自動化されたテストを実行する必要があり、使用しているシミュレーターの自動化で繰り返し問題が発生しました。どういうわけか、私たちはこれが起こることを理解することでそれ以上良くなりませんでした。
私のプロジェクトで私が直面する主な問題は、次のスプリントを予測した後に要件の収集が行われることです。受け入れ基準に基づいて推定します。要件の収集中に、微調整されたACははるかに大きいため、8時間で最初に見積もられたタスクは実際には24時間になります。スプリントのバックログを変更し、見積もりを修正してストーリーを減らすことはできますか？いいえ！アジャイルは、スプリントバックログを変更できないことを要求します！それが私のTLの言うことです。だから、私は時間を8時間と推定した元の受け入れ基準に従ってコーディングするべきではありません！神！いや！できません！それはアジャイルではないでしょう！