スクラムはマルチプロジェクト環境に適していますか？

私は近い将来に職場を動かす予定です。彼らは私のスクラムの経験とそれが彼らのビジネスにどのように関係するかについて非常に興味があると思います。私はそれが彼らの環境で機能するかどうかを理解しようとしています。

私の現在の仕事場には、2つの製品/ 2つのバックログ/ 2つの別々のチームがあります。これらのバックログは、明らかに、私たちが開発するプラットフォームにビジネスが最も必要と考えていることに基づいて優先順位が付けられています。しかし、私が移動する場所には、外出先で多くのプロジェクトが同時にあり（2/3の担当者がそれぞれ作業している）、少量の作業が入り、毎日修正され、すべての顧客の成果物を想像しますほぼ同じくらい重要です。

それで、誰かが同じような環境でスクラムの経験を持っているのではないかと思いますが、実際に機能した例は何ですか？何がうまくいかなかったのですか？スクラムがこの状況で機能するためには、どのような考慮事項が必要ですか？

どのようにうまく機能するかわからないいくつかの側面があります：

1. チームのメンバーはプロジェクト全体で作業するため、分解するとスクラムチーム全体で作業する可能性があると思います。
2. おそらく頻繁に変更され、独自のタイムスケールを持つ非常に多くの可動部品の優先順位をどのように扱いますか？
3. 複数のプロジェクトに取り組むスクラムチームがある場合（その多くは1 Devのみを必要とします）、スタンドアップのコンテキストをどのように理解しますか？

私はまさにこの環境で開発マネージャーとして働いており、恐ろしい混乱から、この1年間で4人のチームとスクラムを非常にうまく導入しました。現在の場所に到達するには少し時間がかかりましたが、うまく機能しました。最も重要な行動をまとめますが、さらにお気軽にお問い合わせください。

1. 私はプロダクトオーナーとスクラムマスターの両方を務めました。各製品のバックログを作成し、関係者と協力しました。

2. 次に、すべてのバックログ全体に優先順位を付けたので、自分のバックログにまたがるプロジェクトに効果的に取り組みました。これはFogbugzを使用していたため、プロジェクトごとにフィルターをかけ、その利害関係者が私と一緒に作業してアイテムをシャッフルできるようにしました。

3. これからスプリントを計画し、すべてのプロジェクトとすべてのチームメンバーをカプセル化します。これにより、一部のチームメンバーは独自の特定のタスクに取り組みますが、機能横断的な作業と学習を奨励します。誰かが知らないことについて誰かが話している場合、彼らが私たちが理解できるように十分に詳しく説明しなければならなかったので、すべての立ち話は役に立ちます。これは学習を助けました。

   • この時点では、チームは結束に欠けていましたが、少なくともすべてのプロジェクトで物事を成し遂げ、ビジネスを満足させ、ソース管理/自動テストを追加することで品質を向上させていました。以前の混乱の大幅な改善でしたが、スプリントを完了する以外に目標を立てることができず、集中力を維持することも困難でした。また、デモは1つの利害関係者には特に関係がないため、デモもありませんでした。私はPOとSMの両方だったので、チームを過大に任せることに比較的穏やかでした。まだ到着前よりも多くのLOTを提供していたことは注目に値します。

4. その後、スプリントの焦点をゆっくりと1つの製品にシフトしようと試みたため、1つの製品でスプリントが60％になるようにしましたが、それでも他のタスクが必要です。最終的に、スプリントは90％が1つのタスクに集中し、利害関係者は「順番を待つ」ことを学びました-結局のところ、以前よりもはるかに多くのことを達成していました。これにより、一度に1つの製品でデモが可能になりました。

5. スプリントに重点が置かれると、私はスクラムの利害関係者をトレーニングし、その一部をプロダクトオーナーに変え始めました。これが現在の段階です。私は3人の製品所有者と仕事をしていますが、2つの製品を実際に所有しています。スプリントには「その他」のプロジェクトのタスクが1つまたは2つある場合がありますが、スプリントの主要な利害関係者が製品の新機能のみをデモするスプリントデモに十分に焦点を当てています。

