Dev vs. Ops

Working with cloud applications like Salesforce greatly simplifies the requirements for delivering capabilities. In a sense, Salesforce itself takes the place of the “Operations” team that keeps the production system running. Salesforce Admins largely work as declarative developers, building new capabilities rather than just keeping the lights on and keeping performance tuned. But to understand the DevOps challenge, we can think about development and operations needs in a traditional enterprise.

A critical need for businesses is the ability to innovate and develop new functionality for their customers and employees. This is the role of the Development team.

Another critical need is for existing systems to be stable, reliable, and secure. This is the role of the Operations team, which typically consists of system admins, database admins, web site admins, and so on. Their main job is to make sure servers are up and running, SLAs are being met, the application is performing as expected, and so on.

There’s a natural tension between the need for innovation (change) and the need for stability. Developers want and need to keep changing the system, while the Operations team wants and needs the system to remain as static as possible so that they can optimize performance and reduce the risk that change brings.

In large organizations, these teams had historically worked in silos which isolated the Development teams from QA and Ops. QA and Ops typically deal with huge numbers of applications and features, sometimes with little understanding of the business purpose and value of the software they were enabling.

The end goal for all of these teams is customer satisfaction, but specific goals for “Devs” include fixing bugs fast and creating new features, whereas for their “Ops” counterparts, the goals might be to maintain 99.99% server uptimes. These goals can often be in conflict with one another, leading to inefficiency and finger-pointing when things go wrong.

Chronic conflict between the Dev and IT operations teams is a recipe for failure for the IT teams as well as the organization they serve.

The concept of DevOps is founded on building a culture of collaboration, communication, and automation between teams that may have historically functioned in silos. The goal is for both Developers and Operations to share responsibility for facilitating innovation while still ensuring stability.

The generative culture promoted in the DevOps community emphasizes values such as ownership and accountability. Developers and operations teams collaborate closely, share many responsibilities, and combine their workflows. This reduces inefficiencies and saves time (e.g., writing code that takes into account the environment in which it is run). Figure 3-3 depicts DevOps as uniting the focus and activities of these previously disparate teams.

The Real Meaning of Agile

The Agile Manifesto itself promotes 12 principles,⁴ the first of which is that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” And the ninth of which states “Continuous attention to technical excellence and good design enhances agility.”

To the extent that most development teams organize their work into sprints, and craft their requirements in the form of user stories, “Agile” has become the dominant practice for delivering software. But if deployments require hours or days of preparation, environments are inconsistent, and development teams are working on differing versions of the codebase, then actual agility necessarily suffers.

Real agility depends on being nimble with changing customer requirements and on promoting and deferring to the evolving understanding of the team. But the systems the team uses to do their work and the underlying architecture of the products they’re building are also critically important to achieving real agility.

What better measures of agility could there be than how often the team is able to deploy, how quickly, how often those deployments fail, and how quickly the team can recover?

The Three Ways of DevOps

In his books The Phoenix Project and The DevOps Handbook, Gene Kim popularized the concept of the Three Ways of DevOps. You can find excellent explanations in those books or in blog posts such as this one.⁵ The basic idea is depicted in Figure 3-4. I like to summarize these Three Ways as continuous delivery, continuous feedback, and continuous improvement.

Lean Management

DevOps basically combines two movements: the technical practices of continuous delivery and the practice of Lean management and Lean product development that originated with Toyota. The Toyota Production System set the world standard for how to mass produce a top-quality product. And their product development processes set the world standard for how to quickly innovate to satisfy customers’ diverse needs. Lean Software Development was born from the realization that applying the same practices to software development increased quality and thereby company performance.

There are two pillars of the Lean approach (whether manufacturing or software): just-in-time and stop-the-line. Just-in-time is focused on speed, throughput, and efficiency. With software, the idea is to minimize the time required to deliver a requested feature through steps like automating deployments and identifying other bottlenecks in the process that don’t add value. One key to fast delivery is to break work into small batches. As each small batch is completed, it can be released, which is why the frequency of releases is an excellent indicator of whether teams are following this approach.

