公式には、スクラムはより高い品質、「リリース可能な可能性のある」増分、そして継続的な改善を約束する。
実際には、技術的負債はスプリントを重ねるごとに蓄積され、最終的にはタブー視されるようになることが多い。
多くのチームにとって、スプリントはレースのように感じられる。
• 特定の量のユーザーストーリーへのコミットメント、
・速度に関する暗黙の圧力、
・業務上の必要性から、レビュー期日が小さな締め切りへと変化していく。
結果として、その機能は「合格」するものの、コードは脆弱で、テストが不十分で、保守が困難になる。
多くのスクラムチームでは、「完了の定義」（DoD）は以下のように限定されています。
•「コンパイルされます」
•「私のマシンでは動作します」
・「機能的に検証済みです。」
新機能は本番環境に投入される一方で、目に見えないが不可欠なタスク、例えばリファクタリング、自動テスト、最小限のドキュメント作成、アーキテクチャのアップグレードなどは後回しにされる。
チームは負債の存在を認識しているが、公式には存在しない。
• プロダクトバックログに専用の項目はありません。
• 明確な優先順位付けなし、
・明確なビジネスレベルでのトレードオフは存在しない。
それは「幽霊債務」となり、開発業者が「少し時間がある」ときにこっそり対処されるだけで、つまり実際には全く対処されないままになる。
実際には、多くのプロダクトオーナーは次のようなことをしています。
・技術的負債の優先順位付けを行う権限がない、
・利害関係者からの圧力に直面する、
・中期的な技術的影響を測定する手段が不足している。その結果、ロードマップは新機能で埋め尽くされる一方で、製品の進化能力は静かに低下していく。
最終的に問うべきは、「私たちは今日生み出している負債を意識的に受け入れるのか、それとも現実から目を背け、明日この技術的負債の結果に苦しむことを選ぶのか？」ということだ。
スクラムは犯人でもなければ、万能薬でもない。
コントロールを取り戻すための具体的な方法をいくつかご紹介します。
奇跡的な治療法を提供すると主張するつもりはないが、特定の取り組みは現場で実際に効果を発揮する。
・バックログにおける債務を可視化する、
• 完了の定義を強化する、
• 品質のためにスプリント容量を明示的に割り当てる、
・振り返りを活用して、人間関係に関する指標だけでなく、技術的な指標も追跡する。
技術的負債は、そう簡単には消え去らない。
しかし、それが集団的に認識され、共有されるようになれば、管理可能なものとなる。