Have you ever worked on a project where you thought your software was great and your managers didn’t? When that occurs, the team feels demoralized. “What did we do wrong? We thought we delivered what our customers (or managers) wanted. Why don’t they like the software?”
We often think of software quality in terms such as “fit foruse,” “exceeds expectations,” or even “we’ll know it when we see it.” However, I find it more interesting to think about Gerald Weinberg’s definition of quality:
Quality is value to some person.
You have many someones investested in a software development project: customers, managers, the project team, and possibly other people across your organization. For example, if you have a help desk or a support department, those people might judge your product quality differently than you do as a developer or manager. Let’s consider the different aspects of quality and the different things stakeholders care about.
Consider All Aspects of Quality
Quality is more than limiting or eliminating defects in your software. Quality also includes the software’s feature set, when the software feature set will be available to customers (release date), and project cost. For some organizations quality includes increasing the knowledge and skills of team members as they complete the project.
As developers, you might focus on the feature set as the mostimportant aspect of quality assessment. You might think an incomplete feature deserves top priority. But often, conversations with customers or managers (e.g., product owners, project managers) on this issue indicate a different set of priorities:
Product Owner: “We need the product to release in two weeks.”
Developer: “Feature XYZ isn’t done.”
Product Owner: “I don’t care. We have to meet the release date.”
The release date is a big part of the quality definition for productowners and their customers.
I like to think about constraints, drivers, and f loats when I think about what quality means to my project. The organization sets the constraints: release cost, project team, and project environment. We have all worked on projects where the original “constraints” were not, in fact, constraints at all. Depending on what’s important to management, the release cost can increase or the project team can grow or change.
The customers care about the final product’s release date (when they will receive their software), the set of features (what is included in the software), and defect levels (how well the software features operate upon product delivery). Your priorities should match theirs, and if you run out of time, sometimes you may descope the feature set or increase the expected defect levels. The point is, you need to know what quality really means for your project.
I like to provide project sponsors with options and clarify expectations at the beginning of a project. “If we’re three weeks before the release date, and we’re still finishing feature development, and we have more defects than we planned on having, where should we focus our attention?” I lay out the options clearly:
A. Finish the features
B. Fix the defects
C. Release on time, as-is
D. Stay within the budget, regardless of what you do
I tell the sponsors, “you can only choose one of these.” This way, I force the sponsor to decide what is truly driving the project. If you know what your sponsor wants, in order of preference, you can make informed decisions throughout the project to deliver the quality the sponsor wants.
Some sponsors say, “I want it all. It’s all #1.” But they can’t have all of these aspects driving the project. While a choice has to be made, let them know that all of their criteria will be recognized in the order that they are ranked. Each aspect of the project, and it’s priority, defines this project’s quality.
What Do Your Customers Require for Product Quality?
If you constantly work under time constraints, you might thinkthat providing a good product on time is the best definition of quality. Not everyone wants something fast. One useful perspective on quality is to think about your product’s life span and when certain customers may adopt of your product.
Quality Perspectives Across a Product’s Lifecycle (from Manage It! Your Guide to Modern, Pragmatic Project Management)
If you have a product that solves a specific problem or small set of problems for the early market, you will have just a few customers, labelled in the Quality Perspectives chart as Technology Enthusiasts, who will expect a fast release. As you progress in the early market to the Visionaries, you will have more customers. The Visionaries want you to solve their problems, and their problems are all over the place. If you’ve ever played “feature leapfrog” with a competitor, you know this problem. This group still wants specific feature sets, but they care more about the speed of release than the Technology Enthusiast.
To hit the mainstream, you have to cross the “chasm” between Visionaries and Pragmatists. Many small companies never reach the mainstream because they don’t create enough features to engage amainstream market, they release products with too many defects, and/or they release at the wrong time, so they don’t capture their potential customers.
Once your product hits the mainstream, things change. Your customers don’t necessarily want more features. They want the features you produce to work. Release time is still important, but not as important as making sure the features work.
The later in the market timeline you are, the less your customers care about the speed of release. Now the priority is on low defects—quality is not assumed here. You have to prove yourself each and every release. These later customers also care that you solve their problems without introducing more.
Although this product timeline can be helpful, you still can’t assume it will tell you exactly what quality means to your customers. You may end up having all five types of customers in the chart, regardless of where your product is in its life span, and you’ll have to choose which customers to satisfy first, second, third, etc. (and you may never get around to satisfying some customers).
I have worked on projects for which the release date was the sole priority (time to release). I’ve worked on projects that required we fix outstanding problems while avoiding the introduction of new problems (low defects). I’ve also been on projects where we had to make sure a few new scenarios worked well in order to meet a specific release date (low defects followed by time to release).
Each project is unique. If you know what your customers find valuable, you will be more successful.
What Your Managers Find Valuable
Managers care about revenue, customer retention/acquisition, and user experience. Even if you are an internal IT organization, managers care about whether your products allow your coworkers to do their jobs better or faster (which affects revenue and customer acquisition). If your coworkers (your customers in this case) don’t enjoy working with the system, and if you don’t make installation and upgrades/rollbacks easy, the system won’t be used.
If you need to talk management about the quality of your software, plan to frame the conversation around revenue and user experience, as well as any other requirements.
Quality is Unique to Your Project
Quality is not one size fits all. Sure, you can work to reduce technical debt, or not create more, as you work; agile approaches can help you do this. However, you should also identify what’s driving your project to create a quality experience. Although you may want to add more features and push back the release date, that might not be the primary quality metric for your customers. Once you know what’s driving your project, you can decide how to organize the project and decide which technical practices will best enhance product quality.
For best practices on writing, testing, and monitoring quality code, get your free copy of the DZone Guide to Code Quality and Software Agility!