I was having a friendly grumble on twitter with @dunc_smith about things that people don’t understand when it comes to delivering software. My comment was that minimum is the least understood word in IT. I have felt this way for ages, but somehow writing it down and firing it off really brought home to me how true it is.
I frequently work with teams that are struggling to plan properly. We work through the whole concept of Minimum Marketable Feature and Minimum Viable Product and people get it – for some it’s a light-bulb moment, for some it is straightforward common sense.
However, the thing that always surprises me is what happens when I ask the teams “What is the smallest, simplest most basic thing you could build that would make sense to look at – that someone could test?” This usually starts a heated discussion, with two opposing sides developing. On one side you have people who try to go for the minimum product as a first effort and on the other side you get the people who keep trying to squeeze ‘just one more’ feature in, as if people feel that minimum is too small.
Anyway, the case for minimum is quite simple. The quicker you can get actionable feedback on something, the more likely it is to end up being what you want. To get quick feedback, on something, it will need to be simple. If it is simple, then you have lowered the risk of starting it to begin with – because if it turns out to be wrong then you’ve not blown a load of cash on it. You can recover, inspect and adapt.
The obstacle seems to be that most people have the belief that if you don’t get all you can now, you will never get anything – and it is this ‘feature greed’ that is their undoing.
IT is littered with the carcasses of large projects that have failed at great expense. This is because they bit off more than they could chew. We need to remember the old saying: “How do you eat an Elephant? One bite at a time” And then learn to take bite-sized chunks.
