• IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog
  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources

IT Revolution

Helping technology leaders achieve their goals through publishing, events & research.

  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog

Elements Of The First Way: And The DevOps Implications…

September 12, 2012 by Gene Kim Leave a Comment

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.

Most Recent Articles

  • The DevOps Enterprise Journal: Spring 2022
  • Learning Effectively From Incidents: The Messy Details
  • Putting the Ops in DevOps – An Infrastructure Story

Filed Under: DevOps Community Tagged With: devops, three ways, value stream

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

newsletter sign up

Topics

Tags

agile agile conversations better value sooner safer happier business business agility business leadership case study continuous delivery devops DevOps Advice Series devops case study devops enterprise forum DevOps Enterprise Summit devops handbook digital transformation dominica degrandis douglas squirrel enterprise Gene Kim incident management information technology IT jeffrey fredrick jez humble John Willis Jonathan Smart leadership lean making work visible manuel pais mark schwartz matthew skelton nicole forsgren operations Project to Product project to product tranformation seven domains of transformtion software software delivery Sooner Safer Happier teams team topologies the idealcast The Phoenix Project WaysofWorkingSeries

Recent Posts

  • The DevOps Enterprise Journal: Spring 2022
  • Learning Effectively From Incidents: The Messy Details
  • Putting the Ops in DevOps – An Infrastructure Story
  • Visualizing Team Dependencies with a Team API
  • What to Expect at DevOps Enterprise Summit Virtual – Europe 2022

Privacy Policy

Featured Book

Featured Book Image

Events

  • DevOps Enterprise Summit Virtual - Europe
    Virtual · 10 - 12 May 2022
  • DevOps Enterprise Summit US Flagship Event
    Las Vegas · October 18 - 20, 2022
  • DevOps Enterprise Summit Virtual - US
    Virtual · December 6 - 8, 2022
  • Facebook
  • LinkedIn
  • Twitter
  • YouTube
Copyright © 2022 IT Revolution. All rights reserved.
Site by Objectiv.