アジャイルで成功するには何が必要ですか？

一部の組織ではアジャイルの採用が失敗する場合があります。ウォーターフォールが唯一の（真の）方法である会社で働いていましたが、それは彼らがプロジェクトでアジャイルを試みて失敗したためです。

まだ覚えている人たちに聞いたとき（私は後輩でした）、本当に起こった悪い悪夢を思い出させたように、私は激しくシャットダウンされました。

プロジェクトが失敗した理由はわかりません。一部の企業ではアジャイルが失敗する理由がウェブ上に記載されていますが、その理由は主に経済的です。そこで、私はここでいくつかのフィードバックをお願いすると思った。

一部の組織でアジャイルの採用が失敗する理由は何ですか？または、別の言い方をすれば..アジャイルで成功するには何が必要ですか？

アジャイルの考え方とアジャイル手法を理解してサポートするには、管理者、クライアント、開発者がそれぞれ必要です。さらに詳細に：

• 経営陣は、彼らが伝統的に聞くことを期待していたものとは対照的に、真実を聞くことに快適でなければなりません（つまり、「はい、プロジェクトは順調です」11か月... ...えー、月...えー...」最後に）彼らはまた、各当事者に仕事をさせて（そして責任を負わせて）快適でなければなりません。最も顕著なのは、開発者が技術的な決定と見積もりを行うことです。そのため、厳密な制御とマイクロ管理はありません。
• クライアントは、アジャイルが「注文をする」だけでなく、数か月後に配信を引き受けるだけでなく、開発プロセスに深く継続的に関与する必要があることを理解する必要があります。また、大きな固定要件仕様の欠如と、最初に要求されたものを提供するための開発チームの明らかなコミットメントの欠如により、快適でなければなりません。
• 開発者は、責任を負い、意思決定を行い、オープンにコミュニケーションをとり、チームとして働くことに慣れていなければなりません。つまり、「コードの所有権」も「孤独なカウボーイ」も、チーム自体が解決できる問題に対する他人の無益な非難もありません。

私の経験では、失敗したアジャイルプロジェクトの背後にあることが最も多い最初のポイントですが、他の2つも問題を引き起こす可能性があります。

更新

「管理」とは、直接的なプロジェクトマネージャーだけでなく、より高いレベルも意味します。@Michaelが非常に正しく指摘したように、多少の外部関係者（QAや外部タスク割り当て者など）もアジャイルプロジェクトの成功/失敗に影響を与える可能性がありますが、それはそれぞれのリーダーが許可した場合にのみ可能だと思います、そして/または、組織内で責任と指揮系統が明確でない場合。

必要なもの：

• 非常にオープンで正直になりたいと思っている人々。あらゆる種類のレイヤー境界を越えた信頼が必要なため、可視性がすべてです。
• お客様とマネージャーは本当に真実を聞きたいです。
• すぐに必要なものに合うように役割を再定義して喜んで、できる人。
• 現在動作していないプロセスを変更する自由。
• 間違いを認めて逆転しようとする人々。
• ビルドとテスト環境を一緒に投げる能力の意志で。（これは、人々が信用を与えるよりも重要で高価です。）
• あなたがあなたの壁を埋めることができる限り多くのホワイトボード。

とても単純に思えますが、これらの多くはこの業界では大きな質問です。

アジャイルプロジェクトは、キープレーヤーがアジャイルを拒否した場合、または（悪い）誰かがプロジェクトの成功に正直に興味を持たない場合、またはプロジェクトを完全に妨害する場合に、ほとんどの場合失敗します。後者は（他の多くのことのように）すべてのプロジェクトを殺すことができますが、アジャイルなプロセスは人々により多くの柔軟性を与え、破壊的な政治をする柔軟性を含みます。

例：

• QAは、1か月にわたる手動テストサイクルに合格しない限り、顧客がソフトウェアを見ることができないと主張しています。
• 管理は非現実的な期限を課します
• 顧客は要件の優先順位付けを拒否します（「すべてが最も高い優先順位を持っています！」）
• 直接の利害関係者ではないが、政治的な影響力がある人は、重要なチームメンバーに長時間の無関係なタスクを割り当て続け、プロジェクトマネージャーはこれを防ぐことができません。

私は自分の個人的な経験からのみアドバイスを与えることができます。

私がアジャイルで完全に失敗した雇用主。作業はアドホックに行われ、テストは存在せず、要件は電子メールと会議議事録に文書化されました。使用された唯一の開発方法は、無秩序、または「火と忘れのコーディング」でした。開発者が働きすぎてストーリー追跡プロジェクト管理ソフトウェアをセットアップできないため、何らかのソフトウェアエンジニアリング手法を実装することは不可能でした。

別の雇用主では、私たちのチームには必死にアジャイルのベストプラクティスを確立しようとする英雄的なメンバーがいました-かんばんボード、課題追跡、TDDとBDDを使用しました（アジャイルではありませんが、アジャイルグループに存在する傾向があります） 。残念ながら、ストーリーポイント、推定セッション、キャパシティプランニング、バーンダウンチャート、速度グラフなど、仕事をスムーズに進めることができるアジャイルプロジェクト管理のようなものがありませんでした。アジャイルがうまくいかない典型的な症状として、かんばんボードがいっぱいになったときに、より大きなボードを購入しました：/

