部門内のすべてのチームに統一されたスクラムアプローチを適用する

私が働いている場所では、最近、スクラムを使用してアジャイル開発を切り替えました。典型的な高まる苦痛を経験しましたが、今のところうまくいくように見えるアプローチに達しました（長期的にうまくいくかどうかは別の質問です！）。

明らかに、部門管理者はスクラムへの移行が機能していることに満足しています。しかし、彼らは私にとっては間違っていると感じることを始めています。

経営陣はチームを観察し、彼らにとって何が有効かを確認し、それを部門全体に処方します。のようなもの：

• 「完了」の定義
• ストーリーポイントに使用できるストーリーポイント値（たとえば、1、2、3、5、13などが、スプリント中に使用された唯一の値であるため、fib。シーケンスから8を省略）
• ストーリーポイント値1を「UIラベルの更新」に調整する必要があることをチームに伝え、上限を20に制限する
  • （すべてのプロジェクトにクライアントがいるわけではなく、すべての開発者がUIの経験があるわけではありません）
• ストーリーポイントの推定値100を使用して「このストーリーは後で分割する」ことをチームに伝える
• 無限のストーリーポイントの推定値を使用して、「これは壮大です」または「詳細情報が必要」を意味することをチームに伝える

私は彼らが役に立とうとしていることを理解していますが、上記のすべてがスクラムチーム固有のものではないのですか？つまり、あるプロジェクトの個人のグループで機能するものは、別のプロジェクトの別のグループでは意味をなさない場合があります。

非常に規範的で堅固なアジャイルアプローチに移行しているのではないかと心配しています。私はこれを考えることで正当化されますか、それとも私は過剰反応していますか？

編集する

明確にするために...「管理」と「マネージャー」によって私は製品の所有者を意味しません。私は、スクラムチーム外の、ソフトウェア部門内のマネージャーを意味します。

もちろん、あなたはそれを考えることで正当化されます。あなたが「スクラムを強制する」ことについて話しているという事実そのものが、鳴り響く警報のサイレンです。
スクラムは何よりもまずチームの自己組織化についてです。彼らは自分の仕事をする方法と自分を組織する方法を選ぶことができます。経営陣は、どのような作業を行う必要があるかについてのみ発言権を持っています。
チームが自分自身を編成する必要があるのは、個々のチームメンバー（および作業する人々）の性質の違いと、作業する製品の違いのため、チームが常に一意であるためです。あるチームにとって完璧に機能するプラクティスは、別のチームに悪影響を与える可能性があります。そのため、特定のスコープ（サンドボックスメタフォアがよく使用されます）内では、何が最適かを実験、学習、および発見する必要があります。
必要なのは非常に有能なスクラムマスター（チームごとに1人）であり、このディスカバリーでチームを導くことができますが、同時に管理者と協力して、チームがそのディスカバリーに進む自由を得ることもできます。

スクラムの最悪の悪夢の1つへようこそ。スクラムを採用するときに誰もが心に留めている素晴らしいものをスクラムが提供できない理由の1つに遭遇しました。

残念ながら、スクラムは、組織およびチーム全体で管理プロセスを集中化および作成する傾向がある上層部の管理者と互換性がありません。成功するために、上級管理職は彼らの考え方を変えて、彼らがチームから必要とするものに集中しなければなりません。彼らはチームの働き方に焦点を当てるべきではありません。彼らが関与すべき唯一の時間は、チームが理由を理解するためにパフォーマンスを発揮していない場合です。

私はあなたが経営陣と一緒に座って、彼らの要件と彼らがチームに何を提供したいかについて話し合う必要があると信じています。これは、すべてのチームにとってグローバルな要件になる可能性があります。それは、彼らが理解している、期間などの推定値である可能性があります。これらのことは、チームのプロセスに影響を与えるべきではありません。管理の期待とスクラムの実行方法を分離することが重要です。各チームは、プロジェクトを推進するための独自のペースと方法を見つけなければなりません。それにより、プロジェクトが成功し、生産性が高くなり、管理に必要なものが提供されます。たとえば、15ストーリーポイントの見積もりがある場合、チームはそれらのポイントを平均チーム速度に基づいて工数（または時間）で計算できるはずです。しかし、それはチームに固有のものです。