これがお役に立てば幸いです。これが私の現在の雇用主との道のりであり、これまでのところ、Devチーム、ビジネスユニット、および（最も重要なことに）上司は非常に満足しています。

現在、私は4人のスクラムチームとして、私たちの会社のすべての製品の責任をある程度担っています。合計で約16の製品に加えて、半接続の1回限りの製品もあるので、経験から、スクラムはマルチプロジェクト環境には向いていないことがわかります。先に述べたように、常にさまざまなことに個別に取り組んでいる場合、チームの相乗効果を構築することは困難です。さらに、あなたの焦点は完全に異なるプロジェクトの完全に異なる割り当てに集中しているので、チームメイトの割り当ての作業詳細と相互に関連付けるのは難しいです。

さらに、特定の製品での「恋に落ちる」、または割り当てられていない分析は、とりわけ、コードの腐敗につながる可能性がある割り当てのターンオーバー率のために、ほぼ不可能です。

チームに割り当てられた複数のプロジェクトから逃れることができない立場にいる場合は、スクラムをお勧めしません。

受け入れられた回答は質問にかなり対応していますが、私の経験を共有することができます。私はSCRUMチームのメンバーが複数のプロジェクトを処理しなければならない2つの異なる状況にありました。SCRUMチームは複数のプロジェクトを処理できますが、特定の条件下でのみ可能です。

最初のケースでは、複数のプロジェクトが大きな課題を提示しました。私の雇用主は、全体としてアジャイル手法をまだ採用していませんでした。私は1つのプロジェクトでSCRUMを使用するパイロットの一部でした。

問題は、プロジェクト管理チームが、短時間の集中的なプロジェクトよりも、並行して長時間実行する多くのプロジェクトを優先することです。その結果、私のチームには開発者よりも常に多くのプロジェクトが割り当てられました。4人のチームが6〜10のプロジェクトをジャグリングするのは典型的でした。これは、かなりの量の運用およびサポートの責任も処理する必要があったという事実によってさらに悪化しました。

私たちが見つけたのは、チームはSCRUMチームに専念する時間のごく一部しかなく、信頼できる速度を確立できず、Sprintのコミットメントを行わないことを恐れて各Sprintの作業量を制限していたためです。他のプロジェクトからのすべての作業を計画に組み込むことは役立つかもしれませんが、それらのプロジェクトには固定の日付とスコープがあり、SCRUMを適切に実行できなかった可能性があります。

2番目のケースでは、会社全体が長い間アジャイルを採用し、SCRUMチームが複数のプロジェクトに取り組むことができる手段を開発していました。非常に効果的だったので、エンジニアとして、プロジェクトの半分が何なのかさえ知りませんでした！プロダクトオーナーはプロジェクトマネージャーと協力して、必要な作業を特定します。当社のエンジニアから提供された見積もりとチームの確立された速度を使用して、プロダクトオーナーは特定のアイテムがいつ完成するかについて合理的な予測を行うことができます。チームが一貫してコミットメントを満たしている限り、ほとんどの成果物の納期を気にする必要はありませんでした。

ただし、私たち全員が同じ小さなアプリケーションセットで作業していることが役に立ちました。チームは製品と連携しているため、同僚が何に取り組んでいるかを理解しやすくなり、必要に応じてプロジェクト間でフォーカスを移すことが容易になります。

つまり、SCRUMは、適切な計画と編成が行われていれば、複数の並行プロセスを処理するように簡単に調整できます。

私が理解していることはわかりませんが、「2/3の個人がそれぞれに取り組んでいる」場合、複数のチームがあり、それぞれがプロジェクトに取り組んでいるのと同じではありません。

彼らは継続的に取り組んでいる「製品」ではなく、定期的にプロジェクトを変更するかもしれませんが、それは大きな違いではありません。一部の場所では、チームが製品のさまざまな部分で作業し、各プロジェクトが完了した後に別の作業を行うように変更することさえ期待されます-主に知識の十分な広がりを確実にするため。