DevOps Culture - The Practice of Cloud System Administration - page 176

ceed. When all feedback is brought to the surface, then we have the most informa-
tion available to improve a process.
• Embed knowledge where it is needed. Specialized knowledge such as configura-
tion information or business requirements is “embedded” in the process through
the use of appropriate documentation and managed via source code control. As
you move from left to right in the process, the details of what is needed are avail-
able at every stage and do not require going outside of the loop to acquire them.
8.2.3 The Third Way: Continual Experimentation and Learning
The third way involves creating a culture where everyone is encouraged to try new things.
This is a requirement for innovation to happen. In the third way, everyone understands two
things: (1) that we learn from the failures that happen when we experiment and take risks
and (2) that to master a skill requires repetition and practice.
In our software release example this means:
• Rituals are created that reward risk taking. Trying new things, even when the
new thing fails, is rewarded at review time if valuable lessons were learned.
• Management allocates time for projects that improve the system. The backlog
of “technical debt” is considered important. Resources are allocated to fix the bugs
filed when feedback is amplified. Mistakes are not repeated.
• Faults are introduced into the system to increase resilience. Fire drills (dis-
cussed in Chapter 15 ) intentionally take down machines or networks to make sure
redundant systems kick in.
• You try “crazy” or audacious things. For example, you might try to get the flow
time from one week down to one day.
When a team can identify its “value streams” (the processes that the business depends on)
andapplytheThreeWaysofDevOpstothem,theprocessesdon'tjustgetbetter—thecom-
pany also values the IT team more.
8.2.4 Small Batches Are Better
Another principle of DevOps is that small batches are better.
Smallbatchesmeansdoingalotofsmallreleaseswithafewfeaturesratherthanasmall
number of large releases with lots of features. It's very risky to do large, infrequent re-
leases. The abundance of new features makes it difficult to home in on bugs in the code.
Features may interfere with each other, creating new bugs. To lower overall risk, it's better
to do many small releases containing only a few features each.