会社として、リソースのバランスをとることは競争上の優位性になるはずです。それ以外の場合は、このタイプのレバレッジを失う個々のソフトウェア会社の束を作成します。複数のチームとプロジェクトを持つ組織は、離職率とチームのバランスを考慮する必要があります。チームの組み合わせごとに、スクラムのやり方について本を書き直すのは良い考えではないと思います。

物事を集約して何かを測定しようとしているときは常に、一貫性が重要です。つまり、リンゴとオレンジを比較しないでください。経営陣はこれらの上位レベルのニーズに焦点を当てる必要がありますが、チームの運用方法の詳細にあまり関与しないようにしてください。彼らの提案を適用するようにしてください。ただし、1つのチームが例外である理由を守るために準備してください。特定の方法を個人的に好まない人は、大人のパンツを履いて対処する必要があります。

ある程度の柔軟性が必要なので、仕事をこなすことができます。必要に応じて一貫性を保つ必要があります。チームのメンバーシップが変更された場合、誰もがそれが仕事の最初の日であるように感じるべきではありません。

チームが変わることはないかもしれませんが、一貫性を持たせることでその選択にチャンスを与える必要があります。

いいえ、あなたは過剰反応しておらず、心配する十分な理由があります。管理は文化の変化に焦点を当てるべきです。経営陣は、チームの生産性を高めるために適切に機能するアジャイルセレモニーを使用して、正しい方向性を設定し、コンテキストをチームに提示してそれに取り組む必要があります。

私は1年以上ウォーターフォールからアジャイルへの変革を経験している組織で働き、私が働いているポートフォリオから始めたことは幸運だと感じています。彼らは当初、アジャイルチームが結成された1つのプロジェクトから始まりました。レトロ、相対見積もり、速度を使用した履歴予測などのアジャイルセレモニーによる配信の成功により、ポートフォリオ全体が独自のバックログを持つ追加のチームを形成しました。

経験から、アジャイルは規範的ではなく、クッキーカッターアプローチをロールアウトすることはできません。あるチームで機能したからといって、別のチームでも機能するとは限りません。これは経験からわかっています。元々、DoDのような同じものを適用することで、新しいチームをジャンプスタートできると思っていたからです。1ポイントの意味、8ポイントの意味。しかし、状況に応じて機能しないため、別のチームに適用してもほとんど意味がありません。ちなみに、8つのポイントを超える1つのチームストーリーは、大きすぎて分割する必要があったことを意味します。

うまくいったのは、チームがスタンドアップ、レトロ、ショーケースを同時に行い、新しいチームを改善するために気を引いて実装した各レトロアクションで行う必要があるように、チームのガイドラインを設定することでした。チームがストーリーナレーションの概念に精通し、カードを完成させて次のスプリントに忍び込まないようにして、2、3回のスプリントの後に、完了の定義やストーリーポイントのサイジングなどの他のものが導入されました。

いつプロジェクトが提供されるのか、また新しいアジャイルチームを形成する際にその状況を事前に伝えることは難しいので、これは経営陣にとって難しい売りです。しかし、現在、このポートフォリオは、俊敏なデリバリー能力が高いという評判を持っています。クッキーカッターのアプローチが引き続き他のチームにプッシュされた場合、私たちはまだつまずきます。

たとえば、チームメンバーがチーム間を移動する場合など、実際にはスクラムチーム間の不整合が問題になることがあります。

このようなチーム間の知識共有の問題をより機敏な方法で解決してみることをお勧めします。おそらく、リーンコーヒーやスクラムマスターのスクラムマスターが関与するセッションを実行するようなものです。これにより、この領域の所有権を取得していることを経営陣に認識させ、トップダウン方式で問題を管理するのをやめることができれば幸いです。