Can Measuring “Progress” Make Software Projects Fail?
Jayme Edwards 🍃💻 Jun 13 Updated on Jun 14, 2018
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.
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?”
Or listen as a podcast:
🔔 Subscribe for 90+ videos on healthy software development