Thoughts on inaugural #c9d9 online discussion panel

On Wednesday I took part in an online discussion on Agile / Continuous Integration / DevOps / Continuous Delivery organised by Electric Cloud (see http://electric-cloud.com/blog/2014/10/c9d9-continuous-discussions-episode-1-recap/) .

I was really happy to be invited to talk as a panellist on the discussion, especially seeing the very high calibre of the other individuals on the panel.  It was great to be included among such an insightful and talented group of people.

One of the things that struck me was that there was widespread agreement among the panellists of the benefits of Agile / CI / DevOps / CD, and many of the barriers that were encountered were also the same.

In the programme I work on at the moment I feel that we have quite a slick delivery machine that incorporates:

• Development - making code changes
• Automated CI build and scheduled build
• "Touch of a button" scripted tear down / rebuild of test environments (both functional and performance), with full redeploy or upgrade of the software
• Comprehensive integration tests
• Ability to "ship" as soon as the software on test has passed QA

However, within all this goodness there are some significant barriers.  I don't want to beat up my end customer too much, because I understand that if my software goes down for any length of time they're pretty much out of business.  It's a big responsibility.  However......

• The end customer is ultimately responsible for integrating, final QA and release into production.  The point was made on the discussion panel that if you look at your development process as a pipeline you can only move at the speed of the slowest stage.  This is definitely an issue where we are at the moment, we have the ability to produce much more value but we are constrained because the end of the pipe cannot absorb change quickly enough.
• As a consequence of this, as releases become further and further apart they become larger and hence have a higher level of inherent risk.  It is an irony that the risk-aversion that leads to endless test cycles of an integrated solution ends up slowing down the deployments so much that each deployment becomes ever riskier.
• One of the keys to solving this is DevOps.  Within my dev programme we've got great build and infrastructure guys embedded so we can all work together to create our slick process.  At the end customer the various teams involved are all in different organisational silos (and often in different organisations altogether).  The multi-functional teams required to make releases slick and frequent are not in place.  
• This makes for an interesting observation.  In software, quality comes from automation, because only by using automation can we be truly repeatable, and a precondition of software quality is repeatability.  But - again an excellent observation made on the panel - automation also frees software developers from mundane repetitive tasks so that they can focus on spending more time delivering solutions.  We should embrace automation, it is our friend.
• Also, and this is my own reflection on this, true agility (as opposed to agile methodologies, which I prefer to regard as strategies for managing change) comes from adopting best practices.  It involves setting up the software development / test machine (note that these two cannot be separated) so that when we change the solution we get feedback on the level of quality quickly. As anyone with a knowledge of control circuits knows: if you want a stable system the speed of change has to be slower than the speed of feedback .  
• Which brings me back to where I was before.  Long release cycles involve slow feedback.  We try to get around this by delivering into a QA environment on several-times-a-day basis (fast feedback).  However, we are at the mercy of integration issues at the other end of the pipeline and there the feedback can be months.  This causes us issues because we are regularly working on updated requirements to fix integration issues - not because this adds more business value, but because slow integration did not catch this early in the cycle.

A great discussion, much food for thought for me about where I want to take this.  My current programme is winding down at the moment, and I'm thinking of what I want to work on next year.  All I know for sure is that I want MORE CI, MORE DevOps and MORE Continuous Delivery!

And to work on big stuff.

Many thanks to everyone involved in #c9d9.