Can Measuring “Progress” Make Software Projects Fail?
Tags: agile, culture, productivity, design
Published: 2018-06-13 00:53:39

---
title: Can Measuring “Progress” Make Software Projects Fail?
published: true
description: There’s an old saying “you improve what you focus on, and you focus on what you measure”.
tags: #agile #culture #productivity #design
---

There’s an old saying “you improve what you focus on, and you focus on what you measure”.

There are too many companies I run across focused on the wrong things - _because they’re measuring the wrong things_.

## The Pressure To Be Cheap

Traditionally software development teams are measured by how much money it costs to build the product.

Since this is the focus, people doing the measuring are rewarded by _how cheap they can make it_.

But a product being cheap to build has nothing to do with how successful the business is overall.

This takes the right combination of pricing, service, and everything else that goes into customers wanting to pay for the software we build.

All of the software products that prove to have staying power (Amazon, Facebook, or Linux as examples) _were changed to be significantly different from their original design_ when customers fully embraced them.

Projects that focus on how cheaply the original vision of the leadership can be built, don’t have any money leftover for customers to adapt and change a product.

## Budgeting Agile

CFOs and other accountants at your software company should really budget agile software projects like you budget a Netflix subscription.

They decide how many people the company can afford over a period like a year and pay monthly.

When things change, **no one on your team has to go get approved for more money because the team is fully funded for the month**.

The team does whatever is necessary because they are fully paid for to build whatever’s most valuable at any moment.

## The Danger Of Focusing On Speed

So let’s say your project is budgeted monthly.

You can still estimate and track time, but it provides little benefit since building the right thing is more important than building fast.

If speed is focused on, _it actually makes it harder to build the right thing_.

Measuring speed costs time and money for the people doing it.

It also creates conflicts of confidence between two people when a measurement changes.

Now _two or more people have to discuss and rectify why_ an estimate was off, or how much a change a customer wants will cost.

Measuring how close a team’s work on an agile software project is to a plan is stupid because the plan has to change.

When it does change, the skill and creativity of the people determine success, not how close people can make numbers look like the original plan.

## Focus On Measuring Business Outcomes

So your company should focus on measuring whether the product you’re building is achieving financial goals for growth, not cutting the cost of development.

This all might sound like common sense but _many people can’t live without their estimates and daily progress to track_.

They have to let go of measuring the wrong thing, to **let the team adapt to build the right thing**.

And they have to be more patient, because _the financial outcome of building a feature takes longer to get feedback on than the effort a team spends_.

So next time you’re deciding whether to estimate cost or measure the velocity of a software team ask yourself:

“Is what I’m measuring really making the business successful, or just giving me a number to track that gets in people’s way of doing their best work?”

# [📺 Watch this video on YouTube](https://www.youtube.com/watch?v=0yxfb-drlE4&list=PL32pD389V8xt_znF-pvOl7OP_xNfnkGgq&index=2&t=0s)

Or listen as a podcast:
[🎧 Soundcloud](https://soundcloud.com/jayme-edwards-media/is-your-team-really-measuring-software-projects-correctly)

<hr />[🔔 Subscribe for 90+ videos on healthy software development](https://YouTube.com/c/JaymeEdwardsmedia?sub_confirmation=1)