Risk, Process, and Balance
##########################
:date: 2015-01-10 22:35
:author: Russell Ballestrini
:tags: DevOps, Opinion
:slug: risk-process-and-balance
:status: published

The operations of a company will have intrinsic risk. Risk occurs each
time we decide to take an action or an inaction. This means that
anything we choose to do, or not do, has associated risk.

An organization which has an unhealthy aversion to risk has a much
higher chance of failure. As time goes on the intolerance of taking on
additional risk to accomplish goals, will render a company petrified.
Stuck in the fear of change.

In order to become unstuck, a company and it's employees must become
great at calculating risk and assessment. In order to make a choice on
what to work on, and what to not work on, they will need to research and
collect data and continuously track progress and feedback. The company
must use this data and feedback to move uncalculated bad risk into
calculated good risk. Simply thinking through the problem and change
before hand can uncover ways to accomplish the end result in the least
risky way.

The biggest objection to the risk assessment phase is typically time
constraints. A great company will learn how to rapidly assess and reduce
the risk of action. They reduce risk by: gathering requirements,
planning, building process, using process to drive automation, and
iterating on automation to speed up feedback loops. These fast feedback
loops will allow the company and it's employees to fail smaller and more
frequently and facilitate reflection to optimize the pipeline. This
means even more calculated and low risk actions!

    So, a company should add more process to reduce risk? Not quite.

A process, when left unchecked or added for the wrong reasons, will
become more detrimental then blindly performing an action without
calculating the risk. Below I outline the key differences between a good
process and a bad process.

A good process will:

-  reduce risk but not at the expense of blocking or preventing progress
-  be fast to facilitate quick feedback loops
-  have potential for automation and must not be tedious or manual
   (think approvals)
-  promote small and frequent changes
-  support both fail forward and fail backward
-  only fail backward to reduce time-to-recover
-  not be pushed down from upper management, rather upper management
   should help set goals and requirements, while the team builds and
   decides on process
-  be questioned and reviewed often to promote iteration to find and fix
   inefficiencies

A bad process will:

-  block real work from getting done
-  prevent creative and innovative solutions
-  have a higher chance of being ignored, skipped, or held in contempt
-  punish people who take risks (make change) and promote people who do
   nothing
-  cause more issues then it solves
-  become a crutch or a security blanket (a false sense of security)

I feel strongly that the essence behind the Agile and DevOps movements
comes from the constant battle of balancing risk with process. This
constant desire for balance in the organization's environment will lead
to innovative ideas, tools, and workflows. These ideas, tools and
workflows can not function properly if transplanted into a company who
does not have the desire to find the optimal balance. Put simply, a
company cannot buy Agile or DevOps, that culture needs to grow from with
in.

.. contents::
