開発者が「デイリースクラム」を好まない理由とその理由は何ですか？[閉まっている]

毎日のスクラムを保持することには、次のような利点があります。

1. チームは互いに調整されます
2. 誰がどの程度のタスクを実行したかを知っています
3. バーンダウンチャートはますます完全になります
4. タスクボードが更新されました
5. それほど長くは続かない、15分は誰も殺さない

しかし、最近（6か月間のスクラムの実装と使用後）、開発者は毎日のスクラムがあまり好きではなくなったように感じます。人々は十分な説明をせずにタスクボードを更新するだけで、退屈しているようです。何らかの理由で、私たちはそれを保持しないとき、彼らは一種の特別な幸せになることがわかります。

私はこれで何が間違っているのか分からない。チームにとって「デイリースクラム」が持つ不利な点について、どこかで言及された理由はありますか？開発者が毎日のスクラムに飽きた理由は何でしょうか？

私はいくつかの雇用者と「SCRUM」チームに参加した経験がありました。マネージャーは、「毎日のスクラム会議」をSCRUMの主要なポイントとして取り上げ、それを目的として設定するのではなく、目標として設定しているように見えます。これは、より効果的な開発サイクルを達成するための手段です。

すぐに15分間の会議が45分間の会議になりました。人々は他人の話を聞くのではなく、あくびをして「いつ行くことができるのか」と忙しくなり、人々のルーチンを壊すため、更新は効果がありませんでした（たとえば、私はフクロウの人であり、この愚かな会議のために毎日午前9時に働くことは、私が仕事を辞める十分な理由です）。

管理者が正しく適用されれば良いかもしれないアイデアを取り、極端にそれを取ります-彼らは期待した結果の正反対を取得します。私は個人的に、参加する会議が多いほど、仕事が減ると思います。カレンダーで週に2回定期的に会議を開いていますが、通常はそのうちの1つをスキップします。ミーティングはマネージャー向けであり、開発者に仕事を任せます。

「しかし、それはとても素晴らしい」と言うスクラム愛好家がたくさんいると確信しています-それを保存してください、私はそれをすべて聞いたことがあります。

価値がほとんどまたはまったくないと感じたら、退屈で役に立たないことに気づくでしょう。毎日の立ち上がりの実用性を低下させる可能性のあるものがいくつかあります。

• 共有される情報は、決して私に関係したり、私に影響を与えることはありません。
• チームのオーナーシップがなく、全員が常に自分のプロジェクトに取り組んでいます。
• スタンドアップ外のチームコミュニケーションの欠如。
• 目に見えるまたは伝達された進行の欠如。
• 共有する情報がない。

これらは私の頭上にありますが、常により多くの考えられる理由があります。

おそらく、開発者になぜ興味がないように見えるのかを直接尋ねるべきでしょうか？より多くの/より良いコミュニケーションが必要な場合は、あなたから始めてください。

毎日のSCRUM会議で発生した問題の一部：

• 長すぎるもの。彼らはこの種の問題の根本的な原因であるので、あなたはそれらの毎日のマネージャーの人を望んでいません。彼らが通常どのように椅子を使用するかを確認します（はい、それらのために立ち上がることは、人々が速くなるように誘惑することです）
• 後で別の実際の会議をスケジュールして関係者と話し合うことを決定する代わりに、彼が抱えている孤立した問題を詳細に説明する人（または2人または3人の開発者）の話を聞く必要がある
• 愚かな時間。これらの会議は午前中に行う必要はありません。昨日やったことについて話しているのではなく、今日何をするかを決めているわけではありません。前回と今回の間に何をしたかについて話し、次の日まで何をするかを決めます。
• 開発者向けのアプリの所有権の欠如。SCRUMは、開発者がコードモンキーとして扱われない場合に機能します。プロセスがうまくいかない最初の兆候は、開発者が何かをするのにどれくらいの時間を要するかを評価する人ではないときです。
• 再び愚かな時間。チームの一部が何らかの作業を開始し、日々の出来事で「ゾーン内」にいる場合、面倒になります。それらを毎日持つ良いタイミングは、誰も仕事をしてはいけないときです（例えば、昼食後、または昼食時に議論を始める直前）。

