Visualizing a DevOps mindset

Visualizing a DevOps mindset

Use this graphical analysis to help develop a DevOps strategy for your organization.

gears and lightbulb to represent innovation
Image by : 

opensource.com

x

Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

These days, organizations are moving from a resource-optimized business model based on capital expenses (CAPEX) to a market-optimized model based on operational expenses (OPEX). What's driving this shift? Reducing time to market and continuously delighting customers with value.

Welcome to digital transformation. Are you ready to embrace a DevOps mindset in your organization?

As defined by DevOps manager Donovan Brown, "DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."

DevOps is not about magical unicorns and colorful rainbows. It's a journey of continuous learning and improvement, with a destination you never quite get to. It's the reason that all of the images herein are based on the infinity symbol:

Being a visual-minded person, I created a presentation with posters for the recent Global DevOps Bootcamp (GDBC). This annual community-driven event is hosted around the globe to create an environment in which participants collaboratively explore digital transformation and DevOps insights.

Let's explore four of the quick-reference posters (also referred to as visuals and infographics). For a more in-depth discussion of DevOps, refer to The DevOps Handbook, by Gene Kim, Jez Humble, Patrick Debois, and John Willis.

Practices

Based on the DevOps Assessment, the first two posters are intended to be used when reviewing the assessment results with all stakeholders. The first one introduces five key practices:

Top performers encourage a culture that fosters a growth mindset, reward innovation, collaboration, experimentation, learning, and user empathy. Strive for a process with responsive application delivery, flexible scheduling, and iterative experiments. Monitor, identify and mitigate issues, and continuously eliminate wasteful bottlenecks. Only valuable key performance indicators are measured and used to strive for better outcomes, such as a low change failure rate (CFR), minimal time to recover (MTTR), and remediation of issues at the root level. Lastly, technology, which is an enabler, is the focus of the next poster.

Technology

Here's a companion of the practices poster, focused on technology:

Version control manages versions of your application, configuration, infrastructure, and other code. It enables team collaboration and monitoring activities such as deployments. Top performers use topic branches for short-term isolation, continuously merge changes into master, review, and audit using Git pull requests, and version everything.

Testing must be viewed as a continuous activity, embedded into both the developer workflow and the continuous integration (CI) and continuous delivery (CD) pipeline.

The cloud enables you to effectively provision your infrastructure and move as fast as necessary.

Lastly, monitoring enables you to form a hypothesis, validate or disprove experiments, proactively detect issues as they occur, and understand application health.

The black bar on the right of the poster lists products to consider when you're investigating technology for your development, production, common engineering, and other environments. Provide feedback on the listed products and regularly update this volatile and opinionated part of the visual.

Habits

Based on the Moving 65,000 engineers to DevOps with VSTS story, this poster focuses on the five key habits we learned about during our transformation. The customer-focused, team autonomy and enterprise alignment, and shift-left habits are evolutions of Agile, and the production-first mindset and infrastructure as a flexible resource are particular to a DevOps mindset.

Customer-focused is part of our quest to delight customers and our obsession with delivering customer value. You must actively listen to your users, progressively enable and disable features, perform continuous experiments, and measure key performance indicators. Use all available feedback to maximize learnings and influence value.

Shift left encourages reviews, validations, and approvals for both testing and security as early as possible in the feature delivery cycle to drive quality and a fail-fast mindset. When technical debt exceeds a predefined limit (for example, five bugs per engineer), encourage feature teams to suspend feature work until the technical debt is paid down.

Team autonomy and enterprise alignment are concerned with what, how, and why we build. You need a common cadence, or heartbeat, across your organization to enable all leadership and feature teams to collaborate transparently and effectively. The most effective feature teams own a feature from idea to production, with autonomy on how they develop and support their features.

Production-first is a mindset that does not differentiate how features and bugs are handled during development, testing, and operational support. Everything should be automated, versioned, and fine-tuned in production. Lean on ring-based deployment and rings to limit the blast radius of feature changes in production, remediate all issues at the root cause level, and remember to be transparent about issues, root cause, and resolution (as a user, I'm much more understanding if I have an insight into issues).

Infrastructure as a flexible resource describes how solution architectures are adapted to the cloud, containerization, and microservices. Adopt a pragmatic transformation that makes sense for your organization, goals, products, and culture. As with the previous habits, it's important to favor autonomy over a descriptive architecture and not to transform everything all at once.

Getting started

The last visualization combines all of the above and suggests five steps to getting started with DevOps:

I prefer to start with the assessment to help identify key areas that can be improved.

  • Assessments provide a benchmark of your DevOps mindset and performance against the rest of the industry. It's important to understand where you're doing well and where investment will help take you to the next level. Both the DORA and Microsoft DevOps Assessments are great starting points. In addition, gather metrics to use as a base to measure progress—for example, deployment frequency, lead time for changes, mean time to repair, and change failure rate.

  • People and culture are your biggest challenges. Everyone needs to buy into the transformation, understand how they will be affected, encourage transparency, be engaged, and take full responsibility for their value streams. This includes leadership, which needs to be supportive, inspirational, empowering, and drive a clear vision. You'll make or break the transformation as a team.

Without committed people and an experimental culture, the rest of the DevOps transformation journey is futile.

  • Process is your engineering system, which enables the teams to manage live site incidents, use lean management and development, and continuously deliver value. A common engineering system introduces consistency, empowers feature teams, and enables and encourages everyone to support and contribute to each other. Your top process goals should include a focus on quality, a loosely coupled architecture to enable scaling, lightweight management, automation, multiple releases per day, and celebration of success as a team and as an organization.
  • Products are the easiest link in the chain. They enable everyone to focus on what's important: Delivering value to end users.
  • Value is all about delighting users. Key performance indicators include deployment frequency, lead time for changes, change failure rate, and time to recover.

Whether you tackle all these steps all at once ("big bang"), step-by-step ("peeling an onion"), or gradually innovate your value chain across all steps ("broad-spectrum innovation") is your choice. Just be pragmatic.

Improvement is possible for everyone if leadership provides consistent support and team members commit themselves to the work. -Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim

Which visuals do you like? Which ones add no value? What is missing? Let's collaborate to demystify DevOps and help you and your users shine. Users need to understand that they are not alone and know they can rely on proven practices and real-world learning.

Looking forward to your feedback and pull requests!

What to read next

How to build a business case for DevOps transformation

Support the need for a DevOps transformation by focusing on the business benefits, not the technology.

Topics

About the author

Willy-Peter Schaub - Since mid-’80s, I have been striving for simplicity and maintainability in software engineering. As a software engineer, I analyse, design, develop, test, and support software solutions. I am passionate about continuous innovation and to share learnings from the digital transformation, by Microsoft and the ALM | DevOps Rangers, to a DevOps culture to adapt people, process, and products to continuously deliver value to our end users. You can follow me on...