Continuous Delivery in the Real World

Source:-devopsonline.co.uk

I feel appropriate to mention is that I do not blindly follow any particular methodology or rules for the sake of it. That may be down to the rebel in me always wanting to question, but in contrast, the professional in me always wants to understand the rationale for doing things in the way we do. Working very much in the “change and transformation” space it’s a trait that I think (my peers may be a better judge) has served me well.

To challenge and question if what we are doing is the best way to do it is no bad thing when we are ever striving to do less with more. Personally, I also find it adds far more value if you understand why you are embarking on whatever plans you have before looking at how you are going to do it. Then determine what it is you want to do. Now I’m not claiming to have discovered a magic formula and I’d imagine some of you might recall the teachings of Simon Sinek’s and recognise Why, How & What as the layers of the Golden Circle but it is a really simple way to evaluate and assess the things you are doing and if you should continue or change your tact. It’s also key to remember that whatever you do the people involved will either make or break it.

Getting back to the point, Continuous Delivery is a term that seems to mean various different things depending on where your specialism lies. For me, I use the definition from Jez Humble and David Farley’s book “Continuous Delivery”: 

“the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.”

I like this definition for a number of reasons but primarily I like that there is no reference to timings or technology. It is also derived from the first Agile Principle:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”

Again, there is no mention of how frequently this should happen or how you do it only that customer satisfaction is important. One thing we cannot get away from though is that by its very definition Continuous Delivery is directly linked to Agile and its methodologies.

“Different stages of a journey”

As a term, I find that Continuous Delivery is often used interchangeably with Continuous Integration and Continuous Deployment. But to me, they are different stages of a journey. You need Continuous Integration to be able to Continuously Deliver and when you’re there you can progress to Continuously Deploying. Understanding this is key as the journey should focus on improving what you are doing and the quality with a view of simply getting better. The only benchmark you should focus on is the one you set and try to avoid making comparisons with some of the so-called “unicorn” companies that might be deploying 100 times a week.

So why bother starting on this journey? Well, there are some significant benefits to doing so. The key three, in my humble opinion, are:

Lower risk to live releases – This starts to open real confidence benefits. If you are consistently delivering without issue then you’ll quickly find yourself in a good place.

Improved speed to market – Ah the possibilities! Some pretty big players in the software delivery world have made a business out of getting things in front of customers quickly. The quicker you can mobilise the quicker your chances of hitting those market gaps before your competitors.

Higher quality of delivery – Lower risks, better outputs all coupled with the above. Quicker feedback and a product improving rapidly again lend itself to being in a really strong position.

However, it is really important to first determine whether or not this is right for your organisation and your customers. If it isn’t then is the investment worth it?

Highlighting unexpected points

Embarking on a never-ending search to “be” an organisation that “continuously delivers” can highlight some things that you may not have expected initially and it’s important to be wary of those. Forewarned is forearmed after all! You’ll need to be conscious that this isn’t a magic bullet, doing things quicker and more frequently will not fix all of your problems. In fact, it’s very likely to highlight some areas as being a bit worse than you expected. I like to look at it as a giant spotlight you shine on every aspect of your delivery cycle. Whether you want people to see it or not you’re going to. All you are really striving for is a constant commitment to discipline and build on that time after time again. Remain focused on your why and persevere even when it feels tough. The more you do something the better you get at it. But you only achieve this by constantly evaluating what you are doing and how it went then applying these findings the next time around. People are key and you have to create an environment that people feel comfortable being honest in.

Going back to the “why bother?” I started a couple of paragraphs ago though if you’re noticing some of the things listed below then you’re probably in a position that would benefit from a shakeup anyway, so why not do it in a way that encourages some elements of continuous delivery:

Large unmanaged (or lightly managed) “change queues”

Implementation of change requires 6-12 month projects

Smaller changes pooled together as “projects”

Distinct handovers between teams (dev, test, UAT, etc)

Complex release plans

Operational frustration at “slow IT” – lack of trust

Disconnect between technical & operational

