Delivering Continuous Delivery

A team should fail, learn, and win together. On a recent allocation the team was given the channel Home Insurance to grow. A common trait within my current employer short term delivery goals are regarded higher than total cost of ownership. This has left many channels with the burden of technical debt, low quality, poor documentation, high risk deployments, and high costs to maintain. A common solution is to rewrite instead of refactor, but I decided to take an approach of “Analyse, stabilise, and optimise”. The following paragraphs will describe how this was achieved through collaboration, stakeholder buy in, and Continuous Delivery.


With the challenges of change ahead, I had to prioritise what was required to achieve these goals. Firstly I had to tackle various elements of risk. There was a lack on domain knowledge within the team. How could I increase this? There was a significant lack of automation on the channel. Deployments were manual across three tiers. Some tiers were deployed in a delta manner due to risk, and hadn’t been deployed in their entirety to for many years. How could I remove this? Secondly, how could I remove noise caused through technical debt, and how could I reduce the cost of delivering value. To begin with I introduced Behaviour-Driven Development (BDD) into the channel’s software development lifecycle.

The first task I had to implement was to get various stakeholders across the business together to describe the channel from their perspective. The output from these sessions was a set of features that detailed the Home Insurance channel. To provide value from these artefacts, these had to be executed as part of a continuous delivery pipeline.


Any automation tests that are driven through a web-browser are notorious for their performance. Developers want quick feedback on their changes. A set of acceptance tests should not take many minutes or hours to execute. To provide a solution to this, I made the decision to implement features using cucumberjs within node, and for these to be executed on a Selenium Grid.  This allowed the benefits of speed and environment agnostic to be gained, and for parallelisation to occur. The team was already accustomed to Selenium Webdriver, and Chrome Driver.

As team we were going on a journey together. New skills had to be learnt by all members. I wanted our two testers to own these feature tests, as I wanted them to become first-class citizens of our software development lifecycle.  At any story kick-off, testers and developers would work collaboratively to
deliver a story. There was a lack of programming skills between our testers, so I spoke to our stakeholders to allow for a week’s worth of effort to be allocated implementing these features through developers and testers
pairing. I negotiated with the team’s product owner outlining how this would de-risk future change on this channel but also how our lead times could be reduced once our continuous delivery pipeline was in place.

Getting the rewards from Continuous Delivery

With the establishment of BDD into our software development lifecycle and confidence growing within the team around these new processes, my attention was now focusing onto how to deliver automation. As an
organisation we have been using the continuous delivery tool “Go” by Thoughtworks. A limited number of channels had already been delivered using “Go”, but these were achieved through Greenfield projects, and never from Brownfield. I had to come up with a strategy that demonstrated that what we were doing was correct, and had buy-in from our transition/release team that we could deliver a channel (various components across two tiers of the technology stack) that could be deployed in an autonomous manner that had no impact on live service. To achieve this I had to demonstrate that at each stage of our pipeline was delivering these reassurances through the successfully execution of our newly established feature sets.

Once automation reached live we saw an increase in the team’s velocity, and technical debt reduce. Small incremental changes were pulled to live through our pipeline where releases would be made four times a week. In hindsight some of the stories created during this task could have been broken down into smaller ones, but this was a minor glitch to what was large success for the team.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.