A faster and safer approach to software releases that can transform business capability

Part 2: Learnings from the Trenches

A project’s success is never perfectly clear cut. There are always compromises, perceptions and expectations to be managed. The journey to implement CD is no different. Having all the tough conversations up front is key and this blog provides a basis for those conversations.

Scope Definition

Defining the scope will define the size, complexity and impact that CD will have within an business. It will also start prioritising work and defining the skills needed.

The scope definition will be different for every company. The questions below offer a starting point:

  • Is this a green field platform?
  • Is it migrating an existing platform or a combination of both?
  • Is the CD journey occurring in conjunction with a new product?
  • Are there multiple pipelines to coordinate?
  • How many customer journeys are effected?
  • How much automation already exists?
  • What outcomes are being focused on?
  • What metrics will determine success?
  • Has the team done something similar before?
  • Does everyone understand and agree on the focus of CD?
  • Are the team(s) aligned with the objectives?
  • Is there a non-opinionated method for determining priority?
  • Do people get carried away discussing the theoretical?
  • Currently, what are we not trying to achieve?

Scope creep is a killer, just like in all projects, so don’t let the excitement of green pastures invoke wayward effort. If the scope is not defined and the team is not aligned, then people will make up expectations along the way and offer disappointment on what had never previously been discussed.

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” —Charles Darwin

Expectations

Expectations are set to focus a team, achieving these expectations is secondary. There is a massive learning curve that occurs during a CD implementation. Gaining a shared understanding of the goals of CD is the easy part. Living those goals at every decision point and knowing how best to implement a solution is an ongoing learning process. It’s fair that these learnings will somewhat change expectations and even change the metrics to measure success. Be staunch on having a shared understanding of progress, that is the “before state”, “current state” and “future state” should be obvious to the business. Business involvement in setting and monitoring expectations will help understanding across the business.

Metrics can only be defined as a range. At one end the initiative is put on hold, at the other end it is unequivocally a success. The initiative’s target should start out being middle to upper of that range.

Operationally, expect the following:

  • Builds and deployments are boring, regular, repeatable and constantly happening.
  • It will continue forever. The mindset of CD is closely coupled with a mindset of continual improvement. The tooling will change and things will get broken but all for the greater good of continual improvement .
  • Output and prioritisation can be hard for an inexperienced team. There is no substitute for CD domain experience.
  • Experimentation will be more common. With experimentation comes failure and learning. Ensure learning is shared.
  • Some roles are redefined. Traditional roles in QA, release management, infrastructure management and even project management are augmented. This can create job uncertainty.
  • A skills gap to bridge. Implementing something new always creates a gap between current business capability and the desired capability to fully embrace that change. Align everyone with the objectives of the initiative, but only with continual improvement and continual bridging of the skills gap can the benefits of CD be exploited. Cross train people; developers should be able to write and fix automated tests, automated testers should be contributing to designing the pipeline and everyone (including non-technical people) must be capable of monitoring and searching system logs. People still need to be specialists but they need broader skills too so they can step in and step up when needed.
  • Old habits die hard. Especially when the pressure is on, people can revert to old ways. Be staunch, stick to the plan and learn. Understand any resistance to change as it could be valid but it’s also an opportunity to renew alignment.
  • Less noise can be perceived as less effort and less effort can be perceived as less output. Less noise should mean more efficiency and automation. Measure efficiency, risk and employee satisfaction.
  • It will get worse before it gets better. CD is often a big undertaking – there is a lot of upfront cost before benefits slowly trickle in. Fully exploiting those benefits takes even longer.
  • It’s not a silver bullet. It makes businesses operate faster and safer, it doesn’t simplify a businesses market offerings, customer needs or industry regulations.
  • Long term benefit. When it’s safer, businesses can run faster, when it’s faster businesses can react better to customer demand which can lead to better market share and customer loyalty. In many industries these metrics are slow moving.
  • 50% – 80% of perfection. Resolve current problems and do not let theoretical issues distract delivery. A continual improvement mindset will stabilise things over time. Aiming for perfection means moving too slow.
  • Old and new often cohabitate. Legacy and 3rd party systems often sit outside of a CD pipeline. Define strategies for integration.
  • Zero perceived change. Measuring improvement and risk is not common in most businesses and people quickly forget how things were. Understand that some of the benefits will go under the radar.

CD is not always the right tool for the job

Evaluate the benefits of faster, safer change against cost. This is easier said than done, but attempting it has more utility than ignoring it.

Consider the benefits

  • Becoming more competitive in the market through software.
  • Improving customer satisfaction through software.
  • Creating a continual improvement, blameless culture.
  • Discovering problems sooner.
  • Improved quality.
  • Increased innovation.
  • Reduced manual intervention – more automation.
  • Improved stability in builds, deployments and releases.
  • Zero system downtime – no more after hours releases.

Consider the costs

  • Creating or acquiring the right skills.
  • New cloud infrastructure costs (minus the retirement of any existing environments).
  • Ongoing investment to maintaining the pipeline and improving it.
  • The job uncertainty created when people are not comfortable adapting to change.
  • A lot of upfront effort whereas the benefits materialise and compound over a longer time period.
“The key to following the continuous delivery path is to continually question your own assumptions about what’s possible.” —Jeff Sussna

To Conclude

Alignment across all business units is key. Set expectations, metrics, and outcomes, but it’s equally important to establish what will not be done and the priority of everything else. Be clear on the current focus and how these will achieve expectations.

It won’t happen overnight, but it will happen. Hit it hard but ensure the pace is sustainable. It’s easy to underestimate the effort and learning required. Similarly, it’s easy to underestimate the compounding benefits over time.

Be staunch. Don’t revert to old ways and instead take every opportunity to renew the shared understanding of why CD is being established.

CD will only help to gain market share and improve customer loyalty if the customer is at the forefront of change.

This blog is based on experience and battle scars, not research or surveys.

Further reading