Accelerate — Continuous Delivery

This post is part 3 of a 4 part series. You can start over or read the introduction in this post. Here are all the posts in this series.

From the last post about Organizational Culture, I concluded that 2 practices, Continuous Delivery, and Lean Management, can impact and change the culture. In this post, I will talk about Continuous Delivery and its impacts.

Figure 1 — Continuous Delivery and its impacts

What is Continuous Delivery

Let’s start with the definition of Continuous Delivery. Technically, you might know this term as CD, however, that’s not the whole story. The core of Continuous Delivery is not about releasing software to production continuously, but it is a mindset, culture, and practices that enable us to release the software to customers continuously which includes:

Built-in quality. Thinking about quality in every process from start to end, not only do the testing after the product was finished.

Work in small batches. We don’t want too many incomplete works waiting for the next person to finish it. What we need is the work that flows from start to end as fast as possible.

Automation. repeated tasks must be done by computers, not humans.

Continuous improvement. We always need a new way of work in order to release a high-quality product faster and faster.

Team responsibility. Mistakes, failures, or even successes should be owned by the team, not any individual.

Capabilities needed for Continuous Delivery

In the book, they discovered the key capabilities that drive continuous delivery in practice.

Version control. Everything related to the product from coding, infrastructure to configurations should be versioned and managed using a tool like Git.

Test automation. You need reliable test automation at all levels; unit test, API test, UI test, and many more to give the team the confidence to make a change. Also important, make sure that the testing codes are maintainable and do not overload the team.

Test data management. Test automation needs data. If the test data is not reliable, tests won’t be reliable either.

Trunk-based development. Trunk-based means a product code lives mainly in one branch most of the time. The research from the book found that this approach is better than the long-lived feature branch-based approach. I absolutely agree with this based on my own experience. Merging from branch to branch is risky and error-prone and adds more friction to the delivery process.

Continuous integration. The process from code committed to product release should be automated using the CI/CD tool. It needs to also include automated testing and auditing as part of the process.

Built-in security. Security is more and more important these days but has been treated as an afterthought. Fixing the security later costs too much and blocks the flow of work. The team should think about it and built it into the system early from the beginning.

Loosely Coupled Architecture. Meaning that the structure of the system should have as little dependency as possible. Product components and teams should be designed in a way that only necessary communications are needed between components and teams.

Empowered Teams. The team should be able to decide their own path, the way of work, tools, or anything they need to be successful. The success of the team must be aligned with organization goals.

Monitoring. Important product indicators should be ready for the team to monitor or act proactively. Metrics include product-oriented such as error rate, performance, auditing, customer-oriented such reported issues, usage, and revenue.

Impacts of Continuous Delivery

The Continuous Delivery capabilities above are used to correlate with other measurements. What they found is that Continuous Delivery could directly impact Organizational Culture, Software Delivery Performance, Team members (see figure 1).

The impact on team members is less deployment pain, less burnout, a bond with the organization, and more job satisfaction.


From this analysis, you can see that Continuous Delivery plays an important role in high-performance organizations. Capabilities or practices described above can be a clear guideline on what you can do to move your organization forward. Next, we will talk about another important factor that is also important, if not more, Lean Management.

Originally published at




software, technology, and life enthusiast. More posts

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Working with your Azure Devops Wiki

Git, the Developers Playbook

Connecting to MS SQL on Compute in GCP Using Cloud IAP

The First big Poll is Complete… Project Future Announcement

The Secrets Revealed from ITIL V4

10 Benefits of Using DBMS Approach

A Christmas Story with Nx, Angular and NativeScript — Part 1

Analyze weather data on a Redshift cluster using S3

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pongsatorn Tonglairoum

Pongsatorn Tonglairoum

software, technology, and life enthusiast. More posts

More from Medium

What is this “DevOps” thing, and why should I care about it?

This image comprises the cultures and practices that define DevOps.

Understanding TOGAF ADM Phase A (Part 2 of 4) — Communications Plan

Understanding Engineering Team Performance Metrics and How to Get Started

Scaling up your business international expansion‍ — Unlocking new markets one at a time.