We are terrible at quantifying and understanding risk. More often than not, we err on the side of positive outcomes, especially if we think something is pretty likely to happen. You can explore this deeply in the classic Thinking, Fast and Slow, but today we’ll look at risk vs optimism in software development planning.
If something is complex, novel or collaborative, then it’s really hard to plan, with software, it’s all three! Previously we’ve looked at the reasons why we use agile methods, and why launching early is important to the creative endeavour, and why “When” is a bad question. Now we’ll bring some number to the party. Exciting!
Sometimes we need to hit a particular date or milestone, usually when there’s an external requirement (think a new law coming in to force, or an immovable date like Christmas). How can we understand the risk we are facing, and also report them out accurately?
Optimism is not our friend in these circumstances. There are a number of ways to be optimistic when planning against these fixed dates, here are the top three:
- This is an easy problem to solve
- We’ll get faster as we go
- Nothing unexpected will happen
A new or naïve planner will come up against all of these, but might not recognise them. They will look at the requirements, split them up, estimate them and slot them into your preferred timeboxes. Almost certainly this means your plan will slip and you’ll miss your target.
Imagine that you hit sprint commitments 90% of the time. That’s pretty good! However, that means within five sprints, you have more than 40% chance of missing a commitment. As soon as you miss one, you are playing catch-up, and experience shows us that never actually happens.
Being right 90% of the time is also massively unlikely, but it’s a nice round number that’s pretty comforting in planning world. If you only really are spot on 75% of the time, then after 5 sprints you’ll have missed at least once move than 76% of the time!
To beat this optimism, put some evidence into your thinking. Track two things. First off, how hard you thought something would be at the start. Second, the end-to-end time to complete it (which includes everything to get it really and truly done and out into the world).
Generally, we’ll perform about as well as we did last time. Maybe a little better, possibly a bit worse, but tracking these two numbers mean you’ll be able to get good confidence in how often you hit those commitments.
Next up, grab some contingency. If you have a fixed date, then aiming at that time is the high risk approach. Remember, you are super likely to slip up, even if you are right 90% of the time.
Assuming that 90% figure, if you extend that five sprint timeline to six, then the chance that you miss commitments twice is only 18%. That’s over 80% confidence of success, much better than your 60% working to 5 sprints exactly.
These calculations can be performed with the help of a binomial distribution. It’s all pretty theoretical, but it can help to shed some light on unexpected outcomes.
Finally, do the things that are most important first. That’s a key part of success in the agile world, and it still helps even with the fixed commitment.
It’s not always the hardest things, but the ones that matter most. If there’s a feature you simply must have or else risk breaking the law, then do that first. If it’s nice to have, or a general solution to the problem, or something else that’s not vital, put it to the back of the queue.
This means that even if you do end up missing more than expected, at least you’ve done the biggest bits first. When a deadline is looming and you’ve got the ‘Musts’ done, then the ‘Maybe’ quite often just falls by the wayside.
These techniques help you overcome optimism, plan better, be more agile and keep more of the commitments you make.
Measure the difference between your estimates and the actual time taken, grab contingency and do the important things first!