Release early and release often, but don't release broken.

I love the mantra of ‘Release early and release often’. It keeps you on your toes, keeps the project fresh and keeps things moving, but most of all, it makes you decide what’s necessary and what’s not. It helps to separate the wheat from the chaff.

Releasing early and often also gives you the opportunity to be a little experimental. A feature that took two days to complete and is a little rough around the edges as a result is much easier to drop than a feature which takes two weeks to complete and is completely refined. With the two-day feature, if it is successful, it can be built upon and end up just as refined as the two week option, but it’s less of a gamble and gives you more agility.

Taking the mantra too far can only lead to pain, in my opinion. Releasing early and often is all good and well if it’s just a little rough around the edges.. As a user, you can deal with that, right? But if it’s full of bugs and isn’t usable and degrades the user’s experience, they won’t see it as agility and good project management skills, they’ll find it frustrating and amateurish.

I won’t name names, because that’s not nice but I was trying to use something this weekend which stank of release early, release buggy. The software would’ve been great, if it only worked! Too many bugs and too many rough edges made me annoyed and in the end, made me look elsewhere for a better, more usable solution.

As with everything, there’s a happy medium to be found. People can accept the odd bug and rough edge, but if it degrades the experience too much, they’re likely to look elsewhere.

Photo by LePacheco