タイミングは多くの人にとって致命的です。プログラマーは、コーディングを遅らせ、眠りを遅らせ、朝のラッシュの後に入ってきます。決まった時間にオフィスにいなければならない-彼らにとっては早すぎる。また、早めに来てすでに仕事を始めている人にとっては遅すぎます。

フローは別の問題です。何らかの機能を備えたフローのプログラマーは、夜遅くまで働いて、家に帰って充電して戻って続行する準備ができています。ほとんど関係のない問題を抱えた会議に出席しなければならないことは、彼の注意をそらす可能性があります。

私の意見では、これらの会議はマネージャーやチームやプロジェクトに役立つのではなく、実際に何かをしているように見えるためにあまりにも頻繁に行われます。

たとえば、さまざまなプロジェクトで一連の短いバグ修正を行うチームが割り当てられます。彼らは実際にはチームとしてではなく、個人として働いています。ただし、会社/部門のポリシーで義務付けられているため、チームリーダー/マネージャーはいずれにせよ毎日のスクラム会議を開催しています。達成されるのは、役に立たない会議のために15分以上を費やし、会議の前後に15から30分の気晴らしと生産性の欠如に取り組むことです。

今では、締め切りが厳しく、さまざまな部分で作業する人々の間で多くの調整が必要なプロジェクトで、スクラムがうまくいくのを見てきました。その文脈では、それは素晴らしいシステムでした。しかし、「私たちはスクラム/アジャイルショップであるため、会議を開いていますが、それが私たちが行うことを想定していることです」という文脈では、本当に残念です。

誰も会議を独占しないようにしてください。

開発者の4、5分、および次の10分で邪魔に彼らの熱弁を取得した場合、すべての詳細をチームリーダーに聞いて費やされている素晴らしい、素晴らしい素晴らしいも素晴らしいほどでもないんほとんどは彼が作られている新たな展開を、彼がそう思うと、人々は非常にすぐに退屈するでしょう。

少し待って、チームについて考えてください。

• 彼らは効果的に働いていますか？
• タスクは時間通りに完了していますか？
• コードは堅牢で適切に作成されていますか？
• チームは、亀裂から何も落ちないことを保証していますか？
• チームは、作業を重複させたり、お互いのつま先を踏みつけたりしないように調整しますか？

これらのすべてに対する答えが「はい」の場合は、おそらく、毎日の会議、バーンダウンチャート、タスクボードなどの忙しい仕事をチームに強制する理由を検討する必要があります。どのような価値が追加されますか？自分の楽しみのためだけに官僚的なデータを生成したいのですか、それともチームの生産性を上げようとしているのですか？

毎日のスクラムが停止してから生産性が低下しましたか？何も変わっていなければ、なぜ会議を続けるのですか？

15分。その15分（および準備の時間）は、チームメンバー間で十分な新しい有用な情報を伝えて、翌日のチームの生産性を15分以上改善しますか？毎日その量の有用なスクラムコンテンツがない場合、チームメンバーはおそらく、この会議をできるだけ早く終えて仕事に戻った場合、目標に向けてはるかに進歩すると考えています。

ボードとチャートを頻繁に更新する場合は、ドラフトコピーをwikiに入れてください。

レトロスペクティブ会議を開催して、「うまくいったこと」と「うまくいかなかったこと」を確認し、開発者が毎日のスタンドアップミーティング自体を時間の無駄として挙げているかどうかを確認することをお勧めします。その後、少し再編成する必要があります。

私の個人的な経験：

• 目的は、今日何をしているか、昨日どこにいたかを知ることです。議題に固執する代わりに、2人の間のブロッカーの技術的な議論に入り、他の15人は退屈します。問題を特定するが、外部と話し合う
• 人々は時間通りに会議室に入ることができず、これは意図的に誰かによって行われるサイクルになります。そのため、スクラムマスターは、会議の外で静かに話し合い、時間どおりに開始および終了するようにする必要があります。
• スクラム会議以外でバーンダウンチャートを既に更新しているため、毎日のスタンドアップの主な目的ではありません。

