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.

In an ideal DevOps team, the whole team works in the same way and toward the same goal – there should be a shared responsibility for the successful delivery of changes. Fundamental to this collaborative approach is strong communication, and this can take many forms, from the more formal approach needed for governance of the overall change management process down to the daily interactions that form part of your usual workflow.

Communication should be clear, informative, and present at every step of the delivery life cycle. For example, when using version control, teams should endeavor to always provide meaningful commit messages and comments on peer reviews. These aid teams to carry out the next steps of any change delivery process with context, not just the specifics of the change itself. There is often a balance needed between providing sufficiently detailed information and relevant information, and you should iterate on this level of detail to find the sweet spot that works for you and your team.

While this book is not an exploration of Agile principles, there does seem to be a strong correlation between successful DevOps teams and Agile practitioners since both disciplines foster these same principles of regular, clear, and concise communication to drive projects forward. Such techniques encompass all team members involved in delivering change so that everyone is informed and aware of the process and progress of work.

Equally, tools will help bring visibility and clarity to daily work. Software for managing features as they go through your DevOps process, such as Jira, Asana, Azure DevOps, and so on, can bring this overview to your processes when used properly and they integrate in some way into most DevOps tools to complete the picture. Many teams have started to eschew email as an internal communication medium, instead favoring the immediacy of messaging platforms such as Slack or Teams as a further means of breaking down siloes and removing barriers between cross-functional teams.

The necessity of adapting to remote work has led to an increased reliance on digital communication tools and has changed the dynamics of team interaction in a number of ways. With teams distributed across various locations and time zones, it is essential to have tools that enable real-time collaboration and offer instant communication, file-sharing, and integration with other tools. In remote work, it is not always possible to gather everyone at the same time for discussions. Asynchronous communication tools, such as project management platforms, shared documents, and threaded discussions on messaging apps, allow team members to contribute at their convenience and keep everyone informed of progress.

With every adaptation that needs to be made with the shift to remote working, balance is key. With the shift to digital communication, remote workers may face an influx of messages and notifications. Messaging platforms have adapted by offering features such as channels, threads, and snooze options, allowing team members to prioritize and manage their communications effectively. However, it is equally important to maintain a sense of connection and engagement between team members. Messaging platforms facilitate informal interactions, such as virtual water-cooler conversations, quick check-ins, and social activities, helping teams stay connected and fostering a positive team culture.

Remote work has made it necessary for teams to communicate effectively without the context provided by face-to-face interactions. Modern methods of communication for distributed teams encourage team members to be more concise and clear in their communications, as well as more intentional with their responses.

Finally, as remote work relies on digital communication tools, ensuring data security and compliance with industry regulations becomes critical. Technological solutions have responded by offering end-to-end encryption, data storage options, and compliance features tailored to different industries.

As we’ve seen, the adoption of a DevOps culture should come before the adoption of DevOps technology. Within each, however, the optimal approach is always to start slowly – it’s often said that DevOps is a journey, not a destination, and to that end, we should begin with some planning.

Questions to start with

The best place to start any kind of journey is to look at where we would like to go, with a few questions:

• What does the intended process look like?

Knowing your target scenario helps focus your efforts and prevents unnecessary disruption to your business. For example, is the ultimate goal to be able to deliver business requirements faster and incrementally, or do you want to work to a more scheduled, sprint-based approach, but have better visibility and control over the elements contained within that sprint? Having the aims well defined up front helps focus teams on delivering them.

• What is the intended audience for the new process?

A new DevOps process will impact more than just development and operations teams. If you truly want to adopt an end-to-end Salesforce DevOps approach, you will need to align not just the technical teams but also those involved in the gathering and assigning of work tasks, those responsible for project management, release management, overall architecture, business approval, and more. We’ll look at some of these governance aspects shortly.

• What do we need to change in our current approach?

While it’s not unheard of, it’s rare that an existing process needs to be completely replaced. Take stock of your current delivery model and make note of what works and what doesn’t work. Where are the bottlenecks that are slowing you down? How many attempts does it take to get something delivered to production? If we look again at the DORA metrics discussed earlier, where are we starting from? Getting a baseline set of metrics before you start a DevOps transformation is a solid way of measuring progress and improvement – and ultimately, your return on investment – as you begin to adopt Salesforce DevOps. Furthermore, having the ability to demonstrate the problem (and later, the improvements made) to executive stakeholders is invaluable in getting their buy-in for a DevOps transformation project.

With these questions front of mind, it becomes easier to start identifying the potential gains from adopting Salesforce DevOps, which, in turn, can help drive team alignment with the change. This step is essential – everybody involved needs to become a stakeholder in the move to DevOps and the best way to achieve this is to look at things from two viewpoints:

• What are the benefits that DevOps will bring?

After identifying the teams that will be directly impacted by the adoption of DevOps as a means of delivery, work on conveying the benefits to them. Visibility of changes, more manageable and smaller units of work, faster delivery, robust testing, reasonably predictable release cycles – all of these things matter to Salesforce teams and the overriding principle of making their life easier is a strong driver for getting people on board with the change.

• What are the risks of not adopting DevOps?

Equally, it’s valuable to assess the risks of standing still and changing nothing. If you don’t adopt a faster and more flexible delivery model, you risk being outmaneuvered by more agile competitors. If you don’t implement a robust backup and recovery strategy, you risk losing your valuable business data or that of your customers. If you stick to more traditional delivery models, which can be lengthy and arduous, you risk dissatisfaction and burnout in your teams, which can lead to them moving elsewhere.

Making life easy for your teams

If your Salesforce team is new to DevOps concepts, techniques, or even terminology, then it can seem a daunting prospect for them to move to a new delivery model. However, like all large projects, the optimum approach is often to start slowly with small aspects of the process, then expand and iterate upon it.

