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
Or listen as a podcast:
🎧 Soundcloud
🔔 Subscribe for 90+ videos on healthy software development
Top comments (8)
There's this famous law which states that "When a measure becomes a target, it ceases to be a good measure.". The problem is not just with the measures but how they become indicators of success. This incentivizes really bad practices like rewarding lines of code written, number of tickets closed, number of commits.
Time estimation is a dark art for most people. It creates a culture of unrealistic deadlines and forces even those with better estimates to lower their own and stay competitive.
On a related note, even successful products (e.g Facebook) have measures of engagement and try to optimize features for that resulting in unintended consequences like filter bubbles, click-baity headlines and content farms.
Couldn’t agree more. Great examples.
Very well put, and as OP video points out - it stops focus on the real progress. With the whole wheel and engine example from previous post, if the only measure is if engine is overheating, sure, you'll end up somewhere, but you also need to check GPS to make sure you are going to right destination.
One thing I would say about time estimation tho, it could be beneficial if multiple departments are working towards same goal, lets say marketing needs to promote the new feature.
It would be wasteful to complete the feature and only then start figuring out marketing, write their copy etc.
In the end it's always about open and honest communication, specially if it's bad news and "there will be delays".
Nice. I totally agree we will have times we should estimate to coordinate dependencies and ballpark things, but the overall value of the estimate is almost meaningless. It might help you not start building something way out of your budget, but it won’t tell you the real cost since the product has to change.
When the CFO or whoever’s funding the project does so monthly - they know the real cost up front. What they don’t know is the scope. And they don’t need to because the team can try multiple times to satisfy the customer for as long as they’re funded. The work they do has to result in profit, but measured less frequently on milestones agreed upon by everyone as targets. But these are revenue targets (or some other measurable business result) - not targets for a fixed scope of product functionality.
Thanks.
You’re very welcome. I hope some of this helps.
Great post/video!
Thanks Kasey! Glad you enjoyed it. ✌️