How Continuous Delivery Enables High-Performing Technology Organizations

Source:-forbes.com

CTOs and other technology leaders face a difficult challenge: How do we get board members and fellow executives to understand how well an R&D team is performing? The short answer is by demonstrating value, which lies in working software. The faster we deliver software, the more value we show. The best way to quickly deliver software is to create a high-performing technology organization (aka an engineering team) by establishing continuous delivery.

Use Continuous Delivery To Meet Expectations

Continuous delivery isn’t a new concept, but it’s a practice that not many larger, established companies follow. There’s often too much history, which leads to risk-aversion policies. Without using continuous delivery, companies package together multiple releases into one big release. As a result, they wait longer to release product updates. This approach feels less risky, but the truth is that releasing larger updates less frequently presents far more risk than regular, smaller updates.

For example, an e-commerce company might halt changes to its website during the winter holiday months to avoid potential outages or other problems while site traffic peaks. That seems reasonable enough until it’s time to update the site in mid-January. What happens if, after the big update, part of the site stops working correctly or recently placed orders become corrupted? Because so much code was changed at once, it’s nearly impossible to pinpoint where in the update the issues occurred.

Unable to pinpoint what’s wrong with the release, the team may have to roll back the entire update to stabilize the site. This means losing even the good code that went out and likely delaying other projects individual teams are working on to contend with the rollback.

If the e-commerce company practiced continuous delivery, it wouldn’t end up in such predicaments. With continuous delivery, companies regularly release software updates in short cycles. This updates websites and products not with large-scale changes but with incremental tweaks. Continuous delivery allows engineering teams to constantly improve the product while also examining and improving their own processes.

It’s important to understand why continuous delivery makes sense and how to align the practice with customer expectations.

Continuously Deliver Per Client Requirements

Before we dive into how to keep an engineering team running smoothly, we should first ensure we’re working toward goals that meet our clients’ needs. To release software that is aligned with client demands, gather and listen to user feedback.

Your team can only accomplish continuous delivery when it receives feedback regularly and can quickly move to adjust to that new information. Constantly iterating based on client demands ensures two things: 1) That your team is nimble and able to act quickly according to client demands and 2) that you aren’t simply updating for the sake of updating.

Obsessing over clients isn’t useful unless you can deliver the results they desire. Delivering adequate results requires creating expectations and measuring progress against expectations. Many typical metrics such as lead time for changes, mean time to recovery (MTTR) and change failure rate apply here. The best way to hit those metrics? Practice continuous delivery.

Regular Delivery Improves Performance Metrics

If we revisit our customer-centric metrics, we can see how continuous delivery enables us to meet them.

•Lead time for changes refers to how long it takes for the engineering team to deliver a change to the software. Larger changes typically require a heavier investment: More people need to be present to implement the change, and individuals higher up the command chain must approve the changes. This results in longer lead times and a higher volume of riskier changes. With continuous delivery, engineering teams can leverage more preapproved standard changes or changes that are electronically approved by the necessary approvers, reducing the amount of human capital and time required to alter the software.

•Mean time to recovery refers to the time it takes to repair the software in the event of a failure. With larger, less frequent updates, the team will have a much more difficult time deciphering just what went wrong. Continuous delivery makes it easier to identify the problem and repair it, possibly even avoiding a rollback of the update altogether.

•Change failure rate looks at how often changes result in failures that need immediate attention. The goal is to achieve a failure rate between 0-15%. If the change the team pushes is very small, there’s a much smaller likelihood the change fails. Small changes are easier to understand during review and usually have a less widespread impact.

Checks And Balances Smooth The Process

While continuous delivery can help our customer-obsessed technology organization perform at high levels, the team still requires checks and balances along the way. These checks and balances may include practices such as pair programming to ensure code is well-thought-out, code reviews to serve as a double-check on the pair programming and test-driven development, which leads to quick development cycles and refactorings with minimal regressions based on specific test cases.

Leadership Must Advocate For Process Changes To Meet Customer Needs

As with any big change, implementing continuous delivery to power a high-performing engineering team requires buy-in from the entire organization. However, large organizations that require buy-in from more individuals would benefit the most from changing to continuous delivery practices. Large companies that are able to deploy continuously do so more times per day per capita than smaller companies, a mark of a high-performing team.

Unfortunately, large organizations often do not have this practice implemented due to unnecessary process and perceived risk mitigation. Technology leaders must urge their fellow leadership team to adopt continuous delivery. It’s the only way to meet the rigorous performance requirements clients demand and stay ahead of the competition.

Hopefully, this continuous delivery primer helps you understand why the process is crucial for a high-performing organization. The book Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren, Jez Humble and Gene Kim explains the concept in much more detail, and I recommend it for anyone interested in pursuing continuous delivery in their company.