複数のスクラムチームが単一のバックログに移動

現在、私たちは過去1年間、独自の製品バックログを処理する5つのスクラムチームを抱えています。各チームは独自の専用システムで作業しますが、基盤となるテクノロジーは同じ.Netです。

単一のバックログから機能ベースのチームに移行することについては、多くの議論がありました。その理由は、私たちの主要なシステムの1つにかなりの量の作業があり、その年のすべての作業を実行するのに十分な容量がないためです。もう1つの重要な理由は、ポートフォリオの変化に迅速に対応できる柔軟性が高まることです。

1つのバックログで作業するように2つのチームを変更する決定が行われましたが、開発者は他のシステムでの経験がありません。私たちがしていることの1つは、エクスペリエンスシステム開発者をチームに移すことによるクロススキルです。

私の質問は、2つ以上の異なるシステムの単一のバックログへの移行を経験したことがありますか。あなたの課題は何でしたか？それを機能させるために何をする必要がありましたか？

1つのバックログを使用して、約6のプロジェクトを管理しています。プロジェクトについてどのように差別化したいかに依存するため、「約」と言います。

大まかに言って、私たちは5人または6人の製品所有者を抱えており、その一部は複数の製品を所有しています。私たちには、7人の開発者とチームリーダーがいる適度に小さなチームがいて、彼には時間があるときにもコーディングを行っています。そして、私たちのプロセスフォークと協力してアイデアをパイプラインに移す伝道者が数人います。もちろん、何人かの人々はいくつかの帽子をかぶって物事を濁らせますが、私の答えではそれを無視します。興味深いことに、私たちは正式なスクラムマスターを持っていません。

バックログをマージする必要はありませんでしたが、それはあなたの側で簡単な仕事のように聞こえます。

物事を整理しておくのは大変なことですので、考慮すべき点をいくつか紹介します。

• ガバナンスが鍵です。パイに管理指がある人は、大幅な変更を行う前に他の人とコミュニケーションをとる必要があります。また、変更を行うユーザーは、変更を行う権限を十分に備えている必要があります（悪い変更に備えて熱心に対応する準備をしておく必要があります）。私たちのチェンジメーカーは強力な幹部の支持を得ており、線がエリアの周りにかなりはっきりと描かれています。しかし、疑問がある場合は、変更する前に尋ねます。

• バックログのグルーミング、優先順位付け、およびキックオフに関連するオーバーヘッドが増える可能性があります。定期的にすべての所有者を集めることは難しいため、儀式としての優先順位付けは最も影響を受けます。優先順位を交渉したり、優先順位を下げないという悪い知らせを伝えたりするために、多数の仲介者を使用します。

• 私たちの仕事の多くは外部のコミットメントによって推進されています。それは私たちの決定から自律性の一部を取り除きますが、それはビジネスの現実です。ただし、開発者はその変更に注意する必要があります。知覚できないコントロールの喪失がある場合、羽毛は波立たせることができます。ただし、コミットしすぎないようにしており、スプリントにするための第一歩を踏み出している一部の製品所有者には「ノー」と言わざるを得ませんでした。

• 通常、2つの方法を使用して、商品バックログアイテムが属する商品にタグを付けます。グルーミングやその他のタスクが簡単になるという理由だけで、両方を使用します。

  1. PBIタイトルの前に、製品名または簡略版を付けます。
  2. 製品全体を示す別のフィールドがあり、これも入力する必要があります。

• 私たちはクロストレーニングに意識的な努力を払い、すべての人がさまざまな分野で手に入るようにする必要があります。開発チームに関しては、非常に大きなコードベースがあります。私たちが行うコードの一部は、非常に特殊化されています。私たちのチームリードはその点で素晴​​らしいです、そして彼は私たちのコミットメントレベルを一段下げるので、クロストレーニングから来る非効率を受け入れることができます。この点では、強力なチームリーダーを持つことが重要です。

• スプリントの時間枠を維持するために最善を尽くします。新しいチームメンバーとの複雑なプロジェクトは、コミットメントによる珍しいことではありません。分岐に関するプロセスは、ここで本当に役立ちます。すべての作業はブランチに対して行われ、ブランチはその後トランクリリースにマージされます。アドホックトリガーに加えて、毎晩実行されるビルドサーバーもあります。ビルドを中断した開発者は、24時間以内に問題を認識して解決します。限目。24時間以内に解決できない場合、コミットがロールバックされ、上級開発者が悲しみを与えます。そして、ビルドを維持することに関しては、上級開発者は自分自身に最も困難です。

• コードのウォークスルーとレビューはさらに重要になります。さまざまな分野で何が変化しているかを全員に最新の状態に保つのに役立ちます。

• 同様に、毎日のスタンドアップには、すべての開発者とUI担当者が関係しています。私たちは、有益なコラボレーションコミュニケーションとあまりにも多くの人々からの非効率性の端にいます。しかし、スタンドアップを15分未満に保ち、サイドディスカッションからすぐに進みます。通常、5〜10分で完了します。

