#62-Shift Left – Detecting Defects During Deployment

In this episode, I will investigate the first step in shifting left, which is to detect product defects at the time they are sold and deployed but before they are in use by the customer, and therefore cannot impact them.

Transcript

Shift Left - Detecting Defects During Deployment 

Last week I discussed how defects being discovered during product use is probably the least advantageous way for that to happen. Our first step in “shifting left” is to detect more defects when the product is being sold and deployed at a customer's site but before they begin to use its features. 

I'll start by pointing out that defect detection upon deployment is unlikely in most cases. The reason for this is that the act of deploying a product is mostly dependent on its “deploy-ability”, if you will, and that if successfully deployed a product can still contain defects that are yet to be discovered. 

There are several things that can prevent the product from being successfully deployed, however. 

I'm including in the term “deployment” the successful sale of the product. Perhaps it is not competitively priced, and therefore the sale does not happen.  It's also possible that we have missed some law or standard that prevents the sale of the product, legally. Even if the product is competitively priced and legal to deploy, it may not have the right attractive features when compared to other, competitive products. The marketplace is a highly dynamic thing, and extremely unpredictable.

As an example, the Microsoft Zune music player product was not a success. This was not because the product was poorly designed or overpriced. I owned a Zune and quite liked it. It failed because an unanticipated force in the marketplace made it unappealing to consumers. That force was the invention of the iPod which no one anticipated would be as successful a product as it was. The iPod fundamentally changed consumer expectations about their personal electronic devices. Even Apple did not predict this, which is why they later decided to rebrand many different products in their company with an initial letter “i”.

Once successfully sold, we may find barriers to the installation of the product. 

For example, we may not be able to install it on the hardware platform that is preferred by our customer because it is too tightly coupled to the platform that we developed it on.  This would actually be a flaw in the design or architecture that was settled on much earlier in the process but might not become apparent until the attempt is made to install the system.  It’s also possible that a new, more popular platform has emerged while our product was being developed.

I witnessed this very problem when I was consulting for John Deere, but I’ve seen it elsewhere since then in such varied products as videogames and automated teller machines.

Sometimes we discover at this point that our product cannot be deployed because doing so would interfere with other systems that a customer utilizes and therefore would damage their flow of business.  This may not be a problem for all customers, and so we might not discover it until we encounter one for whom it is. 

Most of these problems stem from a failure to properly analyze the marketplace and customer landscape much earlier in the process.  Often product developers do not consider these issues to be part of their purview, but if they prevent the success of the product then they are.

So next week I will investigate the next form of “shifting left”, which is defect detection during traditional testing. This is, of course, where most people expect defects to be detected, but I want to point out what some of the barriers are to that happening, and some of the costs and waste that it can create.

See you next week.