あなたのチームは仕事の方法論（スクラムなど）に従わなくてもうまく機能していますか？
私は過去9年間、いくつかの小さなチームで働いてきました。それぞれに、短い会議、改訂管理、継続的インテグレーションソフトウェア、問題追跡などの明らかな優れた実践がありました。
この9年間、私は開発方法論についてあまり聞いたことがありません。たとえば、「私たちはスクラムをやっている」、「アジャイルを実行する」など、渡された参照以上のものはありません。すべてのチームは問題なく機能しているように見えましたが、多くのプロセスを経ることなく、自由に流れていて自然にうまく機能していました。
他の誰かがスクラム/アジャイルなどに遭遇することなく長期間進歩しましたか？
私がこれらに持っていた唯一の露出は、このようなサイトを通してです。私は Sprint Meetings-何について話すか ...のような質問を読みます...そしてすべての話は方法論の有限状態マシンに従う人々のようなほとんどロボットのように見える。それは本当に（誇張されていますが）そうですか？インターネットに「ベストプラクティス」の支持者を大声で投稿し、人々がどのように働いているかを実際に反映していない、同様の教科書の見方をしている人がいるのではないかと思います。
さらに（私はイギリスにいるので、関連があるかもしれません）...方法論が私が取り組んでいるチームのいずれかに導入された場合、彼らはそれを愚かで不必要であるとして拒否するだけだと思います...その後、オン。私は同意する傾向があります、以下のプロセスは少し不自然に思えます。これは典型的ですか、それとも一般的ですか？
ここでは20年以上の開発経験があり、正式な方法論を使用したことはありません。それらを必要とせず、将来使用する予定もありません。方法論は一部の人には問題ないかもしれませんが、優れたテスト済みコードを書く熟練したプログラマーに代わるものではありません。
個人的には、今日の最もホットな新しい方法論に従うことをあまり気にせず、コードの品質にもっと焦点を合わせることが多くの人にとって必要だと思います。
正直なところ、小規模なチームがプロセスを考慮せずにこれらの年の間ずっと大きな事件なしにうまく働いていたなら、おそらく何らかの形のアジャイルを行っていたでしょう。すべてのアジャイルプロセスとは、「アジャイルマニフェスト」 http://agilemanifesto.org/ に準拠していることを意味します。これは、反復、ストーリーボードなどについては、驚くほどのことではありません。アジャイルの最初のテナント「プロセスとツールよりも個人と相互作用」を好むということです。一緒にうまく機能するチームは、プロセスについて真剣に考える必要はありません。
アジャイルのさまざまなブランド（スクラムなど）は、お互いの作業に慣れていない新しいチームがある場合に非常に役立ちます。彼らは、まとまりのあるチームを構築する方法の枠組みを設定し、それがまとまりのある製品を構築します。
あなたがしていることがうまくいっているなら、それを続けてください。成果物が常に遅れる場合、定期的に時間外勤務を行わなければならない場合、または何かを展開した後に主要なバグを修正する必要がある場合は、何かがおかしいです。そのとき、問題を修正するために一連の小さな変更を行います。
すべてが問題なく常に問題なければ、問題はありません。新しい方法（チームは正式な方法でもそうでない方法でも）を導入しても、実際には時間の無駄になります。
方法論が実際に役立つのは、チームが問題に遭遇したとき、または外部ソースから問題が発生したときです。方法論は、優れた実践を紹介するだけではなく、保護それらを助けます。意識的にそれらを行っている場合、ストレス下で優れた実践を維持する方がはるかに簡単です。
私は必ずしも正式な方法論が必要だとは思いませんが、効果的なIMHOを実現するには、すべてのチームが作業に何らかのパターン（必ずしも繰り返す必要はなく、イベント駆動型である可能性があります）が必要です。
解決する問題がない場合は、ラッキーです。
多くのチーム（特に非常に小さな会社）が、定義された方法論なしでうまく機能しているのを見てきました。
方法論（またはテクニック）を実装するのは、それが楽しいから、またはインターネットでそのブログ投稿を読んだときに非常に危険だからです。
元気であれば、何も変更しないでください。可能な場合は、いくつかの最適化を試してください。
非常に賢明なものもあれば、非常識なものに接しているものもあり、膨大な数の方法論があります。それらはすべて成文化しているようです常識、彼らに面白い名前を付け、そしてたくさんの本/セミナー/その他を販売します。
あなたの経営陣、または実際にあなたのチームが常識に欠けており、有機的に独自の賢明な方法論が（意識的であろうとなかろうと）適所にない場合、彼らは調査し、方法論の一部に取り組む価値があるかもしれませんそのチームの経験に関連。
最新の<insert-buzzword-here>の作業慣行を全面的に課すことは、それが解決しようとしている以上の混乱を引き起こす可能性があります。しかし、通常、非コーディングラインマネージャーが熱狂的にチェックできる多数のチェックボックスメトリックを提供できます。
多分あなたはそれをアジャイルやスクラムと呼ばなかったかもしれませんが、それはあなたがプロセスがなく、それを使用していなかったことを意味しません。
ソフトウェア開発そのものと同じです。名前で明示的に考えなくても、おそらくいくつかのデザインパターンを使用することになります。