アジャイルは新しいマイクロマネージメントですか？
この質問はしばらく頭の中で料理してきたので、開発環境でアジャイル/スクラムのプラクティスに従っている人に質問したいと思います。
私の会社はようやくアジャイルプラクティスの組み込みに乗り出し、アジャイルグループの4人の開発者のチームから試験的に始めました。それは3反復の4か月であり、彼らは私たちの残りのために完全にアジャイルになることなくそれを続けています。これは、上からのかなりのアドホックタイプの要求でビジネス要件を満たすという経営陣の信頼があるためです。
最近、私はこのイニシアチブの一部である開発者と話しました。面白くないと言われます。彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されていませんし、ワークエリアで電話をかけることも許可されていません（これはおそらくある程度は問題ありません）。たとえば、アジャイルチームに所属しているキックについて友達と話したい場合、スクラムマスターの承認なしでは許可されません。アジャイルチームのすぐ隣に座っている人。
このすべてまたはアジャイルのアイデアは、アジャイル開発者に中断から完全な真空を提供し、6時間以上の生産的な時間を確保することです。ええと、私はアジャイルの第一人者ではありませんが、Yahooのアジャイルロールアウトドキュメントなど、他の組織で読んだことから、アジャイルは安くはないという気がします。チームにアジャイルを導入し、到着時に問題を修正して軌道に戻すには、リソースと予算が必要です。
まず、開発者向けのトレーニングやマネージャーなどのコーチングが必要です。現在のスクラムマスターは、マネージャーが支払ったアジャイルトレーニングクラスを数日かけて担当したマネージャーで、現在このアジャイルチームをリードしています。また、アジャイルマニフェストはアジャイルが石に設定されておらず、企業ごとに異なる方法でカスタマイズされているとは規定していないと会議で聞いたことがあります。まあ、それはすべて良いと理由に聞こえます。
結論として、アジャイルは開発チームに調和をもたらし、開発者を満足させるはずだといつも思っていました。しかし、アジャイルチームの開発者と話すとき、私は非常に反対の感覚を感じています。彼らは仕事以外何も話せず、一日中静かに座って仕事をしているだけでは不満であり、経営陣が仕事をもっと効率的にするためのもう1つの方法だと感じています。
これがより多くのドルのための利己的な利点の目的で使用される良い習慣の例の1つであるかどうか教えてください。あるいは、私たちのような開発者だけであり、このアジャイルチームは、仕事をしているだけで仕事をしているような環境で仕事をしたくないと感じています。
これは、米国全体にオフィスを持つヘルスケアドメインの会社です。それは間違いなくカウボーイスタイルのアジャイルのように感じます。そのため、現在の会社では特に、アジャイルにまったく行きたくありません。
それはすべて、管理が完全に安価であることと関係があります。高価なコーヒーをより安いバージョンに切り取り、節約に重点を置き、可能な限り無駄を省いて生産性を高める。
私の考えでは、ドアの後ろにいる管理職の誰かがこのアイデアを捨てました。アジャイルはより多くのプロデュースを提供するので、同じ人数でより多くのプロデュースしている上司を示すことができます。または、多分、それが事実であれば、人員を減らすことができます。
彼らは毎日5分のミーティングを行っています。ただし、チーム外の人とのチャットや会話は許可されていません。すべての焦点は仕事です。
あなたはアジャイルではなく、経営独裁を説明しています。アジャイルは、変化する要件の分野における段階的な開発についてであり、個々の作業をどのように行うかを人々に指示することではありません。
彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されておらず、ワークエリアで電話を取ることは許可されていません
これは実際にはアジャイルプラクティスの一部ではなく、別の問題です。
アジャイル手法の大きな動機は、開発者間のコミュニケーションの増加です。開発者<->開発者のコミュニケーションを制限することは、アジャイルの実践とは別の問題です。これが起こっていないと言っているわけではありません-明らかにそうであり、組織の「アジャイル」ロールアウトの一部としてラベル付けされていますが、これは実際にはアジャイルとは別の問題です（そしてアジャイル開発の精神に多少反しますが、 IMO）。
それはアジャイルのかなり変な実装のように聞こえます。アジャイルは、どちらかといえば、マイクロマネージメントを減らすべきであり、増やすべきではありません。チームはコミットメントを行い、プロセスの一部は、経営陣がチームがそれを達成することを信頼することです。毎日のスクラムは、開発者が互いに通信する方法であり、開発者が時間をどのように費やしたかではなく、何をしたかを通知する方法です（これはいくつかの場所で見た間違いです）。ストーリーがかかる時間（別の一般的な間違い）ではなく、相対的な複雑さを推定する必要があるので、推定プロセスでさえ、推定から明示的な時間管理を削除する必要があります。開発者が費やした時間を制御することは、マイクロマネージメントの特徴であり、プロセスから時間を取り除くことは、アジャイルの中心的な信条の1つです。
あなたが説明する環境は、庭の多様性pseudo-Agile bullshitのように聞こえます。
アジャイルになる前から、アジャイルと関わりました。 2000年頃コーディングに夢中になり、エクストリームプログラミングについて聞いて、試してみて、気に入りました。開発者として、確かなソフトウェアを作成することが最も重要であるという状況を私に与え、そして私を狂わせていた多くのでたらめを最小限に抑えるためのツールを手に入れました。私はそれが好きだった。
今日の問題 私は他の場所で詳しく説明します ですが、最近「アジャイルを採用」しているほとんどの人々は、不快になったら何も改善することに興味がありません。そのため、彼らにとって、「アジャイル」は、開発者に同じ古い方法を打ち負かすための新しいスティックにすぎません。たとえば、開発を遅らせているでたらめをすべて取り除きながら、生産性を根本的に高める方法とは対照的です。
たった今。私は会社を始めており、私は多くのXPに加えて、アジャイルの世界で学んだ他のたくさんのトリックを使用します。しかし、まさにあなたのような話のために、私は最近アジャイルの採用について聞いたときはいつでも尻込みします。
質問に直接回答するには：アジャイルは新しいマイクロマネージメントであってはなりません。それは、たわごとを成し遂げるために実際の仕事をしている人々に力を与えることについてであるべきです。しかし、あなたの場合、アジャイルは、彼らが自分の悪い本能に耽っている間、彼らがあなたに話している最新の嘘のように聞こえます。本当に申し訳ありません。
これは俊敏ではありません。
まず、スクラムはアジャイルではありません。率直に言って、スクラムはでたらめです。私はエクストリームプログラミングの家で育ちました（文字通り-ケントベックに父親のソファーに座らせて、テストについて話してもらいました）。スクラムはそうではないことをはっきりと伝えることができます。スクラムは、プロジェクト管理ツール-開発プロジェクトの定義されたリズムです。ただし、開発自体については何も言う必要はありません。要件、計画、および顧客との関係についてはほとんど触れません。 XPは、そのすべてについて多くのことを言います。他の方法論自体をアジャイルと呼びたい場合は、会話に追加する何かがある必要があります。スクラム支持者は、それをプロセスではなく、プロセスのラッパー。賢明な人はかつて、ラッパーはあなたが削除して良いものを手に入れるためのものであることを指摘しました。
さて、スクラムは怒鳴ります！
第2に、XPの創設の原則は、アジャイルプロセスの基本であると私は信じていますが、これは開発者中心であるということです。これは、開発者が行う必要があることがわかっている仕事を実行する力を与える方法であり、頻繁に実行を停止されます。アジャイルチームは民主主義または独裁制として構築されるかもしれませんが、リーダーは開発者です。プロジェクトマネージャーなどには重要な役割がありますが、チームのリーダーシップの1つではありません。マネージャーがいる-申し訳ありませんが、「スクラムマスター」-そこに座って人々をボスにすることは、チームが俊敏にやっていないことの確かな兆候です。
第三にあるべきだと思います。ありません。
スクラムはアジャイルのろくでなしの子です。これは、すべてのアジャイル手法の中で最もウォーターフォールスタイルであり、そのため、管理者の間で最も人気があります。
すべてのアジャイルな方法は、がらくたを邪魔することなく動作するコードを生成することです。もう一度お読みください。そしてまた。
「アジャイルルール」に関係なく、その目標を妨げるものはすべて悪いものです。ルールが邪魔になる場合は、f **ルールを変更してください！それがアジャイルな方法であり、それがそれを適切かつ効果的なものにしているのです。
これの 最良の例 は、Alistair Cockburn（アジャイルマニフェストの作成者の1人）によって与えられます。
「ワークステーションとホワイトボードを備えた部屋に4〜6人を配置し、ユーザーにアクセスできるようにします。 1〜2か月ごとに実行中のテスト済みソフトウェアをユーザーに提供し、それ以外の場合はそのままにしておきます。」
それがあなたが持っている人たちの質のために働くなら、それはあなたが必要とするすべてです。スクラムマスターや「アジャイル」な方法論は必要ありません。毎日のスクラムに座るのが効果的であれば、f ***がそれを行います。立ち上がることは、自分自身で考える能力の悲惨な廃止です。
response を使用して、アジャイルを実行しています。そのこれ。印刷して、誰もいないときにどこかにピン留めして、自分で見つけてもらいます。
現在のスクラムマスターは、管理者が支払った数日間のアジャイルトレーニングクラスを受講したマネージャーで、現在このアジャイルチームを率いています。
それはあなたの問題だ。経営陣はいくらかのアジャイルを望んでおり、それが何であるかを本当に知らないので、チームにそれを課します。これは、開発者の生産性を大幅に低下させたい場合にすべきことです;）
新しいプロセスの提案は開発者からのものである必要があります。または、少なくとも開発者によるレビューおよび承認経営陣のアイデアである場合。
いずれにせよ、開発者がそれを拒否した場合、実装しないでください！またはそれはあなたが説明する災害になります。
「アジャイル」およびその他すべての「管理方法論」は、人々にマイクロマネージメントを強制するために頻繁に悪用されます。 OTOH不十分な仕上がりを守るために虐待されることもあります。
「私たちはアジャイルです」は、計画の欠如、デザイン、機能、品質、リリースサイクルについての考えの欠如について私が聞く最も頻繁な言い訳です。これは通常、開発者と下層の管理者からのものです。また、ミドルマネージャー、アーキテクト、営業担当者などから聞いた、最も頻繁に使用される言い訳であり、マイクロマネージメント、締め切りと機能リストのシフト、人々への残業の大幅な強制（もちろん、締め切りと機能リストのシフトにより、もちろんそれが確実になる）などについて話します。 。
もちろん、この2つは直接的に矛盾することが多く、同じプロジェクトで発生する可能性があります。
あなたの元の質問に答えるために、アジャイルは新しいマイクロ管理です、私はノーだと思います。
まず、 this （アジャイルマニフェスト）を読んでください。共同開発者と話さないことがリストに含まれていないことに気付くでしょう。
実際、「個人と相互作用」は、共同開発者と話さないこととは正反対です。
アジャイルは新しい自己管理である必要があります。アジャイルが正しく実践されている場合、多くの決定は顧客と開発者が合理的にスコープされたユーザーストーリーで作業して行いますタスクが識別されるとバックログに追加されます。
毎日のスクラムは、管理ではなく通信に関するものです。優先順位と負荷分散についていくつかの議論がありますが、スクラムで管理される人はスクラムです主人。開発者として、私は参加し、私がしたこと、私がやろうとしていること、そして私が必要としていることを話します。次に、スクラムマスターは、私の進歩の障害を取り除くために行動を起こすはずです。
アジャイルチームは、日々の仕事が階層的に管理されているように感じてはなりません。階層的な組織の最上位の誰かが遠くから決定を下した場合、それは意思決定の分権化のための時間！一部の人々と一部の組織にとって、これはあまりにも遠い橋であるかもしれません。以下が組織に当てはまらない場合：
Live the Agile Manifesto
「私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることにより、ソフトウェアを開発するより良い方法を明らかにしています。」
「新しいボスに会って、古いボスと同じ」を避けます。できるだけチーム内からアジャイルを作成します。時々これは、アジャイルを使った試験プロジェクトに参加する意思のある連合を選ぶことによって起こります。優れたチームワークの実績を持つボランティアまたは招待されたメンバーからアジャイルチームを形成できる場合、彼らはそれを解決できます。短いプロジェクトで小さなチームを使用します。おそらく、社内またはアクセスしやすい顧客向けです。
変化に対応します。トレーニングを受けることもできますが、予算が不足していて、お金がないだけかもしれません。他の機会も同様に改善をもたらすことができます。読書をして、チームのメンバーにアジャイルについて何ができるかを学び、お互いに教える。アジャイル導入をモデル化し、リードする資格のある新規または既存のスタッフを見つけることができる場合があります。
アジャイルチームは、一般に理解されている目標に向かって取り組むサッカーチームのようなものです。私は数年アジャイルチームの一員であり、重要なのはすべての利害関係者間で効果的かつ効率的なコミュニケーションを行うことです。マネージャー/スクラムマスターはチームの単なるファシリテーターであり、従来の管理/マイクロ管理はチームの精神を殺します。
私が働いたチームでは、メンバーの仲間意識を高めるために、勤務時間後にチームゲームをプレイすることをお勧めします。私はそれらの考えを収集しました ここ 。
あなたの質問に答えるには：いいえ。アジャイルはマイクロマネージメントの一種ではありません。しかし、他のツールと同様に、人々はそれを誤って使用する可能性があります。アジャイルは、適切に実装されている場合、および人々がそれに一貫している場合は素晴らしいものです。
「開発者はスクラムマスター以外の誰にも話さない」というトピックについての私の考え：
以前はそれが当たり前だった場所で働いたことがあります。ただし、ルールは、人々にタスクを完了するように依頼することとより関連がありました。たとえば、私はランダムに開発者テスターのところに行き、数時間以内にテストを依頼することはできません。緊急の場合（または将来のスプリントのためにバックログにプッシュする必要がある場合）に、その作業がスプリントにどのように適合するかをチームメンバーと話し合うことができるように、スクラムマスターと話し合う必要があります。
その場合、私は「開発者同士が話し合わない」という概念を理解しました。これは、特定の開発者が過労したり、緊急タスクを実行するのに忙しくて、計画を達成できないほど忙しいタスクではないため、実際に1つのチェックポイントを通過するタスクに変換されました。仕事完了。
それ以外の場合、開発者はお互いに話している必要があります。常に。これにより、問題をより迅速に解決し、チームとしてより緊密になり、より早く提供できます。
単に別の視点を提供するために：私はまた、人々が開発者が「話し過ぎ」だと思った環境にいました。座った後、実際に「開発者は自分の仕事を遂行するのに十分独立していない。すべてが非常に断片化されているため、開発者は小さなタスクを完了するために他の3人に行かなければならない」に翻訳されていることがわかりました。
そのため、マネージャがアジャイルに移行することを決定したとき、彼らは情報を適切な場所に持ち込み、組織内の多くの断片化を阻止することを期待していました。一部の人々は、アジャイルが実装された後も、開発者同士が相互に行き来していることに少しがっかりしました。しかし、彼らが気づかなかったことは、それがますます少なくなっているということです。しかし、それは時間がかかりました。ですから、もしそれがあなたの組織で起こっていることなら、人々は夜通し物事を修正するためにアジャイルを期待しているかもしれません。それだけでは機能しません。