A lot has been written about software development metrics. Clearly we need some way of determining how well software teams are doing and how fast they do it. Makes sense, right?
There’s just one problem. The customer (or client, or end user) doesn’t care. If you tell a customer that the software team is working really hard, putting in extra hours, and creating high-quality code, the customer will shrug. She will say something like “I don’t care about that.” And then ask, “When will you deliver the software?”.
Muffle the noise.
Customers can only measure a team’s performance by evaluating delivered software. Everything else is simply background noise. All that other stuff is internally focused on the team. Only the delivered software is externally focused on the customer.
If you want to show progress to a customer, deliver something. The software doesn’t have to be 100% complete. It doesn’t even have to be totally reliable. Call it “beta” or “pilot”, if you like. Just deliver something.
We sometimes get so caught up in paper trails, version control, defect counts, velocity, point systems, etc. that we lose sight of the primary objective — delivering working software. Some teams get so caught up in policy, process and procedures that they forget why they exist at all — to deliver working software.
If you work in an environment where ancillary artifacts and standard procedures are more important than delivering software, offer the minimum needed to satisfy the project police. Use the time you save to deliver working software. That makes more sense.
