Is quicker always better

I will start this post from a note: we are not talking here about producing cheap goods with low quality when the cheaper or faster production always means worse. Here we consider our nowadays world when we try to release a software to the market as soon as possible using agile and other methods that will not require compromising the product quality.

First of all, rushing sometimes means that you are constantly changing the release date. The traditional software development process will go through certain well-defined stages and normally you do see the product in more details on later stages, so you could discover some logical/design mistakes that will require certain redesigns and so will mean some more days for development. People hate constant changes of dates. The nature of mankind demands stability around to apply experience and make the future more predictable. Therefore neither customers nor in-house people (consultant, marketing, testers etc) will like such uncertainty and will not probably be happy if you offer your product one week early in the end of ends.

Thereafter, the early cut of project mandays could mean that you don’t have those anymore for future improvements especially if new release dates are promised to the management. Although the statement is quite elementary “you cut + you don’t have those days any more” it is not simple to understand for many people. They will argue that it is what actually we want to do cutting days since we think that the required functionality development will not require those. The real pattern is the following:
At some stage some kind problem will be discovered. My experience shows that it will occur with 200% probability - i.e. there will be at least 2 such problems in each project. A problem can be, for example, an inconsistency in the project design, a technical problem, a performance problem and so forth.
A typical reaction will be: OK, we don’t have any more time to solve the problem, so let’s adopt a workaround which we developed in a time-period we had. Notice that usually everybody is fine to do such decisions: there is a belief that it can be solved in the next release. In reality it rarely happens. Usually you will find that customers are not complaining and designers will say that there are much more important features to do. Unfortunately it will lead to a product, which is hard to develop (as there are a lot of temporally solutions) and sell (customers doesn’t complain – they just switch to something else or doesn’t select it considering which product to buy). So don't rely on a belief that you can improve software in the future, do it now and think twice cutting resources.

And of course you have no time to accommodate any better ideas or design you can come with somewhere in the final stage.

Sometimes the cut of dates is driven by testers who report that they can test a certain area by a certain date. But are they sure that developers will be able to solve all found problems by that date? They are not interested! So, the decrease of the production cycle should be agreed with all team members. Sometimes discovered problems are quite complex. In addition consider performance requirement that could arise during the testing or acceptance face.

Let’s finally talk about uncertainties that exist in any project. It is always possible that even during such relatively short period as is offered by agile and other iterative development methodologies, a re-prioritisation could happen including into the project more/other features. Have you participated in a project, where this never happened? May be if you are the in-house developer, but unlikely otherwise.

Concluding all previously said I would like not recommend rushing in cutting project mandays since faster is not always better.