#61-Shift Left – Detecting Defects During Product Usage

The next series of podcasts will examine the concept of shift left, which deals with the way we determine and remediate defects in our product.  This week I will start with the notions of detecting these defects when the product is being used.

Transcript

Shift Left – Detecting Defects During Product Usage

Last week I introduced the notion of “shift left”. 

I began by examining the phases in product development, whether it is done in a waterfall or agile fashion. Just to remind you those phases were: planning, design, implementation, integration, testing, deployment, and usage. This is just meant to be a typical set of development phases, yours may well vary in some ways. But it's a reasonable view. 

What I want to do now is to start at the far right and work my way backward, explaining in each case how shifting to the left can create advantages for the organization, the product, the team, and the customers we serve. 

Arguably the worst time to uncover a defect in a product is when the product is being used. 

First of all, usage implies that the defect is detected by an end user, a customer. This may mean that the customer's business has been damaged by the defect. At the very least the reputation of your product, your organization, your team, or yourself may be damaged. 

This of course presupposes that the customer who encountered the defect will report this back to you in some fashion. That may not happen. They may simply be suffering with or working around the defect because they don't feel there is any advantage to them to report it back to you. That doesn't mean they won't tell anyone about the defect!  It's possible they're telling lots of other potential customers who are now being warned away from your product, and the worst part is that you don't even know it's going on.  You can’t fix a problem you’re unaware of.

If they do report the defect to you this will likely be after a non-trivial amount of time has passed since you worked on it. So the process of detecting the source of the defect will take much longer than it otherwise would, which causes delays and waste. Also, the remediation of a defect will consume the resources of the organization, impeding its ability to capitalize on opportunities, insights, and to deal with competitive threats. 

Furthermore, a defect reported from the field does not indicate when that defect was introduced into the product in the first place. Did we miss something during the analysis step in our planning phase? Was the design itself faulty? Were mistakes made in implementation of that design? Is this an integration bug? Testing itself can introduce defects into the system if it is not done properly. And perhaps it was ultimately inaccurately deployed. Because we do not know where to look, then remediation may involve many different parts of our organization, all of which will be distracted from new work. 

An agile process can improve this somewhat because we do not wait until the entire product is complete before customers have a chance to validate it. That means that we have a much better idea of where to look for the defect, but still it will create waste and may damage our reputation.

So, there are many advantages to the notion of detecting the defect before it becomes deployed. An immediate shift to the left would mean that we would detect those defects as part of the deployment process. 

I'll examine that next week.