Stop-the-line means that as soon as any defect or abnormality is found, the production line (or deployment pipeline) stops and the top priority becomes identifying and uprooting the source of the problem to ensure it doesn’t happen again. The focus here is on stability and quality. With software, this is accomplished through building in checkpoints such as automated testing and validations, and rerunning those every time the codebase changes. The idea is to make the system autonomic, like your autonomic nervous system, where your reflexes recoil from fire without your having to consciously think about it. Having a culture of blameless postmortems is a clear foundation for this kind of approach.

It’s sometimes hard to tell which actions add value and which actions don’t. But it’s always the case that time spent waiting doesn’t add any value. The fastest sustainable speed at which all of the valuable work could be done is called the Process Time. The difference between the Lead Time and the Process Time is one of the main types of waste.

If you think of the lifecycle of groceries, they’re first grown or manufactured, then they’re stored or shipped, then eventually they’re bought and used. The more time elapses between being grown and being used, the more likely they are to go bad. Software also ages quickly. More importantly, the longer the lead time, the longer it takes to get feedback from actual users. Building software is extremely complex, and the only reliable way to ensure things are built well is to get feedback quickly and repeatedly.

The essence of DevOps (and Lean software development) is to eliminate waste, especially time spent waiting. Reducing lead times allows for fast feedback, fast feedback allows for innovation, and innovation enables success.

One of the easiest ways to eliminate wasted time is to automate your deployments using continuous delivery. Implementing continuous delivery on Salesforce is one of the main focuses of this book.

Generative Culture

In his study of safety cultures, sociologist Ron Westrum famously categorized organizational cultures into pathological, bureaucratic, or generative.⁶ Pathological cultures are oriented around gaining and maintaining power. To maintain power, groups and individuals in pathological organizations tend to limit knowledge sharing and retain tight control over their areas of responsibility.

Bureaucratic cultures are rule oriented, with a focus on applying rules consistently across the organization. Bureaucratic cultures have an emphasis on fairness and on following processes.

Generative cultures, by contrast, are performance oriented. The focus in generative cultures is on getting the job done, rather than emphasizing control or process. Control is still important in generative cultures, as are rules and processes; but they are important only in serving the larger mission of organizational effectiveness.

The term DevOps itself indicates collaboration between Dev and Ops. By extension, DevOps involves collaboration with the QA teams, security teams, as well as business owners and subject-matter experts. The origins of DevOps in lean manufacturing imply looking at the entire software delivery chain strategically, to gradually improve the flow of work. The adoption of new development tools and best practices is done as a means to improve the entire system and thus requires the team to work together for the benefit of all.

For these reasons, Westrum’s generative culture model is an excellent description of a culture conducive to DevOps. DevOps requires collaboration between different teams as well as learning and experimentation to optimize software delivery. For many companies, the biggest challenge to adopting DevOps is establishing an open, performance-oriented culture that allows for such continuous improvement.

The 2018 State of DevOps survey asked respondents about their team’s culture and their organization’s culture. The survey analysis concluded that a generative culture is indeed indicative of better company performance. Importantly, it also found that adopting DevOps practices such as continuous delivery actually drives further cultural improvements by reducing the barriers to innovation and collaboration.

Blameless Postmortems

One manifestation of such a generative culture is an absence of finger-pointing. Development of a strong “safety culture” is recognized as important across many industries, notably healthcare, manufacturing, and transportation. In the aftermath of any incident (whether a train crash or an outage in an IT system), blameless postmortems should be conducted to determine how such incidents can be averted in future. Rather than ever settling on “human error” as a root cause, emphasis should be placed on the circumstances that allowed that error to occur. Human error itself has root causes, and a rich safety culture builds in protections that allow imperfect humans to nevertheless avoid such risks and dangers.

A powerful example of a blameless postmortem followed a headline-generating outage for Amazon Web Services. AWS has become the computing infrastructure for an enormous number of companies. On February 28, 2017, the S3 storage service in AWS’s main region went offline for 4 hours. This took a large number of major Internet companies like Quora and Trello offline during that time, since S3 is used to host web site files among many other things. AWS soon released a postmortem of that event,⁷ in which they identified that a typo from one of their admins triggered a chain of other problems.

