一般論から、個人的な感想まで記述します。
パターン１：固定期間のサイクルが保てない。
外部要因でサイクルの途中にリリース作業が発生する。
リリース済み機能のバグ修正等が頻発し、新規機能の実装が進まない。
リリース後に発見されるバグは、一般的にスプリントサイクルとは無関係にインシデントとして報告されるため、優先順位を上げざるを得ないことが多い。
開発チームの外部にテストチームが存在する場合、開発中の当該スプリントの進捗を妨げないような配慮が必要となる。
機能が増えるにしたがって、機能の正当性を証明するための工数が増加する。
パターン２：アジャイル開発をやりつつ、従来開発のプロセスも維持しようとする
パターン３：よく分からずに、なんとなくやってみた
評判から、うまくいくという幻想のみで手を出した
よくするための努力（分析・改善活動）を怠っている
パターン４：周囲の忍耐力が足りない
その他の開発手法も完全でないことを忘れている
それまで採用していた開発手法が完璧でなかったから、別の開発手法に手を出したことを忘れている
それまで採用していた開発手法が最初からうまくいっていたわけではないことを忘れている
不足している点に注目が集まってしまう
パターン５：管理者（上司）が昔の自分の成功体験を引きずっている
かつての「ウォーターフォール開発」が輝かしく思える
大原則は『工程の後戻りはしない』だが、実際に後戻りしないプロジェクトは存在しない。
開発の終盤で発覚した、設計ミスや仕様バグは取り返すことが困難。
ウォーターフォールですべてがうまくいったことなどない！
パターン６：各スプリントで完成度が低いまま、リリースを繰り返す
レビュー時点で解決できていない課題を技術負債に蓄積することで、とりあえずリリースする。
負債に蓄積するだけで、負債の返却（返済計画の作成）を実行しない。
結果として、問題がある状態が改善されないまま放置される。
そのような状態を放置できてしまう「チーム全体」の問題（開発メンバーだけの問題ではない）
- チーム全体で「リリース可能な品質を維持し続ける」ということを無視している状態。（≒パターン３）
パターン７：チームメンバー内で能力差が大きいため特定の人に業務が集中する
- スクラム開発に限らず、どんな開発手法でも発生する。
参考文献
以下の書籍から大きな影響を受けました。