• 速度や全体的なコミットメント、バーンダウン率などのメトリックへの影響について話すことはできません。これらの側面は、私たちがしっかりとフォローするには十分に重要ではありませんでした。YMMVなので、考慮してください。これはまた、各チームがストーリーポイントの合理的に類似した定義を持っていることを前提としています。そうでなければ、それはマージ後の最初の見積もりを台無しにするでしょう。また、以前と同じ測定単位を使用していないため、履歴比較でいくつかの問題が発生します。簡単な方法は、メトリックの「新しいチーム」を宣言し、マージ後にデータの収集を開始することです。

• このアプローチには大きなメリットがあります。すべてのハンドが1つの領域に集中しているスプリントがあり、短期間に多くの変化を打ち消すことができます。特定のプロジェクトに通常の2倍の開発者をすばやく適用できることから得られる価値を過小評価しないでください。ただし、事前にクロストレーニングを行う必要があります。また、テストサイクルやグルーミングなどにより、「何もしない」という開発者がいないことも意味します。取り組むべきバックログは常にあります。

• R＆Dプロジェクトに時間を費やす。そうでなければ、彼らが亀裂をすり抜けるのはあまりにも簡単であり、あなたはそれらの領域に投資する機会を失います。

• 自我のないコーディングに本当に取り組みます。ある分野の専門家はいるかもしれませんが、コード領域の所有者はいないのです。地域に異なるスタイルが導入される場合、傷ついた自我の機会を防ぐことは重要です。新しいコードがチームの基準を満たし、機能している限り、問題はありません。それが専門家がやった方法ではないからといって、それは問題ではありません。

• 関係するチームが同じコーディング規則とスタイルを使用していることを確認してください。統合の試みに混乱をもたらすのは、ここでの矛盾のようなものではありません。

• あなたの回顧展を続けて、それらをグループとして持ってください。何が機能しているのか、何が機能していないのか、そして何を別の方法で試す必要があるのか​​について全員のフィードバックを得ることが重要です。これは、チーム内の友情の感覚を促進し、開発プロセスに関する所有権の感覚を与えます。

スクラムの正解は「チームに質問する」です。これは、自己組織化の原則であり、彼らは自分たちを再構築して、仕事を迅速に終わらせることができるはずです。チームの多くの人が部外者よりもコンテキストに関する知識を持っていることがわかり、彼らは何が最善かを知っています。これには製品所有者も含まれます。

あなたがここに来て質問をしたのは、気分が悪いことや懸念を隠していたためだと思います。そこで、正しい決定を下すためにチームと話し合うためのヒントをいくつかお伝えします。

プロダクトオーナー

バックログの製品所有者は1人だけで、これはビジネス担当者またはビジネスを代表する担当者である必要があります。IT管​​理であってはなりません。大きなバックログには多くのアイテムがあり、複数のチームがあると、1つのPOで処理するには多すぎる可能性があります。このため、バックログを個別に保持することをお勧めします。

複数のPOがある場合、チームは1つのPOとバックログにスプリントで専念する必要があるため、必ず複数のバックログが必要です。その理由は、チームが製品所有者の優先順位間の競合を管理する必要がないためです。

製品開発とメンテナンス

メンテナンスチームは、多くの小さな拡張機能、複数の異なる製品のバグ、そして場合によっては複数の製品の所有者と作業します。これらのBAUチームは、複数の製品所有者間の競合をスケジュールし、管理するためにIT管理のサポートを必要としています。

プロジェクトチームは、一度に1つの製品に集中して、コンテキストの切り替えを最小限に抑え、一度に1つの優れた製品を提供する必要があります。コンテキストの切り替えにより、ある程度の技術的負債がある多くの平凡な製品が提供される可能性があります。

コンテキストの切り替え

複数の製品または異なる機能で作業すると、コンテキストの切り替えが発生し、チームの生産性が低下します。POはこれを考慮に入れて、次の作業、およびどのチームがどの作業に取り組む必要があるかを検討します。切り替えの量は重要ではなく、単なる理論上の問題ではありません。これは現実的であり、これによりチームの生産性が最大80％低下するのを目にしました。

優れたPOは、グループの機能と作業の種類を試し、コンテキストの切り替えを少なくして、パフォーマンスを向上させます。

危険

悲しいことに、経営陣は時間、資金、予算、ビジネス上の圧力のリスクをチームに課します。チームはこれに同意することでこれを受け入れます。開発の専門家として、意思決定の事実と影響を簡単に述べ、ビジネスに独自のリスクを負わせる必要があります。

例

• ばかげた時間に同意する。むしろ、仕事を適切に行い、ビジネスに時間の問題を管理させるために、どのような努力が必要かを言います。

• 見積もり。ビジネスは、チームが複雑さと不確実性のある世界で正確に見積もることを期待しています。チームは、予想外の課題が原因で見積もりが超過した場合に、その可能性を軽減するために、何をしているのかをビジネスに質問する必要があります。チームは脂肪を考慮に入れるべきではなく、ビジネスを考慮に入れるべきです。

