Many organisations are struggling to replace legacy systems. This is happening while industries are also coping with disruptive change. Business models are under pressure and new competitors are appearing.

It’s an enormous challenge for those responsible for delivering technology in those organisations: not only do they have to find a way to meet the goals of the business and maintain, control and support existing software platforms, but they also face pressure to adapt, innovate and compete.

In an attempt to control the change from the top of the organisation, we see companies introducing bureaucratic processes in order to cope. For example, they’ll introduce enterprise platforms before fully understanding the needs of the business. This conflicts with the changes that are being driven by the delivery organisation who are often moving to a more iterative approach.

That’s why understanding how Continuous Delivery works can benefit the whole organisation. Product owners should also understand the benefits of implementing an approach that focuses on fast feedback and regular, incremental improvements.

Reacting to change

A simple way to gauge your organisation’s ability to react to change is to measure how long it takes to get a feature from the first idea into the hands of users. For some organisations, even those that may run two-week delivery sprints, it may take weeks or even months to release a new product increment into production.

This slow pace of change leads to problems:

• Feedback – Teams find it hard to get quick feedback. No matter how much analysis, design or testing you’ve done on a feature you won’t know if it works until it’s in the hands of your users. This in turn makes it hard for teams and product owners to learn and react to how customers are using the products that have been built.
  
• Trust – As features move to production, trust can be degraded between teams as product owners wait to see feedback from users. When the next feature in development needs to be released more quickly, it becomes harder as both the codebase and the team have moved on.
  
• Inertia – As the size of the deployment gets larger, the negative pressure for product owners not to release increases. If there are problems when the release is made the natural reaction is to rollback the code, rather than fixing it by rolling forward. This leads to inertia with the project unable to progress.
  

How can you deal with this problem?

There are several ways you can tackle this:

• Mapping – Measure how long it takes you to get code into the hands of your end-users. Then, break down that measurement with a Value Stream Mapping to understand which steps in your release process are taking the most time. Perhaps it’s a handover between two environments, perhaps it’s a period of testing – you won’t know until you have some measurements.
  
• Story size – What’s the lowest granularity that you can get to with a story? Can you get to the point where you have small, independent features that can be delivered to production? Being able to release code in smaller batches can release some of the pressure that builds up with large releases.
  
• Measure and learn  – Watch how your customers are using your product. When the feature is being used by real people you’ll see things that need to be changed and updated but only if you have good analytics.
  
• Collaborate – Make sure the product owner is part of the delivery team. They should be sitting with the team, having daily conversations with the developers and testers. Focus on developing a sense of shared ownership.
  
• Invest in automated testing. This will reduce errors, mean less dependency on manual testing and will reduce the time needed to diagnose and fix errors in live code.
  

Overall, you can see how, by adopting a Continuous Delivery mindset across the organisation, you’ll be able to deliver better quality products. Once it’s in place, teams will be able to deliver change more effectively and visibly – whether that change is coming from within or outside the organisation.