In software development, how long is a piece of string is not really a literal question,
is it, but more a rhetorical remark when we're asked to estimate the time it's going to take
to deliver something.
Often from very poorly defined requirements.
"I don't know" we will say.
How long is a piece of string?
I want to start with a story, a software company had signed a big contract with a blue-ribbon
client to take the project in a completely new and exciting direction, and open up many
new levels for the future.
As ever, at the beginning of a project, a scoping exercise was taken and a number of
epics were defined.
These were taken to the software team.
We need you to size these.
Rough estimates are fine for now, but we need them by the end of the week.
So once the protestations had died down about the lack of time, the lack of information
and the fact that this was in a new technology that nobody was very familiar with, the team
did their best and came up with an estimate range of six to 12 months.
That's no good, came the response from the CTO, we need it done by the end of the year.
But okay, because of the complexity and the earn certainty, I will give you an extra four
people.
Let us know if you need any more!
Well, four extra people would be great, but the time it was going to take to recruit and
to train, and ... but by that point, the company had, amidst great fanfare, announced to the
rest of the world that the project would be delivered on 31 December.
Just a side note, if that is not already blindingly obvious, it's clearly a bad day to set, notwithstanding
the fact it was without the software team's agreement.
I probably don't need to complete the rest of the story.
You can probably work it out for yourself.
Suffice to say that the project was delivered in some form by the end of the year.
But it involved a lot of sacrifice.
The longer term ramifications were more severe.
Over the next six months, most of the software team left the organisation.
And relationships between the product and the tech team broke down so much that whenever
subsequent estimates were asked for, well, the software team would just over inflate
them massively.
We don't want a situation like that again.
And the product team would be suspicious about any estimate that came their way.
Software estimation is hard.
I know that.
You know that.
But your CEO doesn't necessarily know that.
They just want to know when they're going to get something.
And we go go along with it, don't we?
Because they're the CEO.
So we come up with a raft of different alternatives to try and determine the them more accurately.
For example, we might use our expert estimators.
The principal developer, or the technical lead.
We will count things, use cases, stories, features, and we were multiply them by a common
factor.
We might compare them with similar historical projects that we've done or use ranges to
encapsulate our uncertainty.
We may go with our gut feel, or we will pad the estimates or just double it to be safe.
We may use T-shirt sizing, story-pointing, and even generate some Monte Carlo simulations.
At the extreme end of the scale, there are a number of complex formulaic ways of calculating
estimates based on a series of input parameters.
This is the Cocomo model which has 20 different input parameters, such as programme capability,
process maturity, the type of language you're intending to use, and even team cohesion.
Which try these methods and what happens?
They're still wrong, and that is maybe because of Hofstadter's law.
It's out of this situation that the NoEstimates movement start, they're hard to do, impossible,
even, given the nature of the work.
We've tried many times, lots of different methods, and we still get it wrong.
If Lean methodology tells us to eliminate waste and software estimates are of no value,
the time spent trying to create them will be better spent trying to create a software
we are trying to estimate.
A colleague of mine had a team who was very diligent at creating software estimates but
inevitably at the end of some sprints, they would be out.
Cue the worst sprint mortem you could imagine.
Their product's owner was a former lawyer and wanted to dissect the reason why every
three-point story that became a five-point story was so.
So this lead developer used to spend lots of hours preparing for that meeting coming
up with all the mitigating factors.
So I've got a lot of sympathy with the no-estimates line of reasoning because of that takeaway
example, and I'm sure you've been in meetings where you've been asked to come up with that
ballpark estimate, that high-level estimate where you've got sketchy requirements.
We protest, we do them anyway.
We caveat the life out of them, but they just become a reality.
Now who loses out?
But, without estimates, project managers couldn't produce ganm and where we would be without
them?
There are times when we need to give an indication to the business on how long things are going
to take.
So they can make the relevant decisions on where to prioritise effort.
So software estimates are hard.
The no-estimates direction is tempting but is there a third way?
I believe there is.
And having been involved in these types of situations many times as a software development
manager, I've come to realise that the key ingredient to solving the conundrum of software
estimation is trust.
Sure, we must do T-shirt sizing, story points, use Spikes, and all that good stuff, but having
trust trumps all those things.
Now, trust is obviously the key to any relationship.
I think we would agree on that, it certainly is true in the relationship between tech and
product.
As I said, I'm not saying let's not do all those good things about estimation, please
don't get me wrong.
Don't go back to your product team and say, "Hey, I went to this conference and I heard
a talk about estimation and the guy said we don't need to do it any more, we need to base
it on trust, peace out, man, everything's good!"
No would be we still need to do those things but underpin it with the foundations of trust.
Okay, he says, trust, but what does that look like?
Well, I can't define what it will look like in your particular relationship but I can
suggest five things that I think can help build or maximise trust between the teams.
Firstly, focus on your sprints.
Make the commitments you can, the ones that are knowable and deliver on them.
Give quality demos.
Secondly, if you don't make your sprint commitments for whatever reason, then be transparent.
Don't hide behind text speak.
If you made a mistake or just had a shocker, call it out.
When we fail and we're open about it, it creates psychological safety which is great for our
relationship.
Thirdly, ensure your developers understand and live out the commerciality of the business.
Don't overdo things.
What do I mean by that?
I mean we need to understand that we are in a business that's there to create a profit.
Or, if we work in a not-for-profit organisation, to deliver value for others.
We don't help ourselves when we gild the lilly, when we try to write the new feature in a
funky new software just because we think it will be cool.
Fourthly, put yourselves in their shows to show empathy.
Your product team inevitably have got a number of stakeholders themselves who all want to
know when something's going to be done, and they're in a difficult position of having
to convey that information to them without having the direct influence over the team,
like you do as a lead developer.
Lastly, educate them on the complexity of software estimation.
The example - for example, use thought experiment analogies to convey how difficult it would
be.
The example I like would be how long would it take to add a cantilevered swimming pool
between the 20th and the 21st floor of the Shard?
I think that's what we are doing with our software architecture times.
I think this is one of the most important things to get right as a lead developer.
Why?
Solving the conundrum of software estimation is not merely an academic exercise, one that
makes us look good and we get better at it.
No.
It is because it clearly impacts life significant ly.
Your people.
Your people are the ones who are staying up late at night coming up with all those reasons
to apiece the product owner.
Your people are the ones who are working over weekends, over Christmas, to get a project
finished rather than spending time with their families.
It can and it does affect mental well being and relationships.
This is serious stuff.
Let's try to get better.
Thanks.