Ability to Innovate (A2I): Technical Health

Level: Advanced Module: Evidence-Based Management 3 min read Lesson 44 of 52

Overview

  • What you’ll learn: The Ability to Innovate KVA, technical debt and its impact, innovation rate metrics, installed version index, and strategies for improving A2I.
  • Prerequisites: Lesson 40 — What is EBM?
  • Estimated reading time: 14 minutes

Introduction

Ability to Innovate (A2I) measures how effectively your organization can deliver new capabilities. It is not about whether you want to innovate — everyone wants to innovate. It is about whether you can. Technical debt, legacy systems, complex architectures, and manual processes all erode A2I.

Think of A2I as your organization’s health: a healthy person can run a marathon; a sick person struggles to walk. A healthy codebase can absorb new features quickly; a debt-ridden codebase turns every change into a multi-week excavation project.

What Erodes A2I

  • Technical Debt: Shortcuts taken in the past that make future development harder. Debt accumulates interest — the longer you ignore it, the more it costs.
  • Manual Processes: Manual testing, manual deployments, manual data migration — anything that requires human intervention that could be automated.
  • Knowledge Silos: When only one person understands a critical system, your innovation capacity is limited by their availability.
  • Legacy Systems: Old systems that are difficult to modify, poorly documented, and expensive to maintain.
  • Defect Rates: High defect rates mean development time is spent fixing bugs instead of building new features.

Example A2I Metrics

  • Innovation Rate: Percentage of time spent on new features vs. maintenance/bug fixes. A healthy team might be 70/30 or 80/20.
  • Defect Trends: Are defects increasing or decreasing over time?
  • Installed Version Index: What percentage of users are on the latest version? If only 30% are on the latest release, the rest are on unsupported versions — a maintenance burden.
  • Build/Deploy Time: How long from code commit to production? Long build times slow innovation.
  • Technical Debt Ratio: Estimated cost of fixing all known technical debt divided by total development cost.

Improving A2I

You cannot innovate your way out of technical debt. You must pay it down deliberately:

  1. Allocate a fixed percentage of each Sprint to debt reduction (e.g., 20%).
  2. Never let Definition of Done be “code works” — include code quality standards.
  3. Automate everything that can be automated: tests, deployments, monitoring.
  4. Reduce knowledge silos through pair programming, documentation, and rotation.

Key Takeaways

  • A2I measures capacity to deliver new capabilities, not desire to innovate.
  • Technical debt, manual processes, knowledge silos, and legacy systems erode A2I.
  • Track innovation rate, defect trends, build times, and installed version index.
  • Deliberately allocate Sprint capacity to debt reduction.
本課中文版

概述

創新能力（A2I）量測你的組織能多有效地交付新功能。不是你想不想創新——每個人都想。是你能不能。技術債、遺留系統、複雜架構和手動流程都在侵蝕 A2I。

什麼侵蝕 A2I

  • 技術債：過去的捷徑讓未來的開發更難。債會累積利息。
  • 手動流程：任何可以自動化但需要人工介入的事。
  • 知識孤島：只有一個人懂的關鍵系統。
  • 遺留系統：難以修改、文件不全、維護昂貴。
  • 缺陷率：高缺陷率意味著開發時間花在修 bug 而非建功能。

改善 A2I

  1. 每個 Sprint 固定分配一定比例（如 20%）給債務清償。
  2. DoD 不能只是「code 能跑」——包含程式碼品質標準。
  3. 自動化一切可以自動化的：測試、部署、監控。
  4. 通過結對程式設計和輪調減少知識孤島。

重點整理

  • A2I 量測交付新功能的能力，而非創新的意願。
  • 技術債、手動流程、知識孤島侵蝕 A2I。
  • 刻意分配 Sprint 產能給債務清償。
日本語版

概要

イノベーション能力（A2I）は、組織が新しい機能をどれだけ効果的に提供できるかを測定する。イノベーションの意欲ではなく、能力を測る。技術的負債、レガシーシステム、手動プロセスがA2Iを侵食する。

A2Iを侵食するもの

  • 技術的負債：過去のショートカットが将来の開発を困難にする。
  • 手動プロセス：自動化できるのに人手が必要なもの。
  • 知識のサイロ：重要なシステムを一人しか理解していない。
  • 欠陥率：バグ修正に時間が取られ、新機能を作れない。

A2Iの改善

  1. 各スプリントの一定割合（例：20%）を負債削減に充てる。
  2. DoDを「コードが動く」だけにしない。
  3. 自動化できるものはすべて自動化する。

重要ポイント

  • A2Iは新機能提供の能力を測定する。
  • 技術的負債を意図的に削減するスプリント容量を割り当てる。

You Missed