Although human error was involved, nowhere in their analysis did they cite “human error” as a factor, let alone a root cause. Rather they dug deeper to ask what other circumstances allowed this mistake to unfold. They implemented several new protections and safety checks as a result. Despite the PR problems caused by this incident, there was no implication that the admin responsible was fired or disciplined. Rather energy was invested in further improving AWS to eliminate the risk of this kind of incident happening again in future.

A dramatic example of the long-term impact of improving safety culture can be found by looking at automobile fatalities in the United States over time. Figure 3-5 shows the dramatic increase in the number of miles driven per year, juxtaposed with the progressive reduction in risk of fatalities from automobile travel, along with a few practices that helped bring about these improvements. Blameless postmortems provide the opportunity for IT teams to make similar progress to build systems that are increasingly resilient, even as the velocity of innovation continues to increase.

The IT industry still has much to learn from the systematic improvements in quality and worker safety that have been implemented through such long-standing safety cultures.

Business Impact of Adopting DevOps

The State of DevOps Report affirms the positive impact that adopting DevOps has on businesses. These studies validate that organizations with high-performing DevOps processes outperform their peers financially by enabling faster time to market for features and increased customer satisfaction, market share, employee productivity and happiness thus allowing them to win in an increasingly competitive economy.

Not only do these organizations do more work, they also have far better outcomes. When they deploy code, it is twice as likely to run successfully (i.e., without causing a production outage or service impairment), and when a change fails and results in an incident, the time required to resolve the incident is far faster.

With DevOps in place, instead of deployments being performed only at nights or on weekends, full of stress and chaos, these organizations are deploying code throughout the business day without most people even noticing.

Developers get feedback on their work constantly: linting tools, automated unit, acceptance, integration tests, and other build validations run continually in production-­like environments. This gives continuous assurance that the code and environments will work as designed and that code is always in a deployable state.

Better Value, Faster, Safer, Happier

Jonathan Smart, who led Barclays Bank on a journey of enterprise-wide DevOps transformation, summarized DevOps as “Better value, faster, safer, happier.”¹⁰

Better means always striving to improve the quality of our work and our products. This implies continuous improvement.

Value means using agile development and design thinking to address and adapt to the needs of end users. The focus here is on delivering the desired results to end users and improving their experience. Software is not “done” until it’s in the hands of users, the ones who actually experience value from it.

Faster means using techniques such as continuous delivery to release more quickly. Speed matters; life is short. The more time elapses between requesting something and getting it, the less time that solution will remain valuable. The more time between creating something and getting feedback on it, the more time is wasted in waiting and inevitably forgetting how to improve it.

Coupling increasingly frequent releases with increasingly automated testing allows you to innovate for customers faster, adapt to changing markets better, and improve your product faster. The quicker you can release new features and fix bugs, the faster you can respond to your customers’ needs and build competitive advantage.

Safer means focusing on stability and integrating automated quality and security scanning into the development workflow. Just as when driving in a car, speed only matters if you can arrive safely. Safety means that the solutions we deliver will work and that they won’t break other things. Safety implies testing, or quality assurance. Testing means testing that the software does what it’s supposed to do, is resilient against changing conditions, and doesn’t introduce regression failures (break things that used to work). Safer also implies security, which is an aspect of structural quality.

Automated testing gives confidence that each change is functional and safe. Monitoring and logging practices help teams stay informed of performance or issues in real time.

And happier refers to continuously improving the development experience and the customer experience of users. We’re humans developing for humans. The experience should be increasingly positive for the developers creating functionality and increasingly positive for the end users consuming it.

Note that all of these terms are relative and subjective. This implies an ongoing process, where value is flowing from developers to end users (from creators to consumers), and the whole process is improving on an ongoing basis . We all want better and better experiences. Wisdom dictates that if we focus on improving our actions, our experiences will naturally improve. And so wisely, we strive to improve ourselves and our teams, so that together we can do a better and better job.

The team with the fastest feedback loop is the team that thrives. Full transparency and seamless communication enable DevOps teams to minimize downtime and resolve issues faster than ever before.

Optimizing the Value Stream

