This episode is part of a wider mini-series looking at Estimation in Software Development. In this episode, I wanted to highlight the emotional baggage that you developers may associate with estimation, and through no fault of your own, will carry that baggage into future estimation work. In the episode, I look at the psychological scarring left behind from decades of using estimates as punitive targets. Like most experienced developers, I've worked in organisations that turn estimates into punitive targets - where a well-meaning estimate has been turned into a commitment, and ultimately, a stick to beat the team with. Now that stick has ranged from the aggressive to the passive, be it threats of dismissal or simply discussing the failure to hit the estimate.
Or listen at:
Published: Wed, 15 Jan 2025 01:00:00 GMT
Links
- #189: Estimation - a review
- #194: Estimation - What are you actually asking for?
- Software Estimation: Demystifying the Black Art by Steve McConnell
Transcript
Hello and welcome back to the Better ROI from Software Development podcast.
This episode is part of a wider mini-series looking at estimation in software development. I started the mini-series in episode 189 by providing the following guidelines:
- Don't invest in estimates unless there are clear demonstrable value in having them.
- Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate.
- provide the team with training and time to develop their estimation skills.
- Collect data on points 1 to 3 and regularly review if you have the correct balance.
Subsequent episodes take a deeper dive into specific aspects of estimation in software development. And while long-term listeners may find an amount of repetition across the series, I wanted each episode to be understandable in its own right, as much as practical, to be self-contained advice.
In this episode, I want to discuss the psychological scarring left behind from decades of using estimates as punitive targets.
Like most experienced developers, I've worked in organisations that turn estimates into punitive targets - where a well-meaning estimate has been turned into a commitment, and ultimately, a stick to beat the team with.
Now that stick has ranged from the aggressive to the passive, be it threats of dismissal or simply discussing the failure to hit the estimate.
As I talked about in episode 194, it's common for different people to interpret an estimate differently.
As a software developer, I may estimate the effort involved to do the work.
As a project manager, I may expect a target date by which the work is done.
As a stakeholder, I may expect a commitment.
As a software developer, I could be giving a three-month effort estimate.
As a project manager, I'm treating that as 3 months from today, as a target, without taking into account other work, holidays, sickness, and a myriad of other factors that influence scheduling.
And as a stakeholder, I'm taking it as a commitment to have it done by that date.
And even when there is a consensus on the meaning, the nature of estimates means they can be wrong, and occasionally take longer than expected is simply a fact of any complex activity.
However, that message has taken a long time to work its way through our organizations and into our leadership structures.
And while I'd like to believe that aggressive punitive action, like the threats of dismissal or weekend working to catch up, is largely a thing of the past, the more passive-aggressive approach of labelling things as a failure is still common enough to be a problem.
Thus, let's take a moment to consider what is running through the developer's head, and heart, when we ask them for an estimate.
While I'm sure that everyone listening to this episode will be asking with the best of intentions, we cannot control the historical baggage that the developer carries, the scars of previous punitive action.
Many of us will be aware of it, even if only subconsciously - how often have we used the lines like "I promise you won't be held to it"?
We are often dealing with a level of emotional turmoil that, no matter how well the developer performed in the work, if it's delivered late it will be treated as a failure.
So much so, is it any wonder that even in the most well-meaning enquiries, we're often met with a reluctant, or worse, an overly pessimistic estimate.
But it shouldn't be much of a surprise that where there is a lack of trust, dysfunction follows.
If the situation is reversed, how would you respond?
Maybe you'll drastically overestimate, often described as sandbagging, to ensure that you'll have the work done in the time.
Maybe you'll provide the estimate with so many caveats, you'll make the Apple Terms and Conditions writer blush.
Maybe you'll just be so fatalistic to it that you simply turn off, go through the motions robotically, dampening the anticipated pain of failure, in short, simply not caring.
None of these responses are useful, and ultimately will lead to further breakdown of trust, leading to even more dysfunctional actions.
I've certainly been in environments that the developers will overestimate because they don't trust the project manager. The project manager then reduces the estimate because they know the developers don't trust them and thus will have overestimated. Only to then have some stakeholder higher up reduce the estimate again as they don't trust everyone beneath them are trying hard enough.
Ultimately, what value can these estimates bring anyone?
The only possible outcome is a poorly performing toxic work environment.
So it begs the question, what do you do if you start to develop that toxic, dysfunctional behaviour? In short, it's not easy.
Trust is easily lost, and very difficult to re-establish. You could spend years building up trust, only to have one slip-up put you back to square one.
The easiest approach is probably to remove estimates entirely. If the anticipated value for estimates isn't great, then simply stop doing that work is a practical solution.
I'd even argue that if you're heading into that toxic, dysfunctional behaviour, that you will not have been getting the value from the estimates that you will have wanted to. Thus, stop doing them will leave you in no worse a position. However, if there is true value in getting those estimates, then prepare for the long haul to re-establish trust through all the levels involved.
And the best starting point is simply to talk about it as a group.
If the wider team can be made aware that the trust is breaking down, and then have an honest conversation about it, then attempts can be made to restore that trust.
But to do this, all of those involved have to be aware of the impacts, real or imagined, and proactively work to ensure that any form of punitive language or actions are removed from the activity, and be prepared to call it out if any of those approaches creep back in.
The approach is not dissimilar to moving an organisation to becoming a learning organisation. A hypothesis-driven environment. One in which every lesson is celebrated as a way of moving forward.
In this episode, I wanted to highlight the emotional baggage that you developers may associate with estimation, and through no fault of your own, will carry that baggage into future estimation work. It may seem unfair that previous experiences are affecting you getting your job done, but our past experiences are what make us what we are.
From the short story, "George", by B.J. Neblett:
"We are the sum total of our experiences.
Those experiences - be they positive or negative - make us the person we are, at any given point in our lives.
And, like a flowing river, those same experiences, and those yet to come, continue to influence and reshape the person we are, and the person we become.
None of us are the same as we were yesterday, nor will be tomorrow."
As I've said in the past, software development is a team sport, a people-based activity. As such, we have to take into account the individual's personalities that come with them.
In the next episode, I want to introduce some practical methods to develop estimation skills
I introduce two approaches to estimation, Qualitative and Quantitative.
Qualitative estimation is predominantly based on expert judgement, something based on subjective thought process.
Whereas Quantitative is based on something we can count or calculate a use of statistical analysis based on historic data.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.