The Primacy of Quality

When you are running a software project, you will undoubtedly come under pressure to deliver more features than is possible by the agreed deadline.  At this point you realise that there are some levers you can use in a software project:

• Resourcing and personnel (bearing in mind the "Mythical Man Month")
• Time
• Features
• Quality

You feel stuck between a rock and a hard place. People will complain if the software is missing 'critical' features, or and there may be penalties associated with missing the deadline.

So you start to review your process and you notice that there is a chunk of time allocated to any of the following:

• Creating and maintaining automated tests
• Creating and maintaining unit tests
• Maintaining continuous integration
• Code reviews and other quality processes

All things that are quite 'invisible' to your client or sponsor, things that seem like they don't achieve a lot.  The temptation comes, quite strongly, to drop some, or all of these, justifying it with "the team are professionals", or "any issues will be found in testing and UAT".

I do not underestimate the strength of the temptation, or the weight of the pressure.  But here is the thing:

• People will forget a feature that missed the cut
• People will forgive a missed deadline
• People will NEVER forget or forgive a buggy software delivery

Delivering defect ridden software costs far more in terms of time, money, lost goodwill, lost confidence and flow-on effects on other projects.  So bite the bullet, and make the tough call: renegotiate the feature-set or the timeline.  Sound like bad advice?  Believe me, you will thank me in the long run.

This is one of the main reasons I like agile, and particularly SCRUM.  Quality and resourcing are fixed, sprints are scheduled in a consistent manner, and the features are delivered according to the clients priorities.  Of course, this does not guarantee a feature-set by a particular date, this can make traditional project managers freak out a bit.  But then, I would argue that under a more traditional approach, there is no real guarantee that all agreed features will be delivered anyway.