アジャイル手法は柔軟性、対応力、継続的な改善を約束する。しかし現実には失敗がつきものである。失敗したスプリントは異常ではなく、データポイントである。チームが失敗をどう乗り越えるかが、完璧なサイクルを祝うよりも長期的な成功を左右する。 本記事では、開発チームがスプリント目標をまったく達成できなかった特定の状況を検証する。技術的・人的要因、問題を診断するために用いられたリトロスペクティブプロセス、そして速度と品質を回復するために取られた具体的なステップについて考察する。 文脈：チームと環境 🏢 失敗を理解するためには、まず構造を把握する必要がある。組織はクロスファンクショナルチームモデルを採用している。チームは開発者5名、プロダクトオーナー1名、専任のテスト担当者から構成される。作業は2週間サイクルで行われる。 チームは物理的・デジタル両方のトラッキングボードを用いてフローを管理していた。ストーリーは「バックログ」から「進行中」へ、最終的に「完了」へと移動された。目標はコード品質を損なうことなく、一貫した価値の提供である。 主な特徴 チーム規模： 7名（サポートスタッフを含む）。 サイクル長： 14日。 焦点：顧客向けの機能強化。 過去のパフォーマンス： 過去6か月間、コミットしたストーリーポイントの80～90％を継続的に達成していた。 事象：スプリント42の崩壊 📉 スプリント42は高い勢いで始まった。チームはバックログから30ストーリーポイントを引き出した。3日目にはペースが安定しているように見えた。5日目には摩擦が生じ始めた。10日目には、コミットした作業を完了できないことに気づいた。 失敗は単一の深刻な出来事によるものではなかった。能力を蝕む、複数の問題が蓄積した結果であった。 出来事のタイムライン 1日目： スプリント計画完了。30ポイントをコミット。 3日目： 前回リリースで深刻なバグが発生し、開発者2日分の作業を消費した。 5日目： 外部依存APIが予告なしに予期せぬ変更が行われた。 7日目： 要件の明確さが感じられなかったため、チームの士気が低下した。 10日目： 前回のスプリントからの技術的負債が新しい開発を妨げるようになった。 14日目：
