Agile, but still really not Agile? What Pipeline Automation can do for you. Part 1.

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?
Possibly your answer is “No”, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‘old problems’ just do not seem to go away…
Hence the question:

“Do you fully capitalize on the benefits provided by working in an Agile manner?”

Straight forward Software Delivery Pipeline Automation might help you with that.

In this first post of three, I hope to inspire you to think about how Software Development Pipeline automation can help your company to move forward and take the next steps towards becoming a truly Agile company. Not just a company adopting Agile principles, but a company that is really positioned to respond to the ever changing environment that is our marketplace today. To explain this, I take the Agile Manifesto as a starting point and work from there.

Agile Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is the main objective what Agile teams aim for. Delivering a fully functional product by the end of every sprint. But far too often this product gets ‘stuck’ somewhere in between the Development environment and the subsequent Test, Acceptance and Production environments, basically leaving you with nothing new to demo to your Product Owner and other stakeholders.
For a large part, if not the largest part, it is about culture: do (product-based) teams literally thrive towards producing high quality functional components in the shortest possible time-frame? If the mindset is correct, you have already come a long way, but often teams work with tooling which is well, errr .. just quirky. Builds need to be started manually, unit tests are performed in a couple of areas and there is a real low coverage for functional testing. In many cases, I see that deployments are performed manually by senior technical developer or the Operations department.
Automation of every manual step in the pipeline that can be automated is key here. Be it the automation of packaging, the automation of tests, the automation of deployments or automatically instantiating new infrastructure. Shaping your company into a product-centric environment, aligning your delivery teams and automating every manual step in your Software Delivery process that can be automated will help you to achieve the first objective of the Agile manifesto.

Agile Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Agile teams aim to be as transparent as possible. This also fits the necessity for delivering a fully functional product by the end of every sprint. By delivering software on a regular basis, requirements may be updated at any time as well. The best feedback a team could wish for is customer feedback and nothing more dynamic than the voice of customer.
Being capable of dealing with the ever-changing environment requires a different mindset than the one used for working with rigid processes some Enterprises still work with today. It requires a culture of trust, continuous improvement on organization, product and personal level and fosters experimentation. A company incorporating concepts of Continuous Delivery focuses on shaping products together with its customer, resulting in a product that will optimally fit customer needs. For instance, this can be done setting up a Minimal Viable Product, making it accessible to the customer while monitoring both user -and system behaviors where feedback is channeled back into your end-product. This feedback-driven change is continuous in nature and requires a level of rigorous automation where manual interventions for deploying a new product are no longer welcome.
In order to foster ever-changing requirements, make sure your software development pipeline is able to provide the right amount of flexibility so your team can deal with this. It is of upmost importance you can react instantly and this is where automation comes into play.

Agile Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Deliver working software frequently is what an Agile team aims for, giving it instant ROI on a sprint-by-sprint basis. Agile teams deliver fully functional software by the end of each sprint, but sometimes this software remains stuck in subsequent parts of the software delivery process. As long as software is stuck within the pipeline, in any other environment than Production, it does not generate any value.
When your aim is to move towards the shortest possible release cycle, like delivering software multiple times a day, this can only be done when applying rigorous automation. These topics are addressed in areas like build automation, test automation, release automation, deployment automation and automating the provisioning of your infrastructure. Automating every manual step in your Software Delivery process that can be automated, will help you to achieve the third objective of the Agile manifesto.
 
Agile Principle 4: Business people and developers must work together daily throughout the project.
Working in end-to-end responsible multidisciplinary teams is an important aspect of Agile. People with all types of knowledge related to the end product need to be assembled within one and the same team. “You build it you run it” is what we hear often and for this, we need to make sure we are working in teams which objective is to not only deliver new functionality, but also to take care of the product’s operational aspects.
An important part related to Continuous Delivery, if not the most important part, is culture. When the objective is to push product delivery cycle times to an absolute minimum, chances are your workforce needs to be organized in a different manner than it currently is. First of all, you need to minimize the amount of handover moments, which can be achieved by organizing people centrically around (a part of) your product, i.e. put business, developers and ops representatives into one team where each member of the team is to explicitly bring skills to the table that add to the product.
Now, there is not much that automation can do in terms of ‘teaming’, but automation can help you in pulling product information to an abstract level everybody can understand. A failing build (red screen), a failing test (red screen with clear test name), a failing deployment (red screen with failing component name), a statistic report (6 / 10 deployments successful or ‘spikes after deployment of version n of the product) can help the whole team to understand what product status is. And this is what teaming is all about: that every discipline within the team understands that it is not just about their isolated part, but it is about the complete team’s product.

Stay tuned for the next post, where I’ll address Agile principles 5 to 8.

Michiel Sens.