抵抗は次の場合に発生します。1）午前9時に人々を急いで押し込むために使用されます。電車が遅れると余分なストレスになります。2）スクラムのリーダーシップが不十分。リーダーは、人々に影響を及ぼさない何かを聞いてもらうのではなく、物事をオフラインにするように人々に伝えるべきです。3）価値のないコンテンツ。これもまた、スクラムリーダーシップの問題です。ボトルネック、軌跡の問題、潜在的なコラボレーションに対処するためのフォーラムとなる予定です。実際に起こることは、誰もがその日に仕事をすることを期待しているだけであり、他の誰にも役に立たないか興味がないことです。4）立ちます。私は立って立つことはありません。地位の背後にある論理は、それが人々が簡潔であることを奨励することでした。人々は実際には関係なくガタガタと鳴ります。

私は何度もスクラムチームを管理し、その一部になっています。開発者がスクラムを好まない主な理由は次のとおりです。

• 非常に貧弱なスクラムマスターによって実行されるため、45分になった場合は、スクラムの制御を改善する必要があります。
• 彼らがそれを好まない最大かつ最も正直な理由は、悪い仕事倫理に隠れることが非常に難しいためです。つまり、より露骨に、怠zyな人々が現れます。私が一緒に働いた開発者の中には衝撃的で、30分間の仕事をするのに数日かかるタスクがあります。優れたPMは開発者の障壁を取り除く必要があります。つまり、開発者はスプリントでタスクを処理できる必要があります。開発者は、毎日立ち上がって、自分の進歩を実証しなければならないので、それが好きではありません。何らかの理由で進歩を実証できない場合、不安を引き起こします。有効な問題が原因である場合、優れたスクラムマスターがその問題をできるだけ早く解決する必要があります。

問題は、スクラムマスターにブロッキングの問題を解決する権限、スキル、または能力がない場合に発生します。実際、私はそれらが消えることを望んで、いくつかの問題を埋めているのを見てきました。これは悲惨です。

率直に言って、私が行った毎日のスクラム会議の99％で、ほとんどすべてのディスカッション/質問/回答は、数通のメールで修正できたはずです。

私は、会議を開かないためにはもっと正当な理由を示す必要があると正直に思います。すべての人を対面で部屋に入れるとき、それが正当な理由であり、時間効率を最大化するために整理された環境を構築します。

私は一般的に会議が嫌いで、ビデオ会議、電話、電子メール、仕事に出入りすることなく生産性フローを中断することなく仕事に参加できる、または滞在できるものなら何でも使用することを好みます。

個人的には、8時間の間に4回以上の会議がある場合、プロジェクトはうまく管理されていないと思います。

会議中の緊張に寄与する多くの要因があります。これらは会議が価値がある以上に費用がかかるかもしれない重要な理由のいくつかと考えてください：

• フォーカス-ソフトウェアと会議
• 管理-マネージャーは測定が必要
• 性格-内向的と外向的
• 時間-割り込み、メーカーおよびマネージャーの時間
• 目標、優先順位

これらの各要因について以下で説明します。

焦点 -私はソフトウェアの開発を楽しんでいます。それには、課題（問題）について考えること、ソリューションを作成すること、ソフトウェアを構築すること、会議がソフトウェアを構築するタスクに集中することを妨げます。開発者が課題（問題）に没頭し、ソリューションのメンタルモデルを構築し、ソリューションの構築に完全に焦点を当てている「フロー」と呼ばれる状態があります。開発者は、真夜中まで働いて、食べて寝るだけにして、その後、離れたところに近い状態に戻ることがあります。

開発者は気を散らすことを避ける必要があり、多くの人が夜遅くまでコーディングすることには利点があることに気付きます（騒音、電話、忙しいオフィス、開発者以外の同僚が作業を中断することを避けます）。そして、午後10時、11時、または12時まで働いたら、後で仕事に来るのは理不尽ではありません（10、11、正午？）。開発者が午前9時から真夜中まで働くことを期待するのは妥当ですか？

スクラム（およびその他の）ミーティングは、ソフトウェアを構築するという主な目的から開発者をそらします。

管理 -マネージャーは成功するために測定する必要があるため、進捗状況を測定および報告し、依存関係、遅延、およびリスク領域を公開するためのスケジュール、成果物、タイムライン、優先順位、および会議の必要性。スクラムの課題は、マネージャーがこれらのことを必要としているが、開発者は集中する必要があるということです。ミーティングはマネージャーに役立ち、マネージャーがステータスと進捗を取得、測定、追跡する方法を提供しますが、ミーティングは開発者に有用性を提供することはほとんどありません。気晴らしを処理し、障壁を取り除き、開発者がソフトウェアの構築に集中できるようにすると、マネージャーはより多くの価値を提供することを考慮してください。

