We have seen software development evolve from ad hoc to CMMI, to Unified Process, to Agile, to Lean, to what next. Why the evolution? Agile has become the mainstream software development method today. So what? What have we been missing? What are we searching for? In my opinion, it is the quest and delivery of a high quality product. We should strive for quality being non-negotiable. Build something without an emphasis on quality and you are building on a poor foundation that will eventually lead to collapse and result in a final product with little to no commercial or operational value.
Companies that build and sell products need to focus on a high level of quality to maintain and increase their customer base. A company venturing into a new market may be able to win over customers through marketing gimmicks, hype and such. But if the products they offer are poor in quality, all the gains will be short lived because dissatisfied customers no longer want the product. I was just reading a report about a successful company. Its responsiveness to customer's requests resulted in the company gaining a foothold in new markets, but the customers reported the lack of quality in the product to an embarrassed executive. Something needs to be done. Today, we often hear about product recalls from famous companies like Toyota - the birth place of lean development. It goes to show how the reputation of any successful company can be ruined by poor quality.
Achieving a high level of quality is the responsibility of everyone involved in product development - not just the development team (which includes testers and developers), but marketing folks and product planning folks. Yes, there are only 24 hours in a day and 7 days in a week. However, there should be time allocated and used to do the right things, provided you choose to do those things right, and that requires a change, which I discuss in this article.
1. Mindset: Quality before Feature
The traditional approach is to build a product with a set of features and then hand-off the product for testing. The testers will find bugs - some minor, some severe, and some are even show stoppers. Test results are then handed back to the developers for fixing. This cycle repeats until the testers are unable to find new bugs and the developers have reduced the number of bugs to an acceptable level. This is what I call a Feature-Before-Quality (FBQ) mind set and this is what most teams are doing.
The modern approach is instead to develop a subset of features, test them and assure the product has reached a predetermined level of quality before working on the next set of features. This is what I call a Quality-Before-Feature (QBF) approach. Features are added incrementally to an increment of a high quality product, until the product contains enough features that make it attractive/valuable to customers. This approach has a benefit because the product can be released any time due to its rich feature set and high quality. Product planning can easily change requirements for the product by deciding on a different set of features to develop. True, this is not so simple, but by having a Quality-Before-Feature (QBF) mindset, you have a chance to do so. If you were to apply a Feature-Before-Quality (FBQ) mindset, chances of effectively adapting to change is near impossible.
The key to making Quality-Before-Feature (QBF) work is simply to maintain and advance the quality of the product and to continuously improve the product development process with a keen eye on no bugs allowed.
2. Mindset: Bug is anything that Bugs You
There are developers who say, "If it works, who cares how I do it". This is just unprofessional. We need to do much better than that. We need to achieve all rounded quality for the product - there must be no bugs.
When I say no bugs, I define bugs as anything that will bug you later. Of course, if a test fails, or the program crashes, it will bug you immediately. There is no argument about that, but I go a step further to broaden the definition of what bugs