Elements Of The First Way: And The DevOps Implications…

In a previous blog post on “The Three Ways: The Principles Underpinning DevOps”, I wrote the underpinning principles in which all the DevOps patterns can be derived from.  They describe the values and philosophies that frame the processes, procedures, practices, as well as the prescriptive steps.

In this post, I’m going to describe some of the elements of the First Way, which will allude to some of the DevOps patterns that result from its application.

 

The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).

Elements of the First Way requires the following:

• Understand the flow of work:In the IT value stream, work is typically created with the description of features needed by the business and ends with the stable, secure and reliable delivery of services being delivered to the customer.
  However, work can also be created by QA as a defect, in IT Operations as an incident or to support a planned deployment, in Infosec to support a compliance requirement, and so forth.Regardless of where the work originates, as in any value stream, the flow of work should only go in one direction: forwards. Work moving backwards, or even standing still, is almost always indicative of problems that need to be solved, and will span people, process and technology.
• Always seek to increase flow:  The goal is to maximize the flow of work through the entire system, from beginning to end.  Entire communities of practice have been developed to enable this, including Theory of Constraints, Lean and the Toyota Production System, Six Sigma and so forth.The tools and techniques they prescribe include elevation of bottlenecks, reduction of work in process, throttling release of work to match the pace of customer demand, reduction of batch sizes, elimination of waste, management and smoothing of variation, elimination of workforce overburden.
• Never unconsciously pass known defects downstream: In order to maximize flow and minimize rework, everyone must focus on creating “quality at the source.” In the ideal, a task is only completed once, including the point where the work originated and at all downstream work centers.This requires making rework visible, as rework must eventually be seen and recognized by the originator of the defect.  When originators of defects that cause rework don’t see the consequences of their actions, not only is it likely to recur, but any fixes are unlikely to prevent future occurrences.
• Never allow local optimization to create global degradation: Creating local efficiencies is important, but it should never jeopardize the achievement of the global goals or prevent customers from getting what they need.Dr. Eliyahu Goldratt described the devastating consequences of the destructive quest for local efficiencies in the Theory of Constraints body of knowledge.Long before the conflict between Development and IT Operations, he pointed to the cultural and measurement conflict and measurement between Sales and Manufacturing as one of the root causes for poor manufacturing plant performance.

  This type of tribal warfare happens most often between organizations (e.g., Development vs. IT Operations, Sales vs. Manufacturing, etc.), but also happens frequently within organizations (e.g., developers vs. QA, release management vs. production, infosec vs. everyone else, etc.).

• Achieve profound understanding of the system:Now more than ever, it is required to achieve what Deming described as “appreciation of the system.”  This is a prerequisite to understand cause and effect, make informed and competent decisions, especially since not everything can be tested.Achieving this profound understanding requires understanding the business goals, how value is delivered, the people, processes and technologies relied upon in order to deliver it, what could go wrong, and the controls required to mitigate those risks.

  The COSO cube describes the four objectives that every organization has: strategy, accurate financial reporting, compliance with laws and regulations, and operations.  In most modern organizations, all of these objectives are partially or wholly reliant upon the IT value stream, and decisions made without understanding the four organizational context is likely to be suboptimized.