他の人はすでに良い答えを提供してくれたと思いますが、私が追加するのは、あなたのチームがスクラムに移行したばかりで、私たちが始めたときと非常によく似た立場にいるためです。
まず、アジャイル、より具体的にはスクラムの紹介はあまりスムーズではありませんでした。基本的に管理職が降りてきて言った、今日からあなたはスクラムを行うべきであり、これはあなたがすべて従うプロセスです。People over Processにとってはこれで終わりです。
私たちが最初に行ったプロセス（盲目的に、私が付け加えるかもしれません）は、あなたが説明した方法と非常によく似ています。人々はタスクを割り当てられ、全員が予約され、私たちは全員私たちのデスクに戻ってプラグインします。それから私達は退屈なスタンドアップミーティングを毎日持っています。
理解するための鍵は、アジャイルとスクラムが含まれているのは、実際には人に関するものであることです。チームがイテレーション計画に入るとき、あなたのスクラムマスター（おそらくマネージャーである）に時間、ストーリー、タスクを割り当てさせないでください。それは完全にチーム次第です。多くの人にとって、これは非常に難しい概念だと思います。何年も前に彼らは仕事に来て、彼らには単に仕事を割り当てる上司（マネージャー、テクニカルリード...）がいたからです。彼らはスクラムに飛び込みますが、誰もが（スクラムマスター自身を含む）同じモードで操作を続けます。
ある日、あなたはこれにうんざりするでしょう。それで、あなたは本やブログを読み始め、スタック交換でこのような質問をし続けるでしょう。あなたが得ることの実現は、開発者とあなたのチームメイトとしてのあなたがストーリーへのコミットとタスクの割り当ての背後にある原動力であるべきであるということです。ペアプログラミングのメリットがあると感じたら、必ずエンジニアごとに2つのタスクを作成し、両方に時間を割り当ててください。スクラムマスターがすべきことは、前回のイテレーションでAS A TEAMとして提供した完成したストーリーに対して速度を測定することだけです。
私のがらくたを悩ませているもう1つのことは、容量が常に合計時間の75％であると人々に言われていることです。そのため、彼らはそれをコミットし、反復の全期間中、彼らは不満を述べています。a）できないあなたを助けるかb）彼らはあまりにも多くの時間が割り当てられているため、彼らは正しいことをすることができません。コミットに何時間かかるかは知らされるべきではなく、スクラムマスターがこのようなものを引っ張ろうとしているのなら、彼らは確かに押し戻すべきです！誰もが自分が何に満足しているのかを正確に約束すべきです。たとえば、私はチームリーダーであり、計画外のランダムな設計に関するディスカッションをしたり、誰かをコードで支援したり、奇妙なことをトラブルシューティングしたりすることがよくあるため、私の能力は50％を超えることはありません。
私たちのチームは、今述べたようなことをしないことを学ぶのに4つのリリースサイクルを要しました。たとえ私たちが確実に改善したとしても、専門家に尋ねれば、私たちは半分も機敏ではありません。だからまだやることをたくさん学ぶ。
更新1：クリフのコメントへの応答
さてあなたはあなたの耳を提供したので、ここにそれは...
そうです、文化の転換が重要ですが、この転換は幹部レベルで起こる必要はありません。あなた自身のグループマネージャーはあなたのチーム内の文化を変え、彼が対処しなければならない企業のBSからあなたを分離することができます。あなたが説明しているのは、2007年から2010年までの正確な私たちです。私たちのチーム（および他のチームも）はリリースごとにリリースをフロップしました。経営陣の「アジャイルになるためのプロセス」を使用したリリースの1つでは、通常は1人で行う作業を9人の人々にプロデュースし、2倍の時間を費やしました。余暇が多すぎて、履歴書も更新しました。
次に、上司と話し合って、これらすべてのことを人に対してアジャイルであるということを説明しました。製品について気にかけてもらいたい場合は、製品の取り組みと提供方法に影響を与える決定を下しましょう。彼はそれを実験的にすることに決めたと思います、彼は私たちのすべての変更を加えました...まあ、ほとんど私自身ですが、私はチームの他のメンバーと頻繁に話し合うので、容量は50％です:) ...提案しました。彼が私たちが求めているすべての変更を加えても失敗する場合、彼は勝利した「私はあなたにそう言った」と戻ってくるだろうと考えた可能性があります。
したがって、過去12か月で、私たちはあまりにも多くの「愚かな」ことを排除しました。私たちはスタンドアップミーティングを実際に意味のあるものにしています。これは、孤立してではなく、一緒に作業するためです。製品の特定の部分の所有権は（少なくとも現時点では）まだありますが、お互いのコードに頻繁にアクセスすることもあります。チームのメンバーが他のコードを学ぶだけでなく、より優れたコーディングおよび設計技術も学ぶように、私たちは常にコードレビューを行っています。モノリシックで巨大な「アジャイル」チームを3つの異なるチームに分割したため、計画やその他のミーティングははるかに短くなり、人々は周りに座って気にしないことについて耳を傾けることがないため、実際に気になります。私' 5人のうち4人（チームの1つ）が夜11時にオンラインになる夜を見たことがあります。実際に一生懸命に仕事をしなければならない、または40時間以上仕事をするように圧力をかけられたという人は実際には誰もいません。半年前まで気にならなかった人々は、突然、彼らがしている仕事に従事し、興奮しています。そして、私たちのマネージャーがすることは、「あなたたちは何が正しいかを決定し、あなたがする必要があることをします、そして私はできる限りチームから企業のBSを守ります」と言うだけでした。
それは実験として始まった（私の疑い、彼は私に言わなかった）が、今、私たちのグループは、部門の他の開発グループと比較して激突しており、私たちに来て参加しようとしている他の開発者もいます。
この変化が起こって以来、私たちにとって最大のハードルは（そして今日でもまだ問題です）、通常の企業環境のエンジニアは、ケージ内の実験用マウスのようなものでした。あなたのマネージャーが本当に「機敏」に行くことを決定し、ケージを削除したとしても、誰もが長い間そのケージの中にいて、彼らが彼らが自由であることにさえ気づいていません。したがって、すべての自由があっても、彼らはまだ制約されているかのように行動し続けます。グループの境界の外に出て、より良い方法を模索しているチーム（自分など）を少なくとも数人持つことが役立つと思います。次に、そのグループに戻って少しかき混ぜます。
あなたの場合、チームに降りてきて作業方法を伝えるために別の外力を探しているのであれば、おそらくペアプログラミングは解決策ではありません。代わりに、ルールを破棄し、管理なしで彼らと一緒に座って、彼らに何をしたいのか尋ねますか？彼らを幸せにするものは何ですか？生産的？最大の問題を特定し、解決策がどうあるべきかをチームに尋ねます。