問題の本質を捉えるのはとても重要
自分が担当しているチームではKPT法を取り入れて、定期的に改善MTGを行っています。
当然色々なP（Problem）が出てくるんですが、出てきたPの本当の問題はなんなのか？ということを掘り下げずにT（Try）を決めると、かえっておかしなことになります。
なぜこうなるか？といったことをきちんと説明してくれている記事を見つけたので、紹介がてら個人的な意見と付け足してみる。
※重ねて言いますが、スクラム嫌いじゃないです。むしろ大好きです。
※DevOpsも大好きですよ。
以下、記事から抜粋
・開発組織の問題を解決するためのマネージャーの施策として、デプロイを自動化して開発スピードを上げ、試行錯誤できる回数が増やしたり、チームビルディングをしてコミュニケーション不全を解消を図ろうとしたりすることは多いですね。
⇒
コミュニケーション不全はたいていの場合、チーム外の環境に問題があることが多いです。
会社の組織風土、社長・役員・事業部長といった上層部の組織マネジメントのレベルの低さ、組織間で連携せず互いに独立で動いたり、情報を隠蔽してこっそりやるのが好きな人間が上のほうに集まり社内政治が非常に活発、評価が適正でない（と強く感じる）、給料が低い、などなど。
このような状態になると、社内で健全に議論ができなくなり、メンバーの状態が非常に不健全になり、パフォーマンスが出なくなったり、辞めていったりとなります。
・チームビリディングをして、環境を良くすれば勝てるわけではない。チームビルディングをするなら勝つための戦術を実行して、そこで分かった状況に応じてチームの現状課題を分岐する、ということが大切
⇒
仮に、そう、あくまで仮ですが、こんなことを言う人がいたとします。
「今勝てないのはベンチャーのような速さがないからだ。だからスクラムやって速さを手に入れるんだ。そうすれば勝てる！」
まず、勝てない原因を「速さ」と分析しているのがおかしい。
素晴らしく速いスピードで開発はできていなくても、それなりにスピードは出ている。
単に戦略ミスってるので、当たらないだけの場合がほとんどなんじゃないかと。
であれば勝てない原因は社長・役員・事業部長といった方々のはずで、それを開発部隊に丸投げするなんて、他責の最上級ですよね～。
自身を常に振り返らない組織に明日はないぞ、と。（負の感情吐き出して申し訳ないです）
まあ、それはおいておいて、事業の内容・競合の状況・フェーズ（立ち上げ、保守運用など）によって、一番求めるもの（速さ・正確さ・調整能力など）・最適な開発手法・チーム構成は変わってきます。
なので、勝てるチームを作るには、地道にPDCA回して、適宜優れた開発手法のエッセンスを取り入れ（つまみ食いともいう）、Fit&Gapするしかないのです。
※スクラムは優れた開発手法で、個人的にも大好きですが、銀の弾丸ではないです。
これに気づかず、すべて一律の体制で開発しようとする、ナマケモノ or 現場を知らない人が責任者をやっている会社には未来はないと思って、まず大丈夫です。
就活や転職をする場合には、サービス内容や業界での立ち位置だけでなく、どのような思想で、どのような開発手法を採用しているかを、是非全段階の面接官に聞いてください。そして、色々質問をしてみてください。
回答の仕方や内容にその会社の真実が結構にじみ出てくるので、会社選びのよい参考になるでしょう。
