Doing DevOps versus Getting Results

excella.com | @excellaco
Doing DevOps vs.
Getting Results
April 29, 2020

June 23, 2009.

What is DevOps?

Everyone had their own definition of DevOps.

Culture.
Automation.
Lean.
Measurement.
Sharing.

How should we do DevOps?

Toolchains. Team structure. Processes. Policies.

How can I improve performance?

208x more frequent deploys.
106x faster lead times.
2,604x faster MTTR.
7x lower change failure rate.

U.S. Citizenship
and Immigration
Services

Federal agency.
9 two-pizza teams.
Lead time for changes under 60 minutes.
Up to 40 deploys per day.
MTTR less than 3 minutes.
The Art of the
Possible.

Change how we think about work.

① Change Approval Boards.

Traditional Change Approval Boards/Change Control Boards
hurt software delivery performance.

“We found that external approvals were
negatively correlated with lead time,
deployment frequency, and restore time,
and had no correlation with change fail
rate. In short, approval by an external
body (such as a manager or CAB)
simply doesn’t work to increase the
stability of production systems,
measured by the time to restore service
and change fail rate. However, it
certainly slows things down. It is, in fact,
worse than having no change approval
process at all.”

1. Reduce dependencies (and complexity) in your architecture.
2. Use heavy doses of automation.
3. Improve monitoring and observability.
4. Institute effective peer reviews.
Instead of the CAB.

Preserve emphasis on finding
issues before going to
production.
Increase emphasis on reducing
impact of finding issues after
going to production.

1. CI/CD pipeline.
2. Blue/Green deployments.
3. Canary deployments.
4. Feature toggles.
5. Architecture patterns like circuit breaker and bulkhead.
6. Event-driven architecture.
Reducing impact in production.

② Security, compliance, and audit.

Using security, compliance, and audit controls dependent on
documentation and human review is “risk management
theater”.

Typical result of the process…
“You can’t release until you fix
these.”

Lengthens cycle times and
feedback loops.
Creates waste and inefficiency.
Involves decision-makers distant
from the actual work.
Can be circumvented.
Hurts situational awareness.
Counter-
productive
.

Apply automation liberally.

Use the exhaust of normal day-
to-day work.

Like change history from source control.

With the details.

Integrate non-functional requirements from the beginning with automation.
Engage security, compliance, and audit early and often.
Be transparent and share information.
Shift left.

Because we all care about
developing and operating
reliable, secure, high
performance systems at scale.
“I care. I care a lot.
It’s kinda my thing.”
-- Leslie Knope

③ Agile.

Agile is dead. Long live agility.

If you’re changing from this…

…to this...

…you’re not getting all the value.
Doing the
work right. + Doing the
right work.

Experimentation and iteration.
DESIRED
SOLUTION
ITERATIONSSTART RELEASE
INITIAL TARGET
RELEASE
RELEASE

Agility.

Agility as a mindset – not a methodology.

④ Risk.

The risk of change is less than the risk of TWWADI*.
* The Way We’ve Always Done It.

16.2% of projects were deemed successful by being completed on time and
budget, with all the promised functionality.
52.7%, were over cost, over time, and/or lacking promised functionality.
31.1% failed, which means they were abandoned or cancelled.

Perspective.
Risk of not
accomplishing the
business objective in
the quickest, most
cost-effective way
>>
Risk of not meeting
cost, schedule, and
scope objectives

Shift from project to product.
Project Oriented Product Oriented
Budgeting
Funding of milestones predefined at project scoping. New
discretionary budget means the creation of a new project.
Funding of value streams adjusted based on business results.
New budget allocation based on demand.
Timeframes
Term of the project (e.g., one year). Defined end date. Not
focused on the maintenance/ health after the project ends.
Life cycle of the product (multiple years) includes ongoing
health/maintenance activities.
Success
Cost center approach. Measured to being on time and on
budget. Capitalization of development results in large
projects.
Profit center approach. Measured in business objectives and
outcomes met (e.g., revenue). Focus on incremental value
delivery and regular checkpoints.
Prioritization
Program and portfolio management, project plan-driven, with
a focus on requirements delivery. Projects often drive
waterfall orientation.
Roadmap and hypothesis testing-driven, with a focus on
feature and business value delivery. Products drive Agile
orientation.
Delivery
IT is a black box. Project management offices create complex
mapping and obscurity.
Direct mapping to what the business wants that enables
transparency.
From “Moving from Project to Product”, 2018 DevOps Enterprise Forum.

The FAANGs are doing all this to make a buck…

Why are we accepting less for our nation?
• [The Government mission matters. A lot. Pictures here.]

More resources.

Jeff Gallimore
jeff.gallimore@excella.com
@jgallimore
http://itsanicelife.com
https://www.linkedin.com/in/jgallimore

Doing DevOps versus Getting Results

More Related Content

What's hot (6)

Similar to Doing DevOps versus Getting Results (20)

Recently uploaded (20)

Doing DevOps versus Getting Results

Editor's Notes