More often than not, software projects end up with pretty arbitrary deadlines. We’ve all had a version of this conversation:
Sometimes you don’t even get to have the conversation, you just get a date from the manager. It’s very frustrating, but try to put yourself in their shoes.
It must be really baffling for managers why exactly it is so hard to get delivery teams to commit to dates, estimate how long it will take them to deliver features and generally predict timelines before starting the work. Surely when you know what you’re building, you can tell how long it will take!
I think it’s because “building” software is fundamentally the wrong word. It suggests the majority of effort is spent on production, where in reality it’s exploring and defining the problem at hand.
This is a blog for product owners, product managers and really entire organisations they represent, to help them understand what they ask teams to do and why it doesn’t work.
When building a house, you draw up a plan, decide where to put walls, what floors and wall decorations to use, what materials to build from, and put all of that on paper.
This takes some time but it’s generally something that takes a few days, then you have a meeting, agree and you have a plan. Having the plan and having built houses before, you can estimate the time it will take pretty confidently. It’s a known problem, it’s just a matter of executing the plan.
Software is not “built” in this sense. You don’t hear mathematicians saying they are building a proof. They are trying to “find” a proof. Writing software is similar. A much better metaphor would be searching for certain objects in a house that somebody has lived in.
Imagine us standing in front of an average house. You’ve seen similar houses before. Now I will give you a list of things – a toy car, a frying pan, a shoe, a set of keys, etc. – to find in the house and ask you how long it will take you to find them. And I will tell you I expect you to find all of them and stay within about 10% of the original estimate you gave me.
If you searched houses before, you can probably give an educated guess – it’s unlikely to take you weeks to find all the things and you can be done as soon as an hour from now. But you never know. And you probably feel quite uncomfortable about me holding you to your wild guess.
Finding things in houses depends on many things. What is the internal structure of the house? Where are the different rooms? What’s in them? Is it all neat and organised, or is it a huge mess? Are some of the rooms locked? What if there is a vicious dog in this house that you need to get sausages for first? All of that can have a huge effect.
Now, if I give you my list and walk away, then come back at the end of the time I gave you, I will most likely find that even if you did find all of the things I asked you for, some of them are not the ones I wanted. I wanted a red toy car, not a blue one and the keys you found are for the shed, I actually wanted car keys.
When the deadline gets near and you’re still missing half of the things and tell me, as a manager, my typical response will be: do you need more people to help with the search? And to some extent, it may help.
But it will take you quite a while to explain to them what you’re looking for and where you’ve already searched and show them where they can be useful. And at some point it won’t help to add more people, you will just trip over each other frantically searching the house and spend more time organising yourselves than looking for things.
So at the end of this, I’ll end up with random things from my list missing and a whole lot of things that I didn’t really want. This sounds completely insane when it comes to searching houses, but these exact things happen in software projects regularly.
The list of things, of course, is our backlog – the list of features we want delivered. I am the Product Owner and you are the team responsible to deliver them. So how do we do this better?
First of all, I should be able to tell you which things I need the most - give you a rough order in which to look for them. This should really be a conversation - I know my priorities, but it probably makes sense to look for bathroom-related items together and you may have other tips since you searched houses before.
It would also be much better if I stayed around to check on things you found so that both of us know right away in case they are not the ones I wanted. I can also ask for more things if I realise I wanted them and change the priority of the ones I already got, rather than trying to nail this upfront.
Even better, I can get involved and help you look in all the ways I can because I likely know some things about this particular house. And if you find a problem – a locked room for instance – I may have the key for it.
And secondly, while up-front, you had no clue how long it will take to find the things, as you’re searching the house and finding things, two things happen:
The latter gives us a good ability to forecast how long the total of things will take to find using a formula called Little’s Law. This is what we use to forecast dates for projects in Red Badger.
I admit saying product managers is a bit personal. I really mean entire organisations they represent to the team. So if you happen to be one, you are under pressure from your boss(es) and you can’t do anything about it, I understand. But this can hopefully help start a conversation.
If you think about writing software as searching a house instead of building it, you realise how silly the typical approach to the problem is. This isn’t executing a plan, it’s precisely defining a problem and finding the solution.
So stop trying to plan everything ahead, stop asking teams for estimates they can’t reasonably give and instead get involved, measure and forecast. And most of all, talk to the delivery team and plan together. You’ll deliver value earlier, more in line with the customer needs and on time.