Anti-Pattern #2: Make Customers Wait

The full title of this anti-pattern is "Make customers wait until they can all be satisfied simultaneously", and it doesn't really need much more explanation than that at first glance. This is rather related to "All projects equally late" in some ways, as it's a lack of focus and a failure to prioritise that underlies the problem.

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 is (as there so often should be) some numbers to crunch. Don't worry about being exact, but make sure you choose a fidelity that will give you some decision making clarity by looking at the return on investment. If you're close to release, then the ROI should be easy to figure out; and you can then make an estimate of what it will change to if you do more work and make a second release. Compare the figures for one delayed release and two staged releases and see what they say to you. I really like doing rough ROI to force these issues, as it always bears out the very simple message that delaying earning costs a lot more than you might think! (If this isn't happening for you, then you've forgotten to discount future earnings: use at least 5% per year, but 10% is more realistic - that's about 0.8% per month). You have to really make earnings change up a gear to justify squandering income now for a slightly increased income later, and this is exacerbated by spending more on development and testing.

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.