A while ago I referenced Allen Holub’s Key Note speech on #NoEstimates. One of the comments read:
I’ve been battling with timescale pressure recently, and hope to use some of these arguments to reframe the conversation.
and on asking for clarification:
In recent times I’ve found myself wary of deadlines for a whole host of reasons including:
– new urgent features/fixes which trump everything else
– small team running multiple independent projects concurrently
– training up inexperienced team on unfamiliar tech/domains
– technical challenges which we don’t have answers for yet e.g. algorithms and processes
– greenfield projects with few benchmarks as to what MVP looks like
Instead of signing up to deadlines which will be missed, I’ve been trying to promote an agile approach where we regularly review what the priorities are, with the primary goal of keeping everyone sane. However, I’ve been struggling to get this message to sink in.
Believe it or not, this kind of situation is very common in the tech industry. It’s even more uncomfortable to have to be dragged through it.
Occasionally, we have to deal with a CEO or similar that has very limited software experience. Sometimes this is advantageous, as they’re not tainted by a history of “this is how it’s always been done”. But often – the desire to know the future can often be overwhelming! Hence we end up with a hard push for (the paradoxical) reliable estimate.
The funny thing is, whether your an executive, middle manager, lead or developer, we all know that estimates are made up. That’s why they’ll factor in “contingency times”, round up estimates, promise they won’t be used against you, etc, etc. But ultimately the customer will believe them – whether they’re internal or external – and despite every assurance, they will -more often than not – be used against you (and your team).
The pressure is often subtle and unspoken, but deep down, we don’t want to risk poor salary reviews, being the weakest link, or letting the team down, so we yield and work around the clock, through lunch, arrive early, leave late, all to deliver the “definitely not going to hold it against you” estimate we reluctantly gave.
The truth is, no one’s ever done exactly the stuff we’re doing, especially if it’s greenfield but no less especially when it’s a rewrite. After all, we’re re-writing for a reason – because change is needed. Can we say precisely what side effects these many changes will yield? No. But are we going to be asked to “just give a rough estimate – some idea of how long… ” blah blah blah – you bet your house on it!
Why? Because it’s how it’s always been done – we can literally trace it back to Fred Taylor’s 1909 publication: The Principles of Scientific Management. This was made for factory workers – automatons, doing predictable, monotonous, repetitive work, over 110 years ago. It is still the industry standard, but:
IT DOES NOT APPLY TO SOFTWARE.
If software development was predictable we wouldn’t need to do it – market forces would have automated it by now. We are by definition breaking new ground, learning as we go, discovering what’s possible and at the same time, what’s not practical. We may have done similar things before, but no one knows what the differences will be now, how to predict them, what side effects they’ll produce and certainly any estimate of how long they’ll take.
NO ONE.
This will take a lot of confidence to declare though. If you’re a developer, you’ll literally find yourself calling-out the emperor for being naked – whilst everyone else is busy fawning over how beautiful those silk sleeves look.
And this can feel very daunting, and – honestly – scary.
So what do you do?
We’re told that there are urgent features coming in and they must take #1 priority. BUT this constant context switching is why everything else is being rushed out, and then later coming back in to be fixed! Breaking the focus of the other thing we were – just this once – going to try and get pure, unbroken focus on.
We’re told that they’re only a small team and having to run multiple, unconnected projects in parallel! How can anyone possibly focus in that situation?
We’re told they also have to balance all of this with training new people and learning new, unfamiliar tech – preventing focus on any single thing!
On top of all this, they need to estimate technical challenges like entirely new algorithms – which to estimate would require you to know the answer in advance. Again:
I’m going to give you an equation to solve. How long will it take?
Ahhh – but don’t worry I won’t hold you accountable for it, it’s just that I need to make business decisions that we will be accountable for, that’s all.
What!?!?
TLDR;
The answer to all of this can be summarised in one word.
Focus.
Step 1: Pick a thing to do. Discuss as a group how you can make it as small as you think it can be. Then make it smaller; because old habits die hard and we will inevitably over-complicate it, even with the best of intentions.
You will then need to get trust and buy-in for this next bit, so, pitch it as an experiment. Your reasoning being, that you’ve tried it their way and so far and it hasn’t worked yet.
Step 2: Get everyone in your team focused on that one thing. Ideally, so focused, that you only have one screen and keyboard between all of you (#mobprogramming). There will now be literally one thing to focus on for the entire team: delivering a super simple, first-pass version of that thing. Do that.
Step 3: Get feedback.
Remember ‘perfect is the enemy of good’. You’re looking for better, not perfect (make this clear) – and precisely, you’re looking to find out if what you’ve done is good enough or if – GIVEN EVERY OTHER FIRE CURRENTLY RAGING AROUND YOU – it’s still worth another round of improvement.
Each round should be counted in hours or, at most, a day – so you’ll need a laser-like focus on the absolute minimum viable product, and this takes practice and discipline.
Now, for whatever is most important given your feedback, go back to step 1. Is another round of improvement needed? Or should we be doing an all-together different thing next?
If you agreed improvement was needed, a certain point will come where it will be good enough. Particularly given the other 50 things that need attention.
TIP: Backlogs don’t help here – don’t plan you’re queue. Strictly no planning. Finish a thing (quickly, by limiting scope) and when delivered, decide what is currently most important through inclusive feedback.
Your mantra becomes:
We are one team. We work on one thing. We make it good enough. We pick up the next thing.
Now the business gets to decide what’s the next most important thing is (good luck with that btw) and before long they’ll realise that prioritisation is incredibly difficult, Hopefully, the organisation will get a first-hand experience of why prioritisation should include everyone involved in the delivery. As such you should gradually start working closer on this, simultaneously getting more autonomy on how things get done, and gaining more trust overall. Why because you will be consistently delivering results that are good.
Not perfect. Good. Because perfect is impossible, and estimates are made up.
—
I help remove stress from software development. If you’d like to get in touch, please do:
@themuradonian – nathan@nhance.io – https://nhance.io