A Better Breakfast with DevOps

In the Harvard Business Review article Quality Comes to City Hall, famous business and management leader W. Edwards Deming said, "our system of make-and-inspect, which if applied to making toast would be expressed: 'You burn, I'll scrape.'"

The essence of this quote is simple. If quality isn't addressed upstream, it becomes folly to correct the productivity issues downstream.

In principle, I generally agree. It is usually more cost-effective and productive to address issues before they occur.

Our current industry thinking around shift-left and security by design bear this out. Applying quality inspection and security audits after the product has been written is usually the most expensive way to deliver software.

However, we as an industry often fall short of putting all our efforts "left." And that is ok. Quality assurance processes almost always start with a "toast" of dubious preparation. Often the analysis is done well after the toast is cooked, and only slightly before it is served.

Asking questions

Even the most robust shift left quality effort usually includes a certain level of distrust of the current state of the final product. Are we, in fact, even shipping the correct thing? Is it what our customers really want?

A team that continues to ask these questions can evolve and respond.

So – I must ask: does Deming's quote always hold true in DevOps and Lean methodologies?

Adherents to Lean principles already know that there is only one constraint in the system, and prematurely optimising for any other constraint will not increase flow.

Feedback matters

In addition, delivery to the customer regardless of scraped toast allows for those critical feedback loops to be established. The entire value stream can then be viewed as an end-to-end process to determine where to best apply optimisation.

After all, can we take it for granted that scraped toast tastes any worse? Might you learn that customers prefer that type?

The greatest risk is not delivering any toast and quickly leaving your customers with an empty stomach.

Incorporating feedback

Here are four ways to incorporate customer feedback earlier in your DevOps journey:

1. Prioritise building a DevOps pipeline that ends at the customer, not just ends at deployment.

2. The most valuable metrics that you can gather are those that show business value delivered over pipeline execution.

3. Improvement to the delivery pipeline can't be appropriately targeted without active customer feedback.

4. Don’t let perfect be the enemy of good. Engage your customers early.