A fundamental concept in Lean software management is to understand the software development and delivery process in terms of how each aspect of the process contributes (or does not contribute) to value for the end user. As mentioned earlier, value reflects the benefit that the end user receives and would be willing to pay for. As software moves through the development and delivery process, different individuals and teams add value through their contributions. Their ongoing contributions to the process are described as flowing into a “value stream” that delivers ongoing value to end users.

Value Stream Mapping is a key tool in lean management. This involves mapping each stage of the development and delivery process and then gathering three metrics from each stage: lead time, process time, and percent complete and accurate. Lead time is the total amount of time that it takes from a work item entering that stage until it leaves that stage. Process time is the amount of time that would be required for that activity if it could be performed without interruption. And percent complete and accurate is the percentage of the output from that stage that can be used, as is, without requiring rework or clarification. The goal of this mapping is to identify slowdowns where work items spend time waiting or could be completed more efficiently, as well as stages that suffer from quality issues. It’s also possible that this process uncovers steps that don’t add much value and can be eliminated or simplified. The core concept of lean management is to assess this process and identify how to eliminate waste from this system, to maximize the flow of value.

The potential technical improvements that can be made to a software product or to the way of working on that software product are limitless. This book alone introduces a huge range of possible improvements to the way code is written or developed, the way it’s tested, packaged, deployed, and monitored. But it is unwise to assume that adopting DevOps means that we should simultaneously take on all of these improvements or make improvements arbitrarily. Instead, the goal should be to identify the bottlenecks in the system that limit the overall flow of value and to optimize the system around those bottlenecks.

Begin by identifying the current state value map, and then craft a future state value map that aims to increase the percent complete and accurate of the final product or reduce the amount of waste (lead time where no process is being performed). For more guidance, see the book Lean Enterprise: How High Performance Organizations Innovate at Scale ¹⁴ or Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation.¹⁵

It can be very challenging to discern where to begin such a process. One complementary approach known as the theory of constraints can provide a practical simplification to help target priority areas for improvement.

Theory of Constraints

In layman’s terms, the idea is that the overall performance of any system at any given time will always be limited by a single constraint. In a software development process, the constraint might be that there are not enough developers, or that the testing process takes too long, or that the deployment process can only be done at certain times, or that there is not any additional demand from customers, and so on. The most important point to note is that improvements to any part of the system other than this constraint will not yield any significant benefit. For this reason, the most critical step to making overall improvements is to first identify the constraint.

Identifying the constraint on a system can be a challenging process, combining measurement, intuition, and experimentation. One approach to identifying the constraint is to look for a buildup of “inventory” in a system, since this tends to indicate a point where the process slows down. The concept of inventory is borrowed from manufacturing, but can be extended to the software development process and relabeled as “work in progress.” Where does work in progress (WIP) accumulate in your development process? You can ask your team questions like how large is the backlog for developers? How many pieces of work are waiting for review by a tech lead? How much work is waiting to be tested? How many items are waiting to be deployed? Asking questions like this and observing trends over time can help you home in on the main constraint in your process.

Once the constraint has been identified, the biggest improvement that can be made is to exploit that constraint—to make sure that it is fully utilized. At the time that Goldratt wrote The Goal, it was common in manufacturing to focus on getting maximum utilization from every single system involved in a manufacturing process. The equivalent in a software team is ensuring that everyone is busy all the time. But in practice this local optimization of each part of the system does not optimize the performance of the overall system, because overall performance is always defined by a single constraint. It is that constraint that needs to be optimized, getting the maximum sustainable productivity out of that constraint.

The third stage is to subordinate and synchronize to the constraint. This means that every other part of the system should be seen as a means to enable and support the constraint. The priority for other systems should be to ensure that the constraint is never waiting on “raw materials” (such as specifications for work) and that the work produced by the constraint is quickly whisked away to the next phase of the process.

For example, if you determine that the capacity of the development team is the limiting factor on your ability to deliver value, then the other individuals or processes that contribute to the value stream—business analysis, architecture, testing, and deployment—should ensure that the developers can be made as effective as possible. That means ensuring that they have a backlog of work and clear architectural guidance, and that once their work is complete, it can be tested and deployed as quickly as possible. Importantly, releasing quickly also allows bugs to be identified quickly so that developers can address those while the relevant code is still fresh in their minds.