私が現在いる場所では、2週間の反復、TDD、毎日のスタンドアップ、反復ごとのタイムボックス化されたレトロスペクティブ、およびほとんどのことに関するペアプログラミングでキャパシティを計画する方法としてストーリーポイントを使用します。これは、総経営陣の賛同と顧客教育の結果です。

アジャイルが企業で成功するためには、次のものが必要だと考えています。

• アジャイルを理解し、ツールを適切に使用するプロジェクトマネージャー。
• アジャイルを理解し、オープンで正直な開発者は、アジャイルの規律を必要とします
• クライアントからのバイイン。彼らはアジャイルの利点を認識し、与えられた時間枠で開発できるものに関して開発者からのアドバイスを喜んで聞く必要があります。

編集：また、毎日のスタンドアップや短い反復などが役立つ理由を十分に理解しておくことも重要です。

私のアジャイル失敗の経験は、経済学とは関係なく、企業/部門/個人の政治とは関係がありませんでした。

個人的なレベルでは、性格が衝突する人がいます。彼らをアジャイルチームに、またはさらに悪いことにペアのプログラミングチームに追い込むと、お互いの嫌悪が沸騰点にエスカレートします。これは非常に厄介で非常に迅速になり、現実のショーにふさわしい妨害行為のようなものをもたらし、スクラム会議を非難の円形の発砲部隊に、またはさらに悪いものにします。

その上に、開発管理があります。私はこれが2つの異なる方法で間違っているのを見ました。

1つ目は「カーゴカルトアジャイル」で、マネージャーはマニフェストと、それらを使用する理由と時期、即興を行う理由を正確に理解せずに正確に読んだクラス/ブック/ウェブサイトに従うことを主張します。アジャイルマネージャーは魔法が起こるのを待っているようです。このアジャイルのプロクラスの実装は、プロジェクトの失敗につながる多くの問題を引き起こす可能性があります。

もう1つは「アジャイルインネームオンリー」で、スプリントやスクラムなどの用語が使用されますが、実際には、マイクロ管理、指揮系統を上下する不正、長い役に立たないステータス会議などの古い慣行を単にラベル付けするだけです。プロジェクトは以前と同じように失敗しますが、アジャイルは管理の悪さではなく非難できるようになりました。

その上に、プロジェクトのクライアント/顧客による賛同の欠如があります。これらの人々は、部門ごとに優先順位を持ち、それが彼らの経営陣の仕事の不可欠な部分であることを明確にしない限り、開発チームと協力することに抵抗することができます。これは、部門の政治や企業の方針によってさらに悪化する可能性があります。たとえば、運用とマーケティングの両方にプロジェクトへのインプットがあり、チームは何も合意できないため、チームは最終的に車輪を回転させます。もう1つの例は、時間管理と請求に関する企業ポリシーが競合を引き起こす場合です。実際、外部の顧客は内部の顧客よりも扱いやすいことがわかりました。彼らはプロセスから得られる注目が好きで、お金の価値を手に入れていることを知っていました。

IMO「アジャイル」は、プラクティスの大規模な賛同がない場合に失敗します。私が言っているのは、アジャイルが「顧客」（通常は別の部門またはマネージャー）に依存しているということです：

1. 彼らは、ソフトウェアに何をしたいのかを100％知らない
2. 完了したと思う場合でも、完了するまでにかかる時間はわかりません。
3. 彼らはそれがどれくらいかかるかを告げられ、それを受け入れるか、期限を満たすために機能を減らす必要があります
4. 反復ごとに機能を選択する必要があり、100％完全なアプリケーションを一度に取得することはできません。

これらはすべて、ほとんどのマネージャーが飲み込むのが非常に困難なものであり、IMOはアジャイルを実行するのが難しい理由の1つです。 （開発者が80時間の週を置いた後）、開発チームがこのプロジェクトが3か月で完了することをあなたに伝えようとしていることを理解するのは180 です。早くやった。

第二に、開発チームへの信頼が必要です。上記の＃1と手を取り合ってみると、専門家として雇われた人々の意見を実際に信じているマネージャーはほとんどいません。開発者は、プロジェクトが時間の量xがかかります、そしてxはより多くの経営者は、それが取ると考えよりも、それはですされていないと言うならば決してそれは「もっとだ「開発者が右おそらくあるので、私は、ソフトウェアを書く方法がわからない」の場合役に立たない開発者たちは仕事をやめたいので、3か月かかると言いました。」

第三に、開発チームはアジャイルの背後にいる必要があります。つまり、角を切ったり、「これは正しいのですか？xが発生したらYは何をすべきか？」という絶え間ないフィードバックと質問を無視しないということです。TDDやペアプログラミングに従わない場合でも、開発チームはアジャイルプロセス（スプリント、反復など）に十分対応できる能力が必要です。これには、タスクを適切に見積もることができ、すべての機能を優先する必要はないこと、仕事のバックログを残してもかまわないこと、従業員を過労にしないことを理解できるリード/マネージャーが必要です。