Just had my say in a discussion on LIDNUG group on LinkedIn. The question put for discussion was “Is it ok to cut corners to meet a deadline?”. Most of answers (or at least the way I interpreted them) say that you generally shouldn’t, but that sometimes you just might have to compromise, especially if that can be justified from business point of view. I think that from agile point of view, the reply is quite obvious. Here is what I had to say:
It’s NOT OK to cut corners, but it’s OK to cut features.
I guess that sums a great deal that agile development is all about! You do very short iterations but you do them properly (no cutting corners). Once you start with new iteration, your client can invent new, eliminate old, reprioritize all features etc. (This is what I actually mean by “cutting features”.) As it happens, most of the time the client will realize that some features are not needed, that other are, and will accept that he can live without “nice to have” as long as the core features are done right and without bugs. As a matter of fact, it is difficult (no to say impossible) to know all the features you will need right at the start of the project. So, why should you cut corners to deliver a feature you are not even sure it’s needed? This doesn’t necessarily have to do with 80-20 rule, it’s more of looking at the software as the “work in progress”. You can release the first version once you have implemented the minimum set of core features that do something useful.
Once you and the client change the mentality from “features initially put into the contract” to “real business value delivered”, you will have no need to cut corners. Switching to short iterations and having users participate in planning and accepting results of each feature had a profound effect on how my team is operating and had enabled us to really uphold the quality aspect of software.