Having identified the constraint, the second and third stages of optimization function to maximize the throughput of the constraint (first by using it fully and then by organizing everything else around it). It is entirely possible that through making these optimizations, the original constraint ceases to be the constraint. By definition, the constraints on a system are subject to moving and changing as conditions evolve. This is why it’s important to begin by mapping the entire value stream and continuing to monitor each component of it to gain insight into your overall flow. If you find that the constraint has changed, then you have just achieved the first level of optimization for that new constraint: identifying it. Your task then becomes how to exploit the new constraint, and so forth.

If a constraint persists despite your maximizing its throughput, you have only one remaining option: to elevate the performance of that constraint. When your constraint is one or more individuals, elevating the performance of that constraint might take the form of giving them better tools, training or coaching them, hiring additional team members, or even replacing them and moving them to a different role if necessary.

This fourfold process is a continual dance. There is never a time when there is not some constraint on a system. Even when the market itself is your constraint, your practice is the same: to exploit that market, subordinate your other activities to feeding market demand, and finally work to elevate demand through marketing and publicity.

Even the optimization process itself is subject to unseen constraints. It takes time, effort, and situational awareness to understand how your value stream is performing; and it can take time, effort, and money to make the changes necessary to improve that performance.

From the point of view of the theory of constraints, this continual dance is the essence of effective management.

Leading Change

If you are in charge of a small team of Salesforce developers, you may be able to lead adoption of Salesforce DX in a simple and organic way just by piloting its usage and demonstrating some of its benefits. But if change needs to happen across a large and distributed organization, you have entered into the realm of organizational change management. If you have access to experts in organizational change, you should lean on them for advice on succeeding at this process.

A leading voice in organizational change management is John Kotter, whose book Leading Change ²⁴ has been an important and influential guide for many organizational initiatives. Kotter defines an eight-stage process by which effective change takes place. The eight-stage process for leading effective change²⁵ is shared here, together with some notes on the relevance to improving DevOps processes.

Step 1: Create Urgency

None of us act unless there’s a need to. Especially when it comes to changing habitual behaviors and learning new practices, the motivation for change must be strong to overcome our inertia. The same holds true for organizations. Organizational change derives from a sense of urgency , and the first step in effecting broad change is to stimulate this sense of urgency in your leadership team.

Kotter suggests that for change to be successful, 75% of a company’s management needs to “buy into” the change. When it comes to DevOps, this mostly pertains to the managers responsible for overseeing development teams. But changes in process can sometimes involve temporary slowdowns as a team learns new practices.²⁶ There needs to be a commitment from anyone who is a stakeholder in the development process, including project managers, internal customers, and even external customers if you are a consulting company doing development at their behest.

Urgency is built from understanding the problems implicit in the current approach and the benefits of adopting a new approach. The State of DevOps Report provides compelling statistics on the impact of adopting DevOps practices, and I’ve touted those statistics hundreds of times to thousands of listeners to help gain buy-in and motivation.

It’s important for you to also identify risks and opportunities that are specific to your company. In Chapter 12: Making It Better, I share Lex Williams’ story of Salesforce’s own DevOps adoption. Their technical team had been arguing for years that production changes should only be made through a continuous delivery system. But it was only once they started documenting the financial cost of outages arising from ad hoc production changes that they managed to get executive approval to adopt that kind of governance.

Begin to track metrics on how long it takes your teams to deploy to production, merge codebases, perform regression tests, and so on. Take note of how often one team is prevented from deploying critical changes because they have to wait on other teams to complete their work. Gather statistics and explanations to support your vague sense that processes could be more efficient or effective than they currently are. These arguments form the basis for convincing other stakeholders of the need for change.

At the same time, these analyses need to be honest, and you need to listen to counterpoints and have dialog around the need for change as well as possible risks. There are indeed risks associated with change. But by discussing costs and benefits clearly and honestly, you can help yourself and others discern when the risks of not making these improvements outweigh the risks of making them.

Step 2: Form a Powerful Coalition

The first step is the most important, and you should spend time to make sure you have won organizational support before proceeding . But buy-in from management is only the beginning. You now need to gather others who can act as change agents within the company.

