77 lines
3.4 KiB
ReStructuredText
77 lines
3.4 KiB
ReStructuredText
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::
|