伝統的な管理構造のスクラム

Question

私たちは現在スクラムを担当しています。しかし、プロジェクトマネジャー（PM）、開発マネージャー（DM）、チームリーダー（TL）、テストチームリーダー（TTL）など、従来のレベルの管理構造は従来のものです。

チームリーダーはスクラムマスターであり、PM/DM/TTL、開発管理に連絡してチームのすべてのことをコントロールします...私たちのPOの責任は、単にPBLを維持することだけです。

私たちのマネージャーとチームメンバーは、従来の管理タイプに慣れています。彼らはスクラムに気を使わず、一部のスクラムルールは非公開です。 私は別のSMとして行動します、私は現在のステータスを変更したいと思います。

しかし、私は何の責任も持っていません、私たちの部門の普通の開発者です。誰もこの種の気になることがありますか？

ありがとうございます！

Answer 1

あなたが他の開発者から購入していない場合は動作しません。期間。

スクラムでは、特に早期採用フェーズでは、規律のヒープが必要です。

私は経営陣がそれを気にしないとは心配しません。あなたがソフトウェアを開発する作業を自由にすることができ、彼らが気にすることがすべて結果であるならば、毎朝10分立ち上がるかどうかは関係ありません。あなたがヒットしたいターゲットをヒットしている限り

もしあなたがチームに参加していないのであれば、が実際にになるのは苦労し、おそらく失敗して、まったく試していないほどの影響を引き起こします。

小さなプロジェクトで起動しようとすると、アイデアに乗っている開発者が少なくても、開発チームの残りの部分にどのように動作しているか、メリットとネガは何か（スクラムのすべての重要な部分を反映している）

あなたの経営陣を迎え入れるには、このようにいくつかのプロジェクトを実行した後、PMによって与えられた要件を開発するために必要な時間を見積もる方がはるかに優れていることがわかります。うまくいけば、より正確に期限を迎えることができます。

PMとBAは通常の方法で動作します。要件を手に入れたら、Scrumを使用して構築できます。それは理想的ではありませんが、誰もが買い物をするのには不十分で、ユーザーに直接話してユーザーのストーリーを書くのを手伝ってもらえません。

プロジェクトの完了に要する時間を予測するように求められたら、スクラム技術を適用することができます。仕様を細かく分割し、それらをスプリントにグループ化し、それに応じて開発し、うまくいけばより良い結果を生み出すことができます。

Answer 2

まあ、それは状況を変更したい、右が良いスタートだ

「私は、私は現在のステータスを変更したい場合は、別のSMとしての役割を果たす」。私は、経営陣の買収がなければ、それは難しいと言わざるを得ない。経験豊かなスクラムスピーカーやアジャイルコーチを迎え入れるようにして、すべての上級管理職が関与する貴社のプレゼンテーションやワークショップを行ってください。経営陣がスクラムを信じたら、そこから下り坂になります。

「スクラムマスターとして、チームリーダーの行為、彼はすべてのものを制御し、私たちのチームである」これはスクラムでチーム原理を力づける自己組織化と自己反する

。優れたスクラムマスターは、スクラムルール内の規律ある方法で、チームが自ら実行できる適切なレベルにチームを強化します。 1つの提案は、チームリードは、シニアデベロッパーとして働いている間にSMと異なるチームとして働くときに、異なる考え方を持つ必要があるということです。スクラムチームにチームリードはなく、スクラムチームメンバーのみです。あなたは真のリーダーシップを割り当てることはできません。それは、他者を助け、他人を指導するという評判を生み出すことによって得られる相互の役割です。 SMと開発の任務の間に、30％、70％、50-50の間、またはあなたが適切であると思っているものを吐くようにしてください。指揮統制は、チームにとって生産的ではありません。

私たちのマネージャーやチームメンバーが、伝統的な管理タイプに慣れている、彼らはスクラムを気にしない

Aスクラムトレーナーは「スクラム自殺をコミットしないでください」、私に言っ一度伝えていました。あなたのマネージャーがスクラムについて気にしないなら、彼らを説得しようとして解雇しないでください。皆さんが従うか、「しない」という方法論が何であれ、これはすべてビジネスだということを認識しなければなりません。あなたの上司またはマネージャがスクラムを気にしない場合、あなたの給料チェックはあなたの上司の承認に依存します。彼らが滝を気にしているなら、それに切り替えてください。気にするようにしてください。しかし、スクラムを途中でやってスクラムと呼んではいけません。

Answer 3

私は一度美しい言葉を聞いたが、誰がそれを言ったのか覚えていない。 「彼らはアジャイルを望んでいるが、それが何であるかを知らないため、アジャイルを与えるが、彼らが望むものは分からない」

これはあなたの会社で起こっているように聞こえます。誰かが、どこかでチームがスクラムを使いたいと思っていますが、それはチームではありません。

これは、特にあなたが非公式にやっている場合は、SMにとっては難しい仕事でなければなりません！私があなたのために提案できるいくつかのことがあります。まず、いくつかの基本的なコーチングテクニックを学びます：肯定的な言語、GROW frameworkとgiving and receiving feedback。これはスクラムの外にあるいくつかの追加のツールを提供し、管理職ではなくリーダーシップで誰かをサポートします（たとえ非公式のSMがリーダーになることもできます）。

次に、実際の慣行について心配しないでください。誰かがスクラムを義務づけていれば、チームはこれをとにかく強制するでしょう。代わりに、スクラムの価値と原則、特にコラボレーション、コミュニケーション、透明性に集中してください。チームが離れてサイロになるのではなく、お互いに仕事をするのを助けてください。あなたはそれらのための例になる必要があります。ペアプログラミングを義務づけてはいけません。スタンドアップを義務づけてはいけませんが、午前中はまず会話を行い、できるだけ多くの人をチームに引き込みます。 「継続的改善」の原則を見てください。 root cause analysis and the 5 Why'sを行う方法を学び、チームが何が難しいのかをよく理解して行動を取るようにします。

Mary Lynn Manns and Linda Rising "Fearless Change"もお勧めします。これは他の誰かがあなたを助けることができるように働くのに役立ちます。

最後に、@sjtをエコーし​​ます。スクラム自殺しないでください。しかし、それがあなたが本当に望むものであり、あなたの会社が正しい方法でそれをやっていないのであれば、他の場所を見るのを恐れないでください。基本のいくつかを学び、自分でTDDを実践し、新しい仕事を見つけましょう。

あなたが何をしても、幸運を祈る！変更する最初のステップは欲望です。

Answer 4

私が過去に功を奏したことは、痛みポイントを特定して伝えることです。確かに、ケント・ベックは、特にあなたを解雇させるようなことを言ったので、決して何かをするべきではありません。しかし、いくつかのスマートな人々は、一貫性のある一連のプラクティスを理解することに取り組みました。これらのプラクティスからの相違は、ほとんどの場合、痛みの原因になります。

要件の反復、設計の反復、実装の反復、およびテストの反復がある場合、Scrumを実行すると、これは理論上は機能しますが、実際は決して実行されません。 QAがテストされている間に要件について何かを学んだことを上司に指摘すると、QAが要件に関わることに価値があることを認識するのに役立つかもしれません。小さなプロトタイプを作成してソフトウェア設計のリスクを発見することは、設計の反復を崩壊させるのに役立つかもしれない理由を示すのに役立ちます。