For example, because the concept of source control has historically been a code-based domain for developers, many Salesforce Admins will be unfamiliar with this approach. This area alone is a good place to start – even if you don’t necessarily dive straight into applying source control, the mere act of aligning Admins and Developers with a common way of working contributes to the communication and collaboration components of building a DevOps culture.

Having Admins and Developers work more closely together in this way also lends itself to another great set of techniques for fostering your DevOps culture. High-performing Salesforce DevOps teams make frequent use of mentoring and coaching to not only improve the overall skill set and confidence of the team but also as an aid to collaborative working and breaking down siloes to form a multi-discipline DevOps team.

Of course, it’s not all about the process, and you should also ensure that your teams have the necessary tools to aid a smoother DevOps journey. As an architect, you should be ever-mindful of the Salesforce DevOps landscape and assess the components, such as version control providers, new tools or updates to existing ones, or even complete Salesforce DevOps platforms – some of which we’ll look at in later chapters.

Governance and risk management

A DevOps culture should be ever-mindful of the need to manage and mitigate business risks, and a strong governance framework should be in place to provide this. It’s important to appreciate that while DevOps unlocks the potential for rapid delivery of change, it is not a free-for-all without controls.

The governance of our DevOps process should be aligned with the governance in which your business, or that of your customers, operates. Without the correct processes in place, you risk losing the value of the alignment and adoption you fostered in starting your DevOps journey. You risk falling back to the use of lengthy, monolithic releases with dissatisfied customers waiting on changes that are buried deep in the backlog. You also potentially risk low-quality changes being delivered, which, in a worst-case scenario, can damage your systems, your data, and your reputation.

Regulated industries such as financial services and healthcare face unique challenges when it comes to software development and deployment. These industries are subject to a wide range of regulations, standards, and compliance requirements that govern how software must be developed, tested, and deployed. These regulations are in place to protect sensitive data, ensure data privacy, and prevent fraud and other criminal activities.

In financial services, regulations such as the Sarbanes-Oxley Act, Payment Card Industry Data Security Standards (PCI DSS), and Anti-Money Laundering (AML) regulations require financial institutions to implement strong controls around software development, testing, and deployment. Similarly, in healthcare, regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the General Data Protection Regulation (GDPR) require healthcare organizations to protect patient data and ensure data privacy. DevOps can help organizations in these types of industries comply with these regulations by providing a structured process for software development, which includes automated testing, security scanning, and continuous monitoring. This can help ensure that software is developed with security and privacy in mind and that any potential security vulnerabilities are identified and addressed before the software is deployed.

A good governance framework addresses these issues by implementing the necessary checks and balances throughout the entire life cycle. From prioritizing work and deciding which initiatives are driven forward through to the technical design and implantation considerations, governance allows stakeholders on all sides to input into success.

At the heart of this approach lies the Center of Excellence, which oversees this journey. It informs and guides the business goals as they apply to Salesforce, the approach used for delivery, and the technologies used. It is also responsible for communication with both stakeholders and end users across the organization, for identifying and managing business risk of projects, and for ensuring initiatives deliver value.

As such, a CoE often contains, or works alongside, distinct groups with specific responsibilities. A Change Management group, for example, will be the approving body for changes going into Salesforce and will make sure that the change is of suitable quality and has been thoroughly tested before it is allowed to be released to production. This would typically be through the definition of the required processes and behaviors it expects to see carried out to ensure quality deliverables, rather than it carrying out the testing itself, which would continue to be the responsibility of the technical teams.

A note of caution should be taken with Change Management groups, however. In the book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim, the authors emphasize the importance of fast feedback loops, continuous experimentation, and a culture of learning and improvement – factors that may suggest that traditional change management practices may not always align with the needs of high-performing DevOps teams.

A Steering Committee, on the other hand, is a business-led group that ensures that changes continue to align with business strategy, vision, and values. Across all these areas, there should be an executive sponsor that is empowered and available to make decisions and unlock business bottlenecks.

Making a case for a CoE to leadership

Architects looking to present a case for establishing a CoE to the leadership of their organization or customers should largely draw upon the same techniques for presenting any proposal to stakeholders. However, some specific elements should be considered a fundamental part of that proposal. Here are some typical areas to focus on:

Table 2.1 – Elements to consider in a proposal

Overcoming resistance and hesitation

There are several common reasons why people might initially resist the idea of implementing DevOps in their organization, believing that “it’s nice, but it can’t be done here.” Let’s address some of these reasons and provide counterarguments to help dispel these concerns:

Table 2.2 – Reasons and counterarguments to dispel concerns

By addressing these common concerns and demonstrating the potential benefits of adopting DevOps, you can help overcome resistance and encourage stakeholders to embrace this transformative approach.

There is an often (mis)quoted saying, “Culture eats strategy for breakfast,” and seldom has this been more pertinent than in the world of DevOps. No matter how well crafted your strategy for adopting DevOps may be, it will not succeed if your team is not on board with the culture and mindset required. By promoting the advantages of a DevOps process and ensuring that the entire team works together to this model, with strong communication along the way, you have laid the foundation for a successful Salesforce DevOps transformation and can now build upon it with the tools and techniques we’ll explore in the next part of this book. In the next two chapters, we’ll first look at the essential role that testing plays across your DevOps life cycle, before looking at an example workflow that takes these elements into account with a typical SFDX and Git workflow.

Culture eats strategy for breakfast – or does it?

The quote is attributed to renowned management expert, Peter Drucker. While this version remains in popular use and demonstrates our point here, Drucker’s original quote was “Culture – no matter how defined – is singularly persistent.”