Should You Really Measure Progress On A Software Project?
Agile Development • Lean Startup • Software Business
You can help a company profit more with the software they build by showing them the right things to measure - but expect some resistance on your project...
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
There’s an old saying “you improve what you focus on, and you focus on what you measure”.
There are just way too many software companies I run across focused on the wrong things – because they’re measuring the wrong things.
In this episode, I’ll show you how you can help your company make more money with the software you build by measuring the right things.
When your company makes more money, you’ll get the opportunities and rewards you want.
Traditional Software Project Measurement
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.
That depends on how well the product was designed so users love the experience.
And whether customers using the product pay enough for our company to make a profit.
This takes the right combination of pricing, service, and everything else that goes into customers wanting to pay for the software.
All this has a much bigger impact on the overall success of the business than just how much building the product costs.
The Cost of Satisfying The Customer
To build a product with a great experience requires taking the customer’s feedback into consideration.
All of the best software products (Amazon, Facebook, or Linux) were changed to be significantly different from their original design when customers fully embraced them.
Here’s the big problem – if you don’t have the money to build what customers want, how cheap you can build your product doesn’t matter.
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.
It’s like building a cheap factory.
You may have saved money by cutting corners, but now the factory can’t churn out products to make any money.
Truly Agile Development Requires Different Measurement
This is why we try to be agile, by building just a little of a product at a time and redesigning it to satisfy the customer at our earliest opportunity.
Agile projects produce a product that emerges through changes over time, so the cost of the initial design has little to do with the real cost.
You should really budget agile software projects like Netflix.
Decide how many people you can afford over a period like a year and pay monthly.
When things change, no one has to go get 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 Low Value Of Tracking Time
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.
Creativity Determines Success, Not How Close We Are To A Plan
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.
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?”
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.