How to measure and how to balance
Many organizations are transitioning from linear software development to agile or lean approaches, creating measurement challenges and complicating status assessments.
Agile and Lean prioritize flow, measuring success through consistent feature delivery and calendar time from concept to release. Linear development uses stage-gate models, comparing accrued hours to estimated workload. When gaps emerge, projects face difficulties.
Hybrid models introduce several complications. Teams often lack discipline in estimation accuracy. While mature teams may provide reliable story point estimates, they frequently overlook significant work categories. Non-visible tasks like inter-team support often go unrecorded, making estimated velocity unreliable.
As traditional accrual tracking disappears in favor of flow-based approaches, teams struggle when delivery slips. They must recalculate how schedule delays affect subsequent sprint velocity.
Development teams focus narrowly on immediate sprints, prioritizing features over broader concerns. This creates an incorrect belief that feature completion equals readiness for release. DevOps addresses this by requiring features meet Definition of Ready criteria before consideration as complete.
Agile struggles partly stem from insufficient analysis and planning resources. Analysis becomes a bottleneck when teams misunderstand expectations. Critically, analysis work itself remains unmeasured and unestimated.
Recommendations
Organizations transitioning between paradigms should enforce disciplined practices. Despite feeling outdated, traditional approaches continue proving their value:
- Collect accrual data systematically
- Measure project scope consistently
- Base decisions on evidence rather than intuition
- Ensure all work categories are visible and measured
- Maintain realistic velocity estimates
The key is not choosing one methodology over another, but implementing robust measurement practices that work regardless of your development approach.