The importance of having a quality philosophy in the Agile environment | David Tzemach
This article reviews the main differences between internal and external quality and sees the importance of having a quality philosophy in the Agile environment.
The Differences Between Internal and External Quality
To understand the true meaning of quality, we should distinguish between internal and external quality:
External quality refers to what the customer sees when interacting with the software. An example of poor external quality is a non-intuitive user interface that demands complex navigation to use a simple function.
Internal quality refers to all issues not visible to the customer that impact the maintainability and stability of the system, such as code design and test coverage.
Which type of quality is more important? Both are important, assuming the team has the time, resources, and knowledge to attend to both. But what happens when you need to release quickly and must choose one?
There isn’t a definitive answer, as each case has advantages and disadvantages. From experience, a system with high internal quality can still be released with low external quality (we see this all the time in the software industry). However, a system with low internal quality will make it almost impossible to build high external quality. How can you build a system that relies on rotten infrastructure?
What Is a Quality Philosophy and Why Do We Need It?
As part of any development project (Agile or otherwise), the organization must determine the level of quality it expects to deliver to the market and its customers. The level of quality should be derived from the quality philosophy.
The quality philosophy is the project’s acceptable tolerance level for quality gaps (e.g., technical debt, low code coverage, etc.) and problems found following the products' release.
At either end of the quality philosophy spectrum, we have a high tolerance for poor quality and a low tolerance for poor quality.
High tolerance for poor quality - The team is expected to deliver products as early as possible regardless of the quality of the deliverables. This includes providing items with significant quality issues (e.g., Tests do not pass, multiple known bugs, etc.) and even without completed tests. This is because the quality philosophy of the organization is to beat the competition at all costs and complete the missing gaps after.
Low tolerance for poor quality – The team is expected to deliver products without compromising their quality, which is likely to be at the highest possible level. To do so, development teams reduce the number of stories they can deliver per release to create automated infrastructures, executing more tests and spending much of their time ensuring that each feature is produced with the highest quality possible.
As you can see, the organizational quality philosophy significantly affects the workflow and speed of delivery. Therefore, it must be communicated to the engineering teams, as it substantially impacts their day-to-day work. Note that even if your company has a high tolerance for poor quality, it still doesn't mean that you can deliver low-quality products to your customers. However, it does allow the team to reduce the test coverage (by an acceptable amount), take more risks and invest less in "external" quality as internal quality is non-negotiable.