Change takes leadership. But leadership happens in many ways, at many levels. You need to find influential people across your organization who are similarly committed to seeing these changes take root. These people may or may not hold traditional leadership roles. Their influence may instead derive from their length of time at the company, their technical expertise, their passion, or their social connections.

Connect with these people to form a coalition. Ask them to commit to helping bring about this change, and work on building trust and collaboration within this initial group. It is helpful to ensure that you have a broad mix of people from different roles and different groups within your organization. For example, at Appirio, we began our DX initiative with a survey of all our technical consultants in which we asked them “which Appirian has helped you the most to improve your coding skills.” This survey helped us to identify influencers across different levels and geographic regions. We brought these people together as evangelists, giving them early access to training and demos as we began to promote Salesforce DX.

Step 3: Create a Vision for Change

Humans are remarkably good at telling and remembering stories. And the most effective communicators rely on stories to convey the essence of complex messages in memorable and impactful ways. Salesforce has poured a phenomenal amount of money into their sales and marketing efforts; and marketing is fundamentally about storytelling.

The tagline for Salesforce DX is “Build together and deliver continuously with a modern Salesforce developer experience.”²⁷ That succinct statement creates a vision , which itself inspires change. “Build together” speaks to collaboration and promises easy collaborative development even across large and distributed teams. “Deliver continuously” speaks to easing deployments and helping end users get ongoing value from development. “A modern developer experience” speaks to the promise of replacing tedious manual processes with powerful and automated tools.

What is the vision for modernizing your own Salesforce development experience?

Think about the values that are most important for this initiative. Are you most concerned about speed? Security? Reliability? Ease of debugging?

Based on these values, write out a one- or two-sentence summary of what the future looks like once these changes are in place. This becomes the vision statement for your change.

Next craft a strategy to achieve that vision. The strategy adds detail that you’ll need as you begin to roll out changes. But the first step in your strategy is to regularly reinforce the vision and ensure that everyone in your change coalition is able to articulate this vision and some key aspects of the strategy. This is the message that you need to build and amplify. It needs to be clear, simple, and compelling so that the story can be told, remembered, and retold again and again throughout the organization.

Step 4: Communicate the Vision

Having gathered support from management, built a coalition of change agents, and established a clear and compelling vision for change , you now need to communicate that vision repeatedly across many channels.

People are subjected to many messages and stories every day. In a busy company, even attendance at ongoing training or all-hands meetings may be limited. So for a message to gain traction, it needs to be heard repeatedly, across different mediums, over a prolonged period. At one point in the Appirio DX initiative, I recognized that many people in our organization lacked grounding in some basic DevOps concepts. So I initiated a “DevOps December” campaign to reinforce some basic DevOps ideas across many channels.

We began the campaign somewhat quietly with posts on our internal Chatter group. But my manager encouraged me that we should reiterate these messages across different channels. “I want people to have DevOps coming out of their ears. I want them to hear about this so much that I start getting complaints!” he said. I happily obliged and sent out daily “byte-sized” updates by both email and Chatter, along with an appearance on a company all-hands call, several open webinars, and a dozen small group meetings. Eventually, he did receive complaints, so we limited the volume and distribution a bit. But we were both delighted with the impact and the reach. No one at the company escaped that December without learning a bit about DevOps.

This formal messaging is not the only way to reinforce the vision. Your actions speak louder than words. So embed these concepts into how you work. Call out teams who are adopting parts of these practices and highlight the benefit they’re receiving. Invite people from those teams to talk about their process . Look for examples in other technologies and share those to bring inspiration.

Tie everything back to the vision. And look for opportunities to incent people to move toward this goal, rewarding them when they do.

Step 5: Remove Obstacles

Repeated communication represents the “happy path” of sharing the vision for change. But it’s entirely natural for you to encounter obstacles as you move toward this goal. Those obstacles may be in the form of skeptics or naysayers who emphasize the shortcomings with the new process or downplay the need for change. There may also be processes or structures in place that get in the way of change.

I’ve encountered senior technical architects who have said that it will never be possible for us to get all of our teams using version control, or that Salesforce DX is not mature enough or a high enough priority for most teams to adopt. Such voices can represent healthy skepticism, but in many cases they are simply based on these individuals’ own inertia or lack of experience with this new way of working.

