My notes from the DevOps Handbook

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

The First Way: The Principles of Flow

• Flow from Dev to Ops
• From business to customers
• deliver value to customers quickly

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

How to increase flow:

• reduce batch sizes
• reduce intervals of work
• build quality in
• make the work visible

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

• in technology work is much more dynamic
• demands of many different stakeholders
• urgent work coming through every communication channel
• disrupting technology workers is easy because it is invisible to everyone but the impact is greater than in manufacturing
• reduce multitasking by limiting work in progress in each kanban column
• all work must be made visible through cards/tickets

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

• thus reduce the number of changeovers
• large batches cause:
• more work in progress
• high variability of flow
• long lead time and bad quality
• continually shrink batch sizes
• theoretical WIP limit of 1
• small batches lead to:
• faster lead times
• less rework
• faster detection of problems
• less work in progress

Reduce the number of handoffs

• each handoff step loses knowledge
• this can lead to losing the context of the problem being solved
• in order to do this
• automate significant portions of work
• reorganize teams so they themselves deliver value to customers

Continually identify and elevate constraints

• improve capacity of work

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

• Environment creation - on-demand and self-serviced
• Code deployment - automate deployments, make it self-serviced
• Test setup and run - automatic tests, fast and parallel
• Overly tight architecture - create a loosely coupled architecture so that changes can be done safely

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.