In my own experience, I’ve seen them all and ultimately, they have been improved by collaboratively adapting and changing ways of working. Sometimes you can do this with just individual teams or departments but the likelihood is your looking a real cultural shift spanning both top-down and bottom-up changes.

Why Continuous Delivery?

What originally inspired me to talk about this subject came down to working with a single organisation that had simply hit a point whereby it was going to struggle to do the right thing for its clients, usually some of the most vulnerable people in society, and the people involved knew something had to be done but struggled to find a solution. The changes made, looking back, were significant but very gradual and subtle although they felt pretty quick to implement to most. There was a lot of background work to make it seem that way. I’m also talking about an organisation that had previously failed to implement Agile principles so there was a careful managing of ideology required. From this I’ve learned that it’s important to pick your battles and also pick your proving ground. Look at low-risk business areas to thoroughly test, iterate and improve your methods. Do this until you’re comfortable and can show real business benefit. You want to be in a position that almost makes it seem too simple to be true. Bring your business colleagues into the mix and engage them early. This process is as much about engagement and communications as it is anything else. Be prepared to coach, support and promote what you are doing and the people involved. Live it and breath it with them this isn’t a process to be managed from afar.

Once you have a framework and your methodology defined against your why then look to formulate a structure that delivers what you need. This can be anything so long as it works! If it doesn’t work then change it based on the recommendations and suggestions of those involved.  Once you’ve started to get a bit of consistency build-up and scale based on your ambition.

This isn’t all straightforward though and you really do need to expect some negative outcomes, at least initially, and if you’re expecting them then you can avoid the knee jerk reaction of falling back to whatever process or ideology that wasn’t working before – usually because it’s comfortable and, to be honest, usually because those pushing it aren’t accountable! Expect a slow start and improvements to come gradually, you may even go backwards first but stay the course and trust the people.

Taking a deeper look

Now…. When talking about this and actually saying these words out loud one thing really resonated, and this goes back to the definition of continuous delivery I started out with, a lot of what I mentioned can be covered off with implementing some form of Agile. What I discovered was that this often fell a bit short and stopped at the point when a sprint ended and a “delivery” team handed over, what is known in the trade, as a shippable increment. A handoff lends itself to just ticking boxes and not focusing on the reason why you are working in this style. Looking back to the most recent occasion of applying this to an organisation I found that there were issues in quite a few areas that just reinforced a mentality of handing over something so it was someone else’s problem. To combat that we looked holistically at the entire delivery pipeline and actually re-engineered the environments model, team structures, release strategy, and delivery cycles. In that particular organisation it was also necessary to implement an overarching function whose responsibility was to effectively keep the cogs turning, planning, coaching and maintain the standards that underpinned this methodology. This goes back to one of my earlier points of ensuring what you are doing is right for where you are and not blindly following a methodology for the sake of it.

Whilst this wasn’t a quick process and could be likened to the turning of freight ship it was hugely beneficial to do. By improving the standards and the processes around delivery and actually creating a repeatable, scalable framework it also lay the foundations to really kick start some grander ambitions. At the point of starting on this journey the organisation I was helping was delivering around five or six large big-bang projects per year (sometimes more sometimes less) with a huge resourcing overhead and nervousness around releasing to live. After the move to a model that supports continuous delivery, the number of live releases dramatically increased, in the first 6 months of the year well over a hundred live releases had happened, with little to no impact on operational systems. The right people in the right place doing the right things for the right reasons (did I say right enough?!). Not only that the increase in speed with no loss in quality, in fact, but quality also improved, putting it simply – by doing more we had more feedback to act on and by acting on it we had better engagement and ultimately better products.

If you are just beginning on embarking on this journey then I wish you luck. If you’re midway through your journey then I hope it’s going well. But if you’ve finished your journey and are now a “continuous delivery” organisation, are you sure?

On a personal note, I’d love you to hear about your experience and what you’re doing, how it’s going, the challenges you’ve hit and overcome. So, feel free to get in touch.