Technology and culture are linked. Organizations that implement the right technology alongside cultural changes reap the benefits of technology.

Partnering with a strong DevOps provider that can guide technological and cultural change is also a transformational catalyst. These two statements are facts; but where to start?

Dr. Eliyahu Goldratt, in the series of recorded lectures called “Beyond the Goal,” provides a simple, four-question framework for exploring new technologies and getting their full advantage by considering the cultural changes that should accompany adopting them. In this series, Dr. Goldratt starts by observing a link between technology and culture, where the limits of our technology are accommodated with rules, and we can only gain the full benefit of technology when we also change those rules.

Let’s use cars as an example. Before the invention of the automobile, transportation was slow. We accommodated that limitation by living within a few miles of our workplace. The car allowing us to get to work a bit quicker is nice but changing the rule such that we can live farther from work was transformational.

The four-question framework and DevOps

Paraphrasing Dr. Goldratt, these are the four questions when considering new technologies:

1. What does the technology do, and what value does it provide?
2. What limitation does the technology diminish?
3. What cultural practices helped us to accommodate the limitation?
4. How do we change our culture with new practices and rules?

Let’s now consider DevOps technologies in light of these questions and then look at how to use them more generally.

An example: Continuous integration

What it does

A continuous integration (CI) server monitors source control. When it detects updates to source, it retrieves them, runs a standard build process, tests, and saves the resulting artifact—typically compiled software. If the build fails to compile or fails testing, the CI server notifies the team. The following video goes further in-depth on continuous integration:

In this case, the desired cultural change (more frequent integration) was identified and then ran into a limitation (the build breaking often). The technology was put in place to overcome the limitation. Still, today, many organizations put the technology in place without changing practices or culture.

How continuous integration diminishes broken code

When changes enter source control, they may cause the software to be broken, including an inability to compile. Badly broken code bases slow down other developers and testers. Without CI servers, someone must do the build manually to detect the problem. With CI, the checks are done frequently and cheaply.

Rules that helped us accommodate the limitation

Developers who “break the build” are socially punished, incentivizing developers to commit to source infrequently and with significant testing and caution before the commit. The team identifies a “Build Master” who would run the build correctly and repeatably. Changes to shared code with infrequent merging would lead to “merge conflicts” which developers would work through together. Resolving merge conflicts is relatively time consuming.

Continuous integration rules and practices

We can now detect broken builds quickly and easily, and we should focus on driving down the cost of merge conflicts. Developers should commit changes early and often. Instead of social pressure not to break the build, the social pressure should be applied towards fixing broken builds quickly. Developers can now integrate their work more often, continuously, reducing that merge pain while speeding time to market.

Practice continuous integration to get the value of continuous integration technology

This is a clear example of how the practice of continuous integration—or committing code to a shared code line at least once per day—and the technology of continuous integration are aligned well enough to rightly share a name.

The real benefits from developers frequently sharing their work—enjoying significant productivity gains from working on the latest, spending less time on merging, and learning about coding errors more quickly when the changes are still fresh in their mind—come from a change in technology and culture.

A naïve implementation of CI tooling would just aim to replace the Build Master role with a tool. A return on investment in terms of lower operational costs could be measured to claim success but that misses the real benefits of implanting continuous integration in the team’s culture.

Release orchestration, continuous delivery, value stream management, and all other DevOps practices and tools

The same exercise can be applied to all the DevOps practices and tools that you should be considering to champion DevOps within your organization.

We are now hearing more and more stories of companies that implemented continuous delivery using CI and release automation and claim that they are not seeing the benefit. This is not a surprise when we see that they have done little to nothing to change the rules, assumptions, and practices. They are living by limitations that no longer apply to them, and that is what it means to adopt DevOps tools without adopting a DevOps culture.

The transformational business change comes from new rules and practices. At the same time, cultural change without assistance from tooling will often struggle. For continuous integration, the practice of constant committing came before the tools. Although it’s been demonstrated that you can do frequent, correct builds in line with CI without any tools, implementing the tools and allying with the right vendor can help to gently push the team towards the culture you are trying to build.

Next steps

1. Tune into Al Wagner’s presentation “Seeking perfection through optimization” on November 12, 2019. Then, take the time to think through what big things can change as you adopt tools. Consider the cultural change you wish to drive, and which tools will help you facilitate it.
2. Check out the latest OVUM report about what to look for in a DevOps platform and how to identify a provider that can help you with the tools and guidance to champion DevOps technology and culture changes seamlessly together in your organization.