• 技術的負債。チームは、十分にテストされた高品質のコードを実行することを推定し、それについて推定する必要があります。つまり、圧力による欠陥の書き込みを停止します。ビジネスがより低い品質を求めている場合、それは彼らが取るリスクであり、物事がうまくいかないときはその問題です。

プロフェッショナリズム

適切なものを合意された品質で構築することを表明することにより、専門家になります。手元にある事実に基づいてあなたの最高の能力を推定します。これらの事実が変化したら、それを伝え、見積もりを調整します。開発チームとして、優れた製品を構築し、ビジネスリスクを負いません。期待を伝え、管理する。

調査して適応

チームは常に改善する方法を模索する必要があり、それが物事を改善するだろうと感じた場合は、それを試す必要があります。次に、改善点があるかどうかを調べます。最後に、彼らは新しいアプローチに適応して改善するか、機能しない場合はそれを廃棄する必要があります。改善を求める背後にある意図は常にそこにあるべきです。

ボトムライン

最終的に、バックログの管理はPOの選択です。仕事のキューをどのように管理するかは、彼ら次第です。唯一の考えは、彼らはすべてのチームへの作業のパイプラインを健全で良好な状態に維持しなければならないということです。したがって、決定するのはPOです。

その契約

スプリント計画セッションでは、チームは、明確で明確で注文された手入れされた製品のバックログ項目のリストを期待する必要があります。POとの短い議論で、チームはPOが何を望んでいるかを正確に知る必要があります。 何だ。次に、チームは彼らがどのように構築するのかに焦点を当てます。

POが十分に準備された計画会議に来た場合、誰がバックログがどのように管理されるかを気にします。POがスプリント計画会議の準備ができていない場合、これはSMによって対処され、これは完全に受け入れられず、チームの問題ではないため、非常に目立つようにする必要があります。

最近、別のチームのバックログを吸収しました。チームには1人のメンバーしかいなかった（チームの大部分はいない）が、彼らのバックログには実際の作業があります。私たちは彼らの仕事にあまり詳しくありませんし、彼らも私たちの仕事にあまり詳しくありません。

バックログはマージされますが、それは誰もがすぐにすべてに取り組む必要があるという意味ではありません。それを期待するのは不合理です。そのため、誰もが両方のバックログですぐにすべてを実行できることをあまり心配しないでください。

代わりに、両方のチームが以前取り組んでいたこととまったく同じように取り組むことから始めます。唯一の違いは、すべてが同じバックログにあることです。

次に、すべての反復/スプリントで、各チームのメンバーの何人かが他のバックログのストーリーに取り組みます。誰もが馴染みのないアイテムで同時に作業しないようにすることで、お互いのシステムを学習するコストを分散させることができます。時間が経つにつれて、チームはお互いの知識を徐々に吸収していきます。

すべての学習を事前に行うと、パフォーマンスが大幅に低下します。上級管理職の誰かがきっと気づくでしょう。新しいチームがパフォーマンスの低下を補うことができるように、別のチームのバックログを吸収することを余儀なくされます... :)冗談はさておき、これは私の推奨事項です。

あなた（または経営陣）が2つのチームのマージされたバックログを作成したいのは、一方のシステムのバックログ項目のみを選択し、両方のチームがそれらを処理できるようにしたいためです。

これが事実であるとき、彼らが慣れていないシステムに取り組むことを強いられるチームからの多くの摩擦を期待してください。チームがすべてのストロー（つまり、「ホーム」システムに関連する小さなバックログ項目）を取り、以前取り組んでいたシステムでの作業を続けることを期待してください。彼らを責めるのは誰ですか？苦手なことをやるのは面白くない。そして、他のチームがあなたが得意ではないものとして得意であるという事実は、それをさらに悪化させます。

したがって、これを成功させる唯一の方法は、2つのチームを分割し、2つの混合チームに形成することです。そうして初めて、（現在の）「重要な」システムですべての開発者が迅速にスピードアップできる可能性があります。

そのようにするのはあまり良いことではありません。私の前の会社は、大企業ではさまざまな人がさまざまなことに取り組んでいたため、単一製品の単一チームモードに入りました。

プロジェクト間の切り替えにも労力がかかります。また、オーバーヘッドの開発を始める新しい人がいる場合は、本当に大きな負担になります。開発したシステム、異なるリポジトリなどへのアクセス権を取得する必要があります。

私は専門化を好む、人々は彼らが何をしているかを知っており、必要なすべての情報を持っている、プロジェクトの落とし穴を知っている、そして人々はあなたが彼らを働かせるためにプロジェクトからプロジェクトに落とさなければならない、すべてのお金を吸い取らなければならないという気持ちを持っていないそれら。

彼らがプロジェクトでアイドリングしている場合でも、プロジェクト間でジャンプするよりも、慣れ親しんでいることのほうがはるかに生産的です。