発端
こういうお話はこの件だけではなく、スクラムやアジャイル型の開発手法を導入したプロジェクトでちょくちょく聞きます。引用リツの通り、これはスクラムがどうのこうのではなく、ゴールの共有と開発者のメンタリングがうまくいっていないだけだと捉えています。
解決策
おすすめしている通り、まずスクラムチームの現状を正しく把握するべく、セルフチェックを実施してみるのがいいかと思いました。
以前に私のチームではこのセルフチェックリストを利用して開発者とスクラムへの理解やロールの必要性を再確認した経緯があり、かなり有効だったと感じています。
上記のポストに戻ると、私のチームと状況は似ておりゴールとインクリメントの検査を改善すればスクラムで進めてもなんとかなるだろうなと感じました。
以下、私からの案です。一例なのであしからず…。
スプリントゴールを明確にする(PO立てる)
開発者が自由にSBIに積むのを禁止する(PBIは問題ない)
インクリメントを準備する(PO立てる、ステークホルダー呼ぶ)
完成の定義を忠実に守る(開発者だけで勝手に決めない)
SM立てて各種イベントで起きる障害排除を促す
まずスクラムというフレームワークから逸脱している部分を正しく認知し、そこに問題点がないかを確認すべきでしょう。そして、スプリントを回している意味を理解しましょう。正式リリース直前にまずいということが分かるのは根本的にアジャイル型の開発でイテレーションを回す意味を理解していないのと同義です。
また、これをウォーターフォール型の開発で実施した際もゴールを設定せずに各種工程を回せば、要件定義~開発でとんでもない戻りが発生し、メンタリングも不十分でテスト工程で確実に爆散します(経験あります)
そもそもスクラムが悪いのか？
上記ポストのケースでは、当人がどのようにこのチームと関わっているのか不明ですが、スクラムだろうとなんだろうとこのチームの考え方や向かう先をマネジメントできないのであれば、失敗して終わりだろうなと思います。今回の問題は、スクラムではなくチームが根本です。それをスクラムイベントに則って解決しようと何人かが引用したのではないなと思います。(当人はテンプレ的な回答と揶揄してましたが、そのテンプレができてないんだと思います)
また、スクラムでも他アジャイル型開発手法でもマネジメントしなくていいわけではないです。必要に応じてPjM, PdM, PLなど責任者を立てるべきです。
全員が対話しながら自走してゴールに向かってくれることは確かにアジャイルのあるべき姿ですが、それはチームに属しているメンバーの性格や業務への姿勢が千差万別である以上、理想論に近いと思います。そのギャップを埋める人がいても、スクラムやアジャイル型開発手法と特にコンフリクトしません。
おそらく、マネジメント不要論などを提供しているアジャイルなチームは、既にそういったギャップを埋める努力をしており、かつ採用で厳選したメンバーを揃えているんだと思います。そのため、チームマスタリーを得ており、それを多くの組織でいきなり実現させるのは無理です。
スクラムというフレームワークを槍玉に挙げる前に、マネージャーとしてチーム(メンバー)の状況と真摯に向き合うべきなのではないでしょうか？