But put simply, this anti-behaviour is turning down an opportunity to deliver finished software now, because there are fixes or features required to satisfy some users left to do. I stress some users, as I don't necessarily mean the minority: I believe that it should be possible to release software, or software upgrades, explicitly for one group of users only, with the clear intention of releasing something else for other groups on another date.
You might ask yourself - as I have - why very bright people; with the best interests of the users at heart; will actively force a large number, even a majority of users to wait for features or fixes that are ready genuinely ready to go and can be delivered right now.
Pop psychology tells us that we are, for the most part, "loss averse"; that is that the loss of something hurts more (about twice as much apparently), than the gaining of something of equal value pleases. I believe that this sort of motivation, when left unchecked, leads to making customers wait, because we are more sensitive to the things we haven't finished than those that we have. Perhaps by a factor of two.
However, when I really look at the situations where I've actually seen this happen (and those where it didn't, but a good understanding of this anti-pattern averted the mistake), it is also "real" costs that affect the decision to wait, as well as the psychological ones. For instance, releasing software now with features to satisfy the vast majority of your customers, and following with another release in a few months when you've finished off the more specialised features could actually cost you in testing effort and other deployment activities. Is this avoidable? Yes, of course it is if your testing doesn't cost much! And if you're operating in an Agile manner - and by that I mean you have developed using Agile principles like low-dependency architecture and a high unit testing coverage - you shouldn't have to pay the cost twice over.
The ways in which I've tried to avoid this anti-pattern from having a bad effect on projects come down to focussing on the real project goals:
- Remind yourself of what you set out to do and try to state it in one sentence
- Objectively decide whether you've really passed the bar on the major project release criteria
- Stop worrying about the few people that won't be happy and remember the central majority of people you're trying to satisfy: you'll always have someone unhappy with a release because you haven't done exactly what they want, so stop chasing perfection, and deliver excellence
There's a related behaviour, which I'm adding to the end of this series called "Make it all things to all people", that is an extended version of this story, but happens much earlier in the development process, and kills projects before they are even off the drawing board.
Post a Comment