スクラムマスターとしての開発マネージャーの欠点は何ですか？
チームマネージャーがスクラムマスターであってはならないことは一般的に認められていますが、その理由を理解するのに苦労しています。コンテキストについては、私はスクラムチームに4人の開発者がいるアプリケーション開発マネージャーです。私はスクラムマスターの出身で、組織にスクラムを導入しています。私はチームをゼロから構築し、私がするすべてはチームを促進することであり、彼らが決定を下すことであることを明確にしました。チームとして私たちは非常にオープンです-彼らはスタンドアップでしばらく私を沈黙させ、私たちが得始めていた「報告」の感覚を排除しました。オープン性の欠如は、一般的にスクラムマスターとしてのマネージャーに対する最大の議論ですが、適切に処理され、適切な文化で簡単に克服できます。
経験豊富なスクラムコーチから、これは危険な状況であり、「事態が悪化した場合」にリスクがあると警告されました。私の見方では、2つのポジションは競合していません。どちらの役割でも、チームと個人に同じ目的を持っています。スクラムは、チーム内の対立を解決します。これは、従来はマネージャーの役割でした。スプリントの自己管理機能により、マネージャーが従来行っていた作業の割り当てがなくなります。
開発マネージャーが個人のニーズが満たされていること、キャリアの目標、職場などを確認しているので、私が本当に気になっていることはすべてあります。毎週、各チームメンバーに追いつき、問題を提起し、管理タスクを処理します。これの多くはチームに直接関係しているか、とにかくスクラムマスターとしての私の役割に関係しています。
大規模な組織では、これがどのように管理できず、個別の役割になるかを理解していますが、小規模な組織では、別のスクラムマスターや開発マネージャーを正当化できません。
スクラムマスターとしての開発マネージャーの落とし穴について教えてください。上で挙げたポイントや既に克服したポイントは除きます。
基本的に、利益相反があります。マネージャーの仕事は、期限を守ることです。スクラムマスターの仕事は、見積もりができるだけ正確であることを確認し、持続可能なペースで作業することです。マネージャーはスプリントに引き込まれる作業を増やしたいと思う傾向があり、スクラムマスターは外部の期限に関係なく、現実的に終了できる量を必要とする傾向があります。優れたマネージャーはその対立のバランスをとることができますが、仕事が2人に分かれている場合ははるかに簡単です。通常、マネージャーは製品所有者の役割に適しています。
チームの誰もがスクラムマスターになじみがない場合でも問題はありませんが、数か月後にその役割を引き継ぐと、チームにメリットがもたらされます。その役割を仲間と見なすことが重要です。非管理スクラムマスターでさえ、チームがマネージャーのように扱いすぎるため、しばらくするとローテーションしなければならないことがよくあります。
「テクニカルマネージャー」がプロジェクトの日々の仕組みに深く関与しすぎるとどうなるかを実際に見てきましたが、それは見事ではありません。私たちの場合、問題のマネージャーはスクラムマスターではなかったではありませんでしたが、これらの決定の一部を選択しようとしていました。私たちが実際にディフェンスをプレイするための個別のスクラムマスターを持っていなかった場合は、はるかに苦痛だったでしょう。
（ちなみに、これはmyマネージャーではなかったので、この点についてはかなり客観的に感じています。）
主な利益相反として私が見たものについて説明します。これらのいずれかが自分の状況に当てはまると思わない場合は、おそらく両方を行うことができます。ただし、必ずこれらの仮定を定期的に再確認してくださいこれらのトラップに陥らないようにしてください。
テクニカルマネージャーは通常、複数のチーム内の特定の役割を担当します。チームが1つだけの場合は、「マネージャー」ではなく「リード」です。この責任の分散は、チームでの時間とプロジェクト/製品での時間の短縮を意味し、「ヒットアンドラン」スタイルの管理につながる傾向があります。
技術マネージャーは、ビジネスに対して他の多くの管理職を持っています。コーチング/トレーニング、パフォーマンスレビュー、面接/採用、インフラストラクチャ/リソースの長期計画などを行う必要があります。これはそれ自体で簡単にフルタイムの仕事になる可能性があり、円滑化に費やす余地がほとんどありません。
忙しいスケジュールもチームに負担をかける可能性があります。テクニカルマネージャーは、チームが都合の悪い時間と見なしたときに、チームメンバーを会議に参加させる必要がある（または希望する）場合があります。中断を管理して排除することは通常、スクラムマスターの仕事ですが、自分のスケジュールを心配する場合、それについて客観的になることは不可能です。スクラムマスターがチームメンバーと個別に面会する必要はほとんどありません。これは、それらのすべてのミーティングが事前にスケジュールされているためです（スタンドアップ、回顧展など）。
テクニカルマネージャーは、横断的なプロジェクトの懸念に対処する必要があり、その自然な衝動は、ライブラリ、ソース管理、アルゴリズム、レイアウト、色など、すべてを標準化しようとすることです。これは実際には会社にとって良いことかもしれませんが、最終的にはチームがやりたいことを打つために誰も残さず、彼らは別のことをやりたいという非常に正当な理由があるかもしれません。これは、スクラムや同様の方法論の根底にある「継続的改善」の理想に反します。
自分が管理する役割の専門家のバックグラウンドから来たマネージャーは、作業をどのように行うか、およびどのくらいの時間をかけるかについて、かなり強力なアイデアを持っています。これはマネージャーとして悪いことではありませんが、スクラムマスターとしては、チームメンバーを設計に偏らせたり、他の方法では同意しないだろうと推定したりします。おそらく、目の前の問題についてあなたより多くを知っています。
チームメンバーは、要求と注文の区別に常に問題を抱えています。 彼らはあなたにこれを伝えませんそして、それを彼ら自身に気付かないかもしれません。あなたが単に尋ねているだけで、言っていないことを明確にしても、彼らの心の中で、あなたはまだ彼らのマネージャーであり、「ノー」と言うことにはキャリアレベルのリスクがあります。 それについてあなたができることは何もないので-それは彼らの態度であり、yours重要です。
あなたがあなたがこれらのトラップのいずれにも落ちることは決してないだろうと確信しているなら、それからそれのために行きます...しかし私は繰り返します、あなたに確認してください-頻繁に検証チーム（および他のチーム/マネージャー！）に話しかけることによってあなたの想定を確認し、気づかないかもしれない微妙なまたは無意識の方法でそれらが起こっていないことを確認してください。
肯定的なメモとして、問題を実際に質問するのに十分重要であるとあなたが考えるという事実は、あなたがおそらく両方の役割でかなり優れていることを意味することを付け加えます。私の本では、自分のキャリアの野心だけでなく、チームを気遣うことが、優れた管理の半分以上を占めていると思います。
...しかし、両方が得意であるということは、常に両方が得意であることを常に意味するわけではありません。気をつけて。
主な問題は、マネージャーにはチームに何をすべきかを伝える権限があるということです。スクラムマスターは、スクラムの原則を実施する以外にこの権限を持ちません。
これは何を意味するのでしょうか？マネージャーの入力は、暗黙的により多くの重みを持ちます。あなたがそれを意味することも、そうしたいこともないかもしれませんが、結局のところ、チームメンバーのキャリアと給料は何らかの形であなたにかかっています。そして彼らはそれを知っています。そして、これは関係を汚します。
まだできますか？もちろん。あなたはサーバントリーダーであり、トップダウンが飛ばないことを補強するために非常に一生懸命働く必要があるだけです。
これは宗教ではなく、スクラムのルールは独断的ではありません。 HRマネージャーとSrumマスターの役割を組み合わせたケースがこれまでにあったとしても、良い役割を果たしています。あなたが言及したこれらの落とし穴に注意してください。しかし、すべての状況に完全に適合する単一のルールセットが存在することは決してありません。
チームが両方の役割の実行に慣れている場合は、本のルールに合わせるためだけに物事を振り回す必要はありません。
私が目にする最大の問題は、マネージャーがあなたに関連した問題を抱えている状況です。彼らがジュニアであるか、自信がない場合、彼らは回顧展中に発言することを恐れるかもしれません。これは回顧の有効性を制限する可能性があります。多くの人は、マネージャーがいるときに「マネージャーが非現実的だと感じています」と恐れています。
だから、多分あなたはこの問題を解決するために遡及することを許しません。これで、チームはスクラムマスターなしで遡及を行っているため、回顧の効果が制限される可能性もあります。
どちらの場合も、チームに悪影響を及ぼします。
私が目にする主な問題は、チームの組織に関する矛盾するメッセージをチームに送信していることです。
以下は、2つの可能なチーム組織です。どちらも成功する可能性があります。彼らは違う。 （それらは唯一の可能なオプションではありません。）
- チームには正式に指名されたリーダーがいます。チームリーダーは、チームの全体的なパフォーマンスに対して最終的に責任を負います。チームリーダーはすべての決定を行うことはできませんが、チームリーダーはすべての決定について最終的な決定権を持っています。
- チームは自己組織化されており、正式に指名されたリーダーはいない。チームの全員が自分自身とチームの全体的なパフォーマンスに責任があります。スクラムマスターはスクラムプロセスを促進しますが、チームのために一方的な決定を行う権限はありません。
実際のチーム構造は＃1のようですが、用語とスクラムのいくつかのプロセスを使用すると、構造が＃2であることがわかります。私の意見では、＃1はスクラムではありません。
以下は、競合を解決するための2つの提案です。
- 現状を維持しながら、チームリーダーであり、スクラムを100％フォローしていないことを明確にします。マネージャーとスクラムマスターの職務を分離することの価値はあるものの、会社にとっては現実的ではないことを説明すると役立つでしょう。
- スクラムマスターの責任をできる限り他の人に譲ります。障害を取り除くことや、組織の他の部分からの注意散漫をそらすことなど、いくつかの責任を保持する必要がある場合でも、スクラムマスターの作業の多くをピアが実行するのに役立ちます。
スクラムマスターとしての開発マネージャーの欠点は何ですか？
開発マネージャーは次の目的で採用されます。
- 解決開発の問題。
- 技術的負債を監視し、削減します。
- 技術スタッフを増やします。
彼らの背景と専門知識により、彼らは技術的な問題に集中する傾向があります。
一方、プロジェクトマネージャー/スクラムマスターは採用されます。
- プロジェクトの成功を確実にします。
- 作業とトリアージのバグ/質問を適切な開発リソースに割り当てます。
- 開発チームと協力して、プロジェクトの完了を遅らせる可能性があるすべての障害を取り除きます。
- プロジェクトのステータスを上層部に伝える。
- プロジェクトまたは会社が特定のサイズに成長した場合、開発マネージャーに両方の任務を実行するよう依頼することは非効率的で賢明ではありません。
開発マネージャは、コードやアーキテクチャに「深く掘り下げる」傾向があるべきですが、プロジェクトマネージャ/スクラムマスターは、常に「50,000フィート」の物事に関心を持つべきです。
ほとんどの開発マネージャーは何年もコードの開発に費やしてきました。開発の問題は彼らにとって非常によく知られています。
- したがって、技術的な問題を解決するときに最も役立ちます。
- プロジェクトマネージャー/スクラムマスターの役割には、非常に組織化された、非常に詳細な志向の人が必要ですが、超技術的ではありません。
- これらの人々が得意な分野に特化できるようにする余裕があれば、ビジネスは最も効率的です。
- また、スクラム関連の責任を開発マネージャーのプレートからオフロードできる場合、彼/彼女は技術的な問題により多くの時間を費やして、技術的な負債を減らすことができます。
私は経験豊富なスクラムコーチに耳を傾けるでしょう。 99％の時間で問題なくエクササイズできる可能性があります。しかし、その恐ろしい1％がやって来て役割が対立すると、個人とあなたとの関係だけでなく、チーム全体の健康を台無しにする可能性があります。そして、1度失敗すると、スクラムマスターとマネージャーの両方としてのあなたの役割が損なわれます。
もし私があなたなら、スクラムマスターになる可能性のあるチームの個人を特定し、彼/彼女と一緒に行きます。私は常に、スクラムマスターを、チームが信頼し、プロセス、ビジネス、恐ろしい技術的なことも理解している人物と見なしていました。有能な人物を選んだ場合、スクラムマスターの役割はフルタイムの仕事ではありません（それに近いことすらありません）。