Agile is..doing only as much as you need

This weekend I discovered what I consider to be a massive design flaw in my Mazda3. The problem that lead to this discovery is actually something that has happened a few times, and I believed it to be an electrical fault.
I was happier in that belief.

Because so much worse is the realisation that this glaring fault, this stupid, damaging, security hole is a ‘feature’!

What am I talking about? Well, it turns out that if you press and hold the unlock button on the remote, not only does it unlock the car, but it also lowers all of the windows.

Yes, all of them.

Now you might be thinking this doesn’t sound so bad. But the problem with remotes, is that they work at a distance. Say…  the distance between me inside a house and my car parked outside.
And the problem with surface buttons on something in your pocket, is the ability to accidentally press those buttons.
And so I woke after a night of rain, to be told by a friend that my car had all the windows open. And was rather wet inside.

$£%*$^&£^$£*^$!!!

This got me thinking around to how such things happen. And I can easily imagine the development process. I can consider reasons why you might want to be able to shut all windows remotely. In much the same way, I realised, I can see why I want to be able to lock the car from a distance, i.e. “Whoops I forgot to lock the car and I’m now 50 yards away”.

I suspect the feature to be able to open all the windows was a ‘freebie’.  If you’ve done all the work to allow for up, why *wouldn’t* you do both?  – it’s free.

Well I’ll tell you why not, because shutting windows is secure. I don’t mind accidentally CLOSING the windows. Opening the windows is INSECURE and I do very much mind accidentally doing so. This also made me realise that what I really want is a remote that lets me lock my car at distance, but only responds to unlock when I’m within a meter or two.

This all brings me around to why I like the AGILE development process. It helps more than ever to focus on doing what your customers/stakeholders have actually asked for and NO MORE. Do just enough to meet the needs, and only add new things if someone actually wants it.

I often find myself  telling people to note an idea as possible, but not to progress it unless someone decides there is a good reason for it. Of course developers like to implement ideas. Sometimes ‘because I can’ is all the reason one needs. But what happens is you spent time and effort developing, and then testing a feature that no one wanted, and in bad cases people actively don’t want.

The other thing I’m a big fan of, is making things configurable. If I had found out about the horrible design flaw in my car, but discovered I could disable this ‘feature’ I would not mind. I guess there maybe some people in the world that really do see a need to lower all their windows at once remotely. But the fact that it cannot be disabled just makes it worse.

There is a lesson in all this somewhere. And I like to think that if I keep evangelizing the agile process to people I might get people to learn this lesson. Don’t implement something if the only reason for doing so is ‘because we can’ –  save yourself and your business time and money and focus on what people actually want, if you don’t know precisely what people want then let them configure.  And, of course, deliver it in the order they actually want it.