スクラムの概念と利点についてはある程度理解しています。それを念頭に置いて、私が現在働いている会社の失敗したスクラム製品管理構造を改善しようとしています.3つの別々のB2C製品があり、同じ人口統計に対応し、同じWebサイトでアクセスできます. 各製品には、製品所有者とその背後にある独自の開発チームがいます。
ターゲット ユーザーが類似しており (それが重要かどうかは不明)、3 つの Web 製品の性質が類似している場合、チームを統合して 1 人の製品所有者と 1 つの開発チームだけを持つことに関連する潜在的な利点/リスクは何ですか? 頭に浮かぶいくつかの質問は次のとおりです。Web サイトに 3 つの異なる製品がある場合、3 人の製品所有者と 3 つの異なるバックログを持つことは理にかなっていますか? また、プロダクト所有者が 1 人しかいない場合、その所有者を選択するための最適な指標は何ですか?
チームで何をすべきかを検討する前に、失敗の原因を特定してください。
ふりかえりは行っていますか？チームに解決策や改善方法に関する提案をしてもらいます (スクラムはチームと個人の責任を強調します。チームは解決策に参加する必要があります)。
複数の PO は、ほぼ確実に、チームにとってより混沌とした環境につながります。PO の優雅さの一部は、「What」の質問に対する最終承認のためにチームに 1 人の頼りになる人物を与えることです。
しかし、私は先を行っています。まず、問題をよく理解してください。
チームを統合する必要がありますか? わかりませんが、7 +- 2 のルールはかなり良い経験則です。同様のことに取り組んでいる場合は、おそらくアーキテクチャ チームが必要です。チームの構成は問題ないかもしれませんが、ワークフローには別のハングアップがあります。
優れたスクラム コーチを導入することを強く検討してください。数多くのトレーニングやコーチングのコンサルタント会社があり、それらの人々は私たちのような人々が実装されるのを助けるために国中を旅しています.
私はこれまでに 2 回スクラムを実装しましたが、正直に言って、トレーニングを導入することがなければ、スクラムはそれほどうまくいかなかったでしょう。(また、管理者のスポンサーも必要です。私の実装では、CIO にさえトレーニングに参加してもらうことができました。これは変革でした)
あなたは「会社のスクラム製品管理構造の失敗」と述べていますが、会社の現在のスクラムプロセスで 何が失敗しているのかを正確に理解することから始めることをお勧めします。
単純に 3 つのチームを統合しようとすることには非常に慎重です。これを行うと、企業文化が非常に破壊され、抵抗が生じ、それでも求める結果が得られない可能性があります。
現在の失敗を理解するための 1 つの良い方法は、ワークフローを視覚化する方法を見つけることです。これは、開発ライフ サイクル中にボトルネックや見逃された期待を明らかにするのに役立ちます。
かんばんはこのための優れた手法であり、新しいプロセスや変更を導入する必要はありません! ホワイト ボードのスイム レーンを使用して現在のワークフローを描画し、ボード上の WIP を制限し、カンバン ボードの周りで毎日のスタンドアップ スクラム ミーティングを実行するだけです。これにより、現在のプロセスで何が失敗しているのかを非常に迅速に理解し、判断できるようになります。
もう 1 つの優れたリソースとして、Henrik Kniberg の「Lean from the Trenches」もお勧めします。
これはチームの問題ではなく、管理上の問題です。スクラム マスターとしてのあなたの役割は、機能不全を指導することです。製品間に矛盾があり、チームのパフォーマンスが最適ではない可能性があります。
既存の製品所有者に意見を聞いて、これが問題であるかどうかを判断してください。これをどのように管理するかを選択するのは、各製品所有者の特権です。これらの異なる Web サイトは一貫性がなく、会社のブランドに影響を与える可能性があるため、PO のリスクとして、実行するかしないかを選択するのは PO です。
ブランドが危険にさらされていると感じた場合、次は 3 つのチームをまとめて (会議のために) 全員に同じ問題を提示します。次に、それを解決するように依頼し、彼らが何を思い付くかを確認します。
簡単に考えてください。3 つの製品すべてを 1 つに統合する場合は、PO で同じことを行う必要がありますが、製品が引き続き別々に存続する場合は、製品ごとに PO を保持する必要があります。
「性質が似ている」ということは、「2 つの製品が同じ機能を持っている」または「3 つの製品すべてがどのような方向に進み、どのように干渉するのか」という問題につながると思います。この種の問題を解決するには、「スクラム オブ スクラム」を使用できます。通常は、各チームが次のスプリントの目標を共有する、すべてのチーム メンバーが参加する毎週のミーティングです。この種のコラボレーションにより、誰が何をしているか、それがシステム全体にどのように影響するかをよりよく理解できます。
いくつかの追加のコンテキストが役立ちます。
チームの規模はどのくらいですか? (7 +/- 2 チーム サイズのガイドラインを思い出してください。) 彼らは機能横断的ですか?
個々の製品の特徴は何ですか? 逆に、各製品の「生物学的および技術的特徴」を製品群に追加すると、何が得られるでしょうか。
どのくらいの頻度で Web にデプロイしますか?