Listen to skeptics, and make sure you’re understanding the doubts and risks being expressed. But be on the lookout for voices and processes that are actively standing in the way of change and figure out how to overcome these. Help educate these skeptics if their concerns are not valid. Or help them understand how the benefits of change outweigh the disadvantages. There is a learning curve to adopting version control. But every developer I’ve talked to who has worked extensively with version control and continuous delivery would never go back to their old way of working and would want these systems in place on any project they were on in future.

If the obstacles relate to time challenges, the need for training, gaps in tooling, and so on then address those obstacles appropriately.

Kotter’s eight steps to effective change were originally based on his analysis of how change efforts failed in organizations . Having studied dozens of transformation efforts across 15 years, he wrote an article called “Leading Change: Why Transformation Efforts Fail” in which he identified that change efforts fail for one of eight reasons, which are the converse of these eight steps for effective change. Your role in leading change is to identify any obstacles to transformation and uproot them rather than letting them undermine the success of your effort.

Step 6: Create Short-Term Wins

Success begets success.

One important conclusion from the law of diffusion of innovation is that Salesforce’s Trailhead motto is not strictly true. We’re not all trailblazers, at least not in every aspect of our lives. Most people, most of the time, are trail followers. And there’s nothing wrong with that.

When it comes to implementing Salesforce DX or other DevOps initiatives, you can expect at most 2.5% of the population to be true trailblazers. To extend the analogy, these are the innovators who tromp through the wilderness and blaze (mark) trees to show others where to go. They’re followed by the equally intrepid 13.5% of early adopters who by analogy are perhaps clearing the trail and ensuring that it’s increasingly easy to follow.

What these trailblazers offer are examples of successes, small and large. And it is these successes that you need to amplify, advertise, and celebrate. Keep track of these successes and share them.

My brother is an extremely seasoned mountaineer, who has traversed almost every terrain you can imagine. But for myself and the majority of the population, the best we’ll do is hiking well-marked trails, while staying in range of cellphone towers that allow us to double-check Google Maps. It’s the same with most of the development teams at our organization. Their adoption will come when they see clear examples of other teams that have succeeded.

You can strategically choose small early wins to build everyone’s confidence in this process. Nowhere is this more important than with refactoring your codebase to make use of Salesforce DX unlocked packages. Many people have tried and failed to convert their entire org into a single massive package. But the most effective approach is to first build a single relatively simple package and ensure you can deploy it across all of your orgs. Unlocked packages make it easy to add unpackaged metadata into a package, so once teams have established initial success with that process, they can build on that strength as their packages grow and multiply.

Create short-term targets , especially quick wins that you can confidently achieve. This gives everyone on the team increased confidence and helps pacify critics and those who might oppose your efforts.

Step 7: Build on the Change

Kotter argues that many change projects fail because victory is declared too early. Quick wins are only the beginning of what needs to be done to achieve long-term change, and your goal here is to effect a deep and lasting change in approach.

On the basis of your initial successes, keep building. Continue to set targets for training and adoption. And importantly, encourage teams to track their own development and delivery metrics and practice continuous improvement.

Consider establishing a center of excellence around DevOps or Salesforce DX practices. This provides the opportunity for disparate teams to share their challenges and successes. This kind of ongoing knowledge transfer is important.

Step 8: Anchor the Changes in Corporate Culture

The final stage is to ensure that these practices become embedded in corporate culture, so that they can become self-sustaining and are simply the way the company operates.

When I joined Appirio, the organization had an extremely well-established performance-oriented culture . From day one the executive team championed open communication, transparency, collaboration, and efficiency. In addition, the agile practices of working in sprints, using user stories, and so forth are second nature. There is still work to do to embed DevOps practices into the culture and to ensure they are as natural to the organization in the future as sprints and user stories are today.

It’s important to see the broader context in which these practices exist, so that even sales and business people recognize that a reason our organizations can be so effective is that we empower our developers and continuously optimize and automate our software delivery processes. It is only when such practices become part of your corporate DNA that you can have confidence that this change effort will outlive any of the original instigators, and be passed from generation to generation of the organization, despite the constant churn and turnover many IT organizations face.