The need for a DevOps culture

The history of software development and its delivery has been long and ever-changing. As the landscape of technology has changed, so has the need for businesses to get that technology into the hands of customers. DevOps represents a drive to deliver according to that need, replacing monolithic software releases, lengthy project cycles, and opaque waterfall methodologies.

When we look at DevOps as a way of delivering change, it’s very easy to get pulled into looking at the software tools first, but this should not be where your DevOps journey begins. It’s equally important to keep in mind that any DevOps transformation should not be prescriptive; instead, it should align with you and your organization’s way of working. This approach is equally important for those that have had prior DevOps experience with other teams or systems – there is no “one size fits all” approach to DevOps, and while experience can be brought to bear on building a DevOps culture with a new team, you should be mindful of tailoring it to fit the team.

However, there are some common elements that work consistently for high-performing DevOps teams, so you should contemplate making these a part of your plan to bring DevOps culture to life. Let’s begin by looking at some of the characteristics of successful DevOps teams and the elements of DevOps culture they have adopted, before diving deeper into how to deliver them.

Strongly defined teams

As the name suggests, DevOps teams are a hybrid of IT Development and IT Operations teams, but the reality is not as straightforward. Successful DevOps teams comprise teams from the full end-to-end spectrum of software delivery, from business analysts gathering the requirements and architects designing solutions to those requirements through to developers implementing those solutions and operations delivering those requirements in your Salesforce environments.

It is within this cross-functional team structure that you need to establish strong buy-in for DevOps. A team that does not understand or appreciate the value of a process is unlikely to adopt DevOps – and it only takes a few shortcuts or out-of-process releases to damage the good work the rest of your DevOps team has done. It is vital that the entire team aligns and engages with DevOps as a way of working, to make the initiative successful.

A team that aligns with DevOps practices has shared responsibility for the entire application life cycle, from planning to deployment and maintenance, thus reducing standoffs and finger-pointing over who is responsible for fixing bugs or test failures. Additionally, DevOps encourages product teams to be more involved in the development process, ensuring that their input and expertise are considered throughout the application life cycle.

As architects, we need to convey the value that DevOps brings since for most teams – whether technical or on the business side – this tends to be the key factor that gets people on board. By showing how DevOps benefits everyone along the development journey we have outlined, we stand a better chance of getting teams on board with DevOps, compared to a hard enforcement of processes.

Companies that have yet to adopt a DevOps culture for software delivery may have lost trust in their delivery teams, bringing in heavyweight processes in an attempt to prevent the risk of future failures. Part of adopting a DevOps culture is restoring that trust by providing tools and processes that empower teams to succeed and allow any failures to be small, rather than bogging everything down by trying to avoid failure entirely.

In general, one of the benefits of DevOps and Agile is to be able to take small steps safely. DevOps and Agile methodologies advocate for small, incremental releases rather than large, monolithic deployments. This approach allows teams to identify and fix issues more quickly, reducing the risk of catastrophic failures. It also enables them to respond to changing requirements or market conditions more effectively. As a result, trust in the team’s ability to deliver accurate results and adapt to change grows.

Closely working together

Hand in hand with strong teams is the need to collaborate and communicate with each other. This may seem an obvious need in all working teams, not just DevOps, but the principles of clarity, visibility, and cooperation really come to the fore with DevOps and are essential for its smooth running.

To break down the siloed approach to software delivery and work toward a common goal, the entire team needs to be aware of how projects are being delivered. Techniques such as Agile and tools such as Jira or Asana will certainly help with this, but that’s only part of the picture of collaboration, as we’ll explore shortly.

Constant evolution

No matter how mature a DevOps team may be, the highest-performing teams are always open to change and improvement. Through a continuous cycle of measurement, enhancement, and re-measuring, these teams are able to pinpoint areas where performance and accuracy gains can be made and then address them. The most common metrics they tend to focus on are based on the DORA metrics, as follows:

• Deployment frequency: How often a team releases to production
• Change lead time: How long it takes for a specific feature to reach production
• Change failure rate: The proportion of deployments that either fail to deploy or cause errors in production
• Mean time to recovery: How long it takes to recover from a production error or another issue

In the context of Salesforce, measuring against these metrics can be a bit different since it’s a cloud-based platform with specific features and limitations. Metrics such as deployment frequency, change lead time, and mean time to recovery can be determined easily enough, especially if you have a ticketing system such as Jira or Asana for managing new work.

The change failure rate can be a little trickier, though, since it involves tracking unsuccessful deployments and the number of incidents or defects related to those deployments. There are a few ways you could approach this – we’ll cover Salesforce-specific DevOps solutions and platforms in later chapters, but as an example using on-platform features, you could try the following:

• Use Salesforce’s deployment history, available on the Deployment Status page, to track the success and failure rates of deployments. Identify failed deployments and the specific components that caused the failure.
• Keep a record of all production incidents, including those caused by recent deployments. You can use the Salesforce Case object to log and track incidents.
• For each failed deployment or production incident, analyze the root cause and determine whether it was due to a recent change. You can use the Salesforce Developer Console, debug logs, and test results to pinpoint the root cause of the issues.
• Divide the number of failed changes (deployments causing incidents or defects) by the total number of changes made during a specific period. Multiply the result by 100 to get the change failure rate as a percentage.

The origin of the DORA metrics

The DORA metrics came from a group called DevOps Research and Assessment, which was founded in 2015 by Nicole Forsgren, Gene Kim, and Jez Humble (and later acquired by Google in 2018), to better understand what factors led to high-performing DevOps teams. Since that initial research, these four metrics have become an industry-standard set of measurements of DevOps success.

Now that we’ve determined the need for, and elements of, a strong DevOps culture, let us look in more detail at some techniques for creating this culture.