A 3 Step Process to Quality

In today’s digitally charged environment, executives leading software development companies consistently walk a tightrope as they balance two very different interpretations of the word, “quality.” Users’ perception of quality focuses on software that meets business requirements, while development teams concentrate on building programs and applications that satisfy product and system requirements. These diametrically opposed perspectives put software executives in the crosshairs of a heated debate as both sides attempt to evaluate quality.

In reality, business requirements spring from the minds of customers and stakeholders who seek a software solution to a conceptual business challenge. Business requirements, which refer to the “what” of software development, do not translate smoothly into product requirements. In most, if not all, cases, several technology-based solutions can resolve the stated business problem. To select the most technically appropriate and efficient path to resolution, business requirements must be broken down into detailed capabilities, or “hows,” that align with business needs. The tightness of that alignment produces value for the end user customer. Loosely aligned technical capabilities are seen as less valuable by customers, often eroding the software’s price point and damaging the development company’s reputation.

To protect the bottom line and reputation of a software development operations, company executives can take a three-pronged approach to extend quality assurance across the entire development process. This three-step methodology, which embraces a universal definition of quality as contrasted to value, incorporates best practices associated with a “right the first time” development approach, and calls for a cultural shift to reward the early identification and resolution of issues, is particularly relevant in today’s fast-paced marketplace.

First: define quality, value

For software company executives navigating this tightrope of conflicting expectations, it would be useful to distinguish between the concept of quality and its value in the marketplace. Conceptually, quality is a measurable outcome of development. The amount of quality associated with any software development project is constrained by available resources and the business priorities of a software development company.

One approach to evaluating software quality uses three dimensions:

1. Quality of design – the functions, capabilities and performance levels required by stakeholders.
2. Quality of conformance – how a software product conforms to design, leverages appropriate standards and is completed on time and on budget.
3. Quality of performance – how the software functions post-delivery, especially as it meets user needs, functions as intended, manages its workload, and is supported and maintained over time.

While most customers will agree that some degree of quality is a baseline expectation, it is critical to understand that a high degree of quality may or may not be perceived as valuable in the marketplace. Customers perceive quality as driving value, and value is relative when compared to the software’s cost. For example, a customer’s limited budget can eliminate a high-value software solution from consideration when company finds a lower quality product acceptable because of its price.

Second: Implement ‘fail fast’

In the digital world, customer expectations change on a dime, which can force development teams to pivot frequently. This rapidly changing environment, which has increased pressure on development companies to deliver software faster and at more competitive price points, calls for a new approach such as “fail fast” and “continuous integration.” However, misdirected emphasis has muddied the perception and value of the widely held fail fast principle. More than a few people place importance on the first word, “fail,” when it’s the second that matters. The success of a failing fast development initiative hinges on identifying issues, bugs and errors early in development, the sooner the better.

To support failing fast, taking a “continuous integration” approach can help software development companies increase quality and keep costs in line. In this agile development practice, developers integrate their current work into a shared depository several times each day. Automated builds verify each integration, flagging problems and assuring immediate correction. As a result, the software stabilizes at a faster rate.

Additionally, many software development companies share software in development with intended users at regular intervals in development. For example, presenting in-development software to users after major agile iterations can be another way to implement the fail fast approach. These frequent releases to end users brings defects to the surface faster than waiting until the development team is deep into the project to find issues.

Three: Shift culture to reward early detection, correction

Often, implementing a fail fast approach requires a culture shift in the software development organization. The importance of this cultural shift cannot be overemphasized. In the fail fast environment, quality assurance spans the entire development process rather than being an exercise that takes place at the end of development. When developers understand that identifying and resolving bugs early in the development cycle is rewarded, improves productivity, boosts quality and saves money, the organizational emphasis continuous improvement will begin to resonate.

In the digital environment, customer expectations change frequently, and development teams must pivot quickly to maintain the tight alignment between technical capabilities and business requirements. Applying the fail fast and continuous improvement tenets to the software development process can increase the velocity of response to evolving customer requirements.