chapter nine

9 Measuring what matters

 

This chapter covers

  • Turning invisible wait states and hidden queues into numbers your team can act on
  • Using lead time, cycle time, activity time, and activity ratio to diagnose stalls
  • Distinguishing system-level signals from vanity metrics that punish collaboration
  • Using Kanban as visual management and building dashboards for improvement
  • Applying control charts to separate normal variation from signals worth acting on
  • Running a hands-on lead time audit to find your biggest bottleneck

Metrics exist for one reason: to make problems you cannot see with your eyes show up in data you can act on. The right metrics reveal where value stalls, where queues form, and where the system, not the people, creates drag. The wrong metrics reward busywork, punish collaboration, and train teams to game dashboards instead of improving outcomes. The difference between a metric that improves a system and one that degrades it comes down to a single question: if this number improves, does the system actually improve? That question guides everything in this chapter, from which metrics to adopt, to how to display them, to how to detect when a metric is being gamed rather than genuinely improving the system.

9.1 Why measure? Making problems visible

9.1.1 Measurement for learning versus ranking

9.1.2 The optimization trap

9.2 Lean metrics for developers

9.2.1 Lead time

9.2.2 Cycle time

9.2.3 Activity time

9.2.4 Beyond the fundamentals

9.3 Avoiding vanity metrics and metric gamification

9.4 Visual dashboards for continuous improvement

9.4.1 From flow signals to flow dashboards

9.4.2 Making it work in practice

9.5 Exercise: Calculate your current lead time

9.6 Summary