My notes from the DevOps Handbook

by Gene Kim, Jez Humble, Patrick Debois, John Willis

The First Way: The Principles of Flow

Optimize for the global goal instead of local goals like feature completion rates, test/fix ratios and Ops availability.

How to increase flow:

Our goals is to decrease the amount of time required for changes to be deployed into production and increase the reliability and quality of those services.

In technology value stream the work is invisible unlike in manufacturing because there the work has physical form.

In technology motion of the work is done by re-assigning the ticket downwards. But this also leads to work bouncing endlessly between teams due to incomplete information.

Work is only done when it is running in production delivering value to the customer.

Limit Work in Process

Controlling queue size is an extremely powerful management tool, as it is one of the few indicators of lead time - with most items, we don't know how long it will take until it's actually completed.

Limiting WIP makes it easier to see problems that prevent completion of work. It's better to find out what is causing of our work to come and help fixing it.

Multitasking comes from being assigned to multiple projects and prioritization problems.

Stop starting, start finishing.

Reduce batch sizes

Reduce the number of handoffs

Continually identify and elevate constraints

In any value stream there is one direction of flow and only one constraint.

Any improvement not made at that constraint is an illusion.

If we improve the workflow before the constraint, the work will just pile up.

If we improve the workflow after the constraint, work centers after will be starved.

Five focusing steps

  1. identify the system's constraint
  2. Decide how to exploit the constraint.
  3. Subordinate everything else to the above decisions.
  4. Elevate the system's constraint.
  5. After breaking the constraint, go back to the first point.

Typical DevOps constraint progression

After all these, the constraints have been broken, our constraint will likely be development or the product owners. That's a good place to have a constraint, the goal is to maximize developer productivity.

When the constraint is in development or product owners, we are only limited by the amount of good business hypotheses we create and ability to turn them into code.