Most approaches to metrics are dominated by a “conformance to plan” perspective in collecting and evaluating data. Stakeholders for software development legitimately care about questions like:
- Do deliverables arrive on time?
- Are we spending funds at the planned pace?
- Does the product work as specified in the requirements?
- …. and the list goes on …
All of the questions above seem to presume that the baseline requirements, budget and schedule are (and remain) the ‘correct’ targets for the program. However, when we look at almost any major program in the DoD portfolio, we see episodic re-baselines for requirements, budget and schedule during the life of the program. Managing a program through actions that force conformance to an outdated plan driven by requirements which have been supplanted by evolving user needs (and technological innovation) would seem to be counterproductive. Yet the metrics we typically use, drive us in that very direction.
This tutorial will explore the challenge of collecting useful metrics in this complex world. Examples will be provided to illustrate how we can satisfy legitimate stakeholder questions, while maintaining the focus on outcomes the plan was devised to achieve – rather than treating the plan as a goal onto itself.
Organizations successfully developing and delivering on an Agile cadence find they have unique advantages in this regard. Adoption of an empirical process based on incremental delivery of working software enables a near term view of end results. This is a stark contrast to the exclusive reliance on proxies of progress against long-range targets. Successful metrics for Agile organizations have a tactical focus, to motivate near-term and local actions that enhance outcomes – while addressing the long-term roadmap and big-picture view of the program.
