“There is no single development, in either technology or management techniques, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” –Frederick P. Brooks, Jr.

Fact, building software is highly complex and very expensive. There is “no silver bullet” for how to effectively proceed through the software engineering and development process (Frederick P. Brooks). Yet, this widely agreed upon assumption is no excuse for not striving to better our software engineering practices. Just as with any other engineering discipline, software engineering will continue to mature and there will be continuous opportunities for improvement. In this post I will be making a case for developing higher quality software. I will outline some of the benefits of developing high quality software; I will describe what it means for software to be of “high quality”; and I will explain how the Scrum development methodology can be used as a framework to increase software quality.

Quality Software Is Important

“Quality is free. It’s not a gift, but it is free. What costs money are the un-quality things—all the actions that involve not doing jobs right the first time.” –Philip Crosby

Before we can set out on our journey to higher quality software, we must first understand why quality is important and what it means for software to be of “high quality.” According to Capers Jones, “High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.” (Capers Jones) In the context of software engineering, Total Cost of Ownership (TCO) consists of all the direct and indirect costs attributed to a single software application throughout its lifespan; TCO is important because it is used to determine a product’s total Return on Investment (ROI). The following are a few software development behaviors that have an impact on TCO:

• Bugs—bugs reduce a system’s value and increase its maintenance and sustainment costs;
• Code refactoring—un-refactored code makes it increasingly difficult to enhance and sustain a system;
• Automated testing—exclusion of automated tests make it difficult to determine system behaviors and capture defects. (Ken Schwaber)

Crosby, Jones, and Schwader aren’t motivated to increase software quality out of the kindness of their hearts; they are doing so to lower an application’s TCO and increase its ROI. Thus, high quality software is built with an emphasis on reducing support and maintenance costs.

Scrum and Software Quality

“I offer you Scrum, a most perplexing and paradoxical process for managing complex projects. On one hand, Scrum is disarmingly simple. The process, its practices, its artifacts, and its rules are few, straightforward, and easy to learn. On the other hand, Scrum’s simplicity can be deceptive. Scrum is not a prescriptive process; it doesn’t describe what to do in every circumstance. Scrum is used for complex work in which it is impossible to predict everything that will occur. Accordingly, Scrum simply offers a framework and a set of practices that keep everything visible. This allows Scrum’s practitioners to know exactly what’s going on and to make on-the-spot adjustments to keep the project moving toward desired goals.” –Ken Schwaber

According to Ken Schwaber, “Scrum is a tool you can use to find out what you need to do to build quality software with a better return on investment.” (Ken Schwaber) I find this statement spot-on; Scrum is merely a framework, it will not guarantee high quality software. The benefit of Scrum is its incremental approach to development—it effectively optimizes predictability and controls risk. (Ken Schwaber) There are two attributes of Scrum that, when practiced correctly, can increase software quality; the first attribute being what are called ‘Sprints’ and the second attribute being that each Sprint must end with a ‘done’ increment being achieved. In contrast to the waterfall development methodology, Sprints can improve software quality by providing the opportunity to engage customers early during development. This enables Scrum teams that have drifted off course, missing customer expectations, to quickly find their bearings and correct their heading—saving valuable time; time that may be utilized to improve quality. For Scrum to be effective, at the end of each Sprint a done increment of potentially shippable software must be achieved—this is not negotiable—in order to obtain customer feedback, the application must be functional, demonstrable, and deployable.

Scrum’s Definition of Done and Software Quality

“quality is a perceptual, conditional and somewhat subjective attribute and may be understood differently by different people.” –Wikipedia (source unknown)

We learned earlier that high quality software reduces support and maintenance costs—this is great, but how do we achieve higher quality software? We learned that Scrum is not the answer; but rather, just a framework that when used properly can improve software quality. So, how do we use Scrum to achieve a high quality done increment of potentially shippable software? I present to you “Definition of Done” (DoD). DoD is an essential step in assuring a done increment of quality software is achieved by Sprint’s end. DoD is a set of guidelines that must be satisfied by each development item in order to be referred to as done. (Ken Schwaber) Development items that are not done are not potentially shippable and may not be released. There is not a single DoD that will work for all situations; each Scrum Team must define their own DoD; and Scrum Teams are encouraged to improve software quality by enhancing their DoD prior to each Sprint. (Ken Schwaber) An example DoD might be:

• Code complete;
• Unit tests written and executed;
• Integration tested;
• Performance tested;
• Documentation complete;
• Increment approved by Product Owner. (Mayank Gupta)

The cross cutting concerns of the DoD are the responsibility of the Scrum Team to enforce. Scrum Teams that are able to produce a done increment at the end of each Sprint realize the benefits of producing high quality potentially shippable software. DoD is a means of quality assurance that can improve the consistency and quality of each done increment a Scrum Team produces.

Summary

Until I began researching these topics, I can’t say I truly understood the meaning of quality, let alone how it related to software. I maintained a “kick-the-tires” understanding; I gauged software quality the same way I perceived the quality of any other tangible good. I believed something was of high quality, if it worked, was well put together, and stood the test of time—I now know there is more to it. Writing this post taught me the meaning of quality, its importance, its economic motives, and how it is related to software. My perspective of software engineering and how I build software has shifted.