会議の必要性に対する解決策があります。マネージャーは、開発者を訪問し、ステータスレポートを要求し、中断がより邪魔にならない場合にプロトコルを採用するか、開発者が中断可能な場合に進捗を通知するポリシーを採用できます。これが重要である理由については、時間の説明を参照してください。

人格 -一部の人は内向的であり、他の人は外向的であることを考慮してください。外向性の人は社会的相互作用を楽しみ、彼らによって充電されます。内向者はマネージャーとして成功する可能性がありますが、マネージャーは通常、外向的な人です（外向的な人は通常、社会的相互作用の方が優れているため）。内向的な人は社会的相互作用を楽しむことができ、さらには優れていますが、孤独によって元気になります。開発者はしばしば内向的であり、ソーシャルインタラクションを「必要としない」ため、単独で（または小さなチームで）成功しています。彼らは問題に単独で取り組むことができます（ただし、外向的な人も開発者になる可能性があります）。毎日のスクラムミーティングは社交的な集まりになり、外向的な人には適していますが、内向的な人にはあまり適していません。

時間 -開発者は会議中にコードを書くことはできません。また、ブレーンストーミングをしている場合を除き、会議に気を取られている間、彼らは難しい問題について考えることもできません。開発者は、ソフトウェアの構築に集中するために、途切れない時間の大きなブロックが必要です。会議は、彼らの努力をそらす中断です。あなたが何時間も問題を解決することに没頭し、ほぼ完了し、誰かが「スクラムの時間」と言うと、あなたは中断され、「ギアをシフトする」間、おそらく何時間もの仕事を失います。または、午後11:00まで仕事にとどまり、仕事を辞め、家に帰り、問題で眠り、目を覚まし、問題を解決する準備ができて仕事に戻った後、問題に取り組んでから1時間後に中断される「スクラムの時間」です。

Paul Grahamには、Maker Time vs. Manager Timeに関する優れた記事があり、この問題を私よりもはるかによく説明しています。計画されているかどうかにかかわらず、会議の中断はフローを中断させ、開発者をMaker時間からManager時間に強制することができると言えば十分です。私を信じて、あなたはメーカーの時間に開発者が欲しい。

目標、優先順位 -開発者と管理者には、異なる目標と優先順位があります。マネージャーは、スケジュールを追跡し、コストを最小限に抑え、レポートの責任と実行を保証する責任があります。開発者には、課題/問題に対処するソフトウェアを構築するという目標があります。これらの目標は矛盾していませんが、緊張を生み出すのはコミュニケーションメカニズムです。ミーティングはマネージャーのニーズに応え、マネージャーの時間を最適化しますが、開発者のニーズと対立します。スクラム会議は、会議の最初のルールを破棄し、「アジェンダを持っている」ため、もっとさまよう傾向があります。また、ミーティングはコミュニケーションを最適化するために使用されますが（マネージャーにとって）、開発者の時間（中断、フローの損失など）がかかります。

目標は何ですか？制約は（品質、時間、コスト、プロセス）でありながら、ニーズに迅速かつ高品質で対応するソフトウェアを構築すること。スクラムおよびその他のアジャイル方法論は、プロセスの制約を認識し、その要因を最小化しようとし、その制約を最小化するため成功しています。ただし、会議の追加には時間がかかり、中断は開発者に会議の継続時間よりもはるかに費用がかかります。

ミーティングを修正して、メリットがもたらされるようにします。

1. 都合の良い時間にスケジュールしてください。仕事を始めてから30分で、誰もがメールを確認し、会議についての考えを整理することができないのはなぜですか。簡潔さには計画が必要です。準備ができていない人は永遠に歩き回ることができます。
2. 会議中に問題が通知された場合に回避できた問題を特定します。誰もがポイントが何であるかを理解する必要があります。
3. すべての人の入力を最小限に抑えるために必要なことは何でもします。議論の場ではありません。議論を必要とするトピックに焦点を当てた毎日の会議以外で、個人的に会議をスケジュールするように人々を促します。ルール：一度に話すのは1人だけです。

すべての不平を言う人は、彼らが問題に寄与していないことを確認する必要があります。毎日のスクラムの目的をそれほど苦痛なくして達成できるなら、私たちはそれを聞きたいです。