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

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 post 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.
In my previous posts (post 1, post 2), I addressed Agile Principles 1 to 4 and 5 to 8. Please read below where I’ll explain about how automation can help you for Agile Principles 9 to 12.

Agile Principle 9: Continuous attention to technical excellence and good design enhances agility.
In Agile teams, technical excellence is achieved by complete openness of design, transparency on design-implications, reacting to new realities and using feedback loops to continuously enhance the product. However, many Agile teams still seem to operate in the blind when it comes to feedback on build, deployment, runtime and customer experience.
Automation enhances the opportunity to implement feedback loops into the Software Delivery Process as feedback. Whatever is automated can be monitored and immediately provides insight into the actual state of your pipeline. Think of things like trend information, test results, statistics, and current health status at a press of a button.
Accumulating actual measurement data is an important step, pulling this data to an abstract level for the complete team to understand in the blink of an eye is another. Take that extra mile and use dashboarding techniques to make data visible. Not only is it fun to do, it is very helpful in making project status come alive.

Agile Principle 10: Simplicity–the art of maximizing the amount of work not done–is essential.
Many of us may know the quote: “Everything should be made as simple as possible, but no simpler”. For “Simplicity-the art of maximizing the amount of work not done”, wastes like ‘over-processing’ and ‘over-production’ are minimized by showing the product to the Product Owner as soon as possible and at frequent intervals, preventing gold plating and build-up of features in the pipeline.
Of course, the Product Owner is important, but the most important stakeholder is the customer. To get feedback from the customer, you need to get new features not only to your Demo environment, but all the way to production. Automating the Build, Deploy, Test and provisioning processes are topics that help organizations achieving that goal.
Full automation of your software delivery pipeline provides a great mechanism for minimizing waste and maximizing throughput all the way into production. It will help you to determine when you start gold plating and position you to start doing things that really matter to your customer.
Did you know that according to a Standish report, more than 50% of functionality in software is rarely or never used. These aren’t just marginally valued features; many are no-value features. Imagine what can be achieved when we actually know what is used and what is not.

Agile Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
Traditionally engineering projects were populated with specialists. Populating a team with specialists was based on the concept to divide labor, thereby pushing specialists towards focus on their field of expertise. The interaction designer designs the UI, the architect creates the required architectural model, the database administrator sets up the database, the integrator works on integration logic and so forth. Everyone was working on an assigned activity but as soon as components were put together, nothing seemed to work.
In Agile teams it is not about a person performing a specific task, it is about the team delivering fully functional slices of the product. When a slice fails, the team fails. Working together when designing components will help finding a optimal overall solution instead of many optimized sub-solutions that need to be glued together at a later stage. For this to work you need an environment the emits immediate feedback on the complete solution and this is where build, test and deployment automation come into play. Whenever a developer checks in code, the code is to be added to the complete codebase (not just the developer’s laptop) and is to be tested, deployed and verified in the actual runtime environment as well. Working with fully slices provides a team the opportunity to experiment as a whole and start doing the right things.

Agile Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
To improve is to change, to be perfect is to change often. Self-learning teams and adjustments to new realities are key for Agile teams. However, in many organizations teams remain shielded from important transmitters of feedback like customer (usage), runtime (operational), test results (quality) and so on.
The concept of Continuous Delivery is largely based upon receiving reliable feedback and using the feedback to improve. It is all about enabling the team to do the right things and do things right. An important aspect here is that information should not become biased. In order to steer correctly, actual measurement data need to be accumulated and represented at an understandable way to the team. Automation of the Software Delivery process allows the organization to gather real data, perform real measurements on real events and act accordingly. This is how one can start act on reality instead of hypothesis.

Maybe this article starts to sound a bit like Steve Balmers Mantra for Developers (oh my goshhhh) but than for "Automation", but just give it five minutes… You work Agile, but are your customers really seeing the difference? Do they now have a better product, delivered faster? If the answer is no, what could help you with this? Instantly?

Michiel Sens.