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

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 post, I addressed Agile Principles 1 to 4, please read below where I’ll explain about how automation can help you for Agile Principles 5 to 8.

Agile Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is an important aspect in Agile. People get motivated by acknowledged empowerment, responsibility, ownership and trusted support when performing a job. This is one of the reasons Agile teams often feel so vibrant and dynamic. Still, in many organizations development-teams work Agile but “subsequent teams” do not. Resulting in mini-waterfalls slowing down your delivery cycle as a whole.
“Environment and the support needed” means that the Agile team should work in a creative and innovative environment where team-members can quickly test new features. Where the team can experiment, systems “just work” and “waiting” is not required. The team should be enabled, so to speak .. in terms of automation and in terms of innovation. This means that a build should not take hours, a deployment should not take days and the delivery of new infrastructure should not take weeks.
Applying rigorous automation will help you to achieve the fifth objective of the Agile manifesto. There is a bit of a chicken and egg situation here, but I feel it is safe to say that a sloppy, broken, quirky development environment will not help in raising the bar in terms of motivating individuals. Hence "give them the environment and support they need, and trust them to get the job done".

Agile Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
When working Agile, individuals and interactions are valued over the use of processes and tools. When starting a new project, teams should not be hindered with ticketing systems, extensive documentation to explain themselves and long service times. These type of “services” often exist on boundaries of business-units of bringing different ‘disciplines’ to the solution.
Although working Agile, many companies still have these boundaries in place. An important aspect of Continuous Delivery is executing work in Product teams dedicated to delivery and/or maintenance of an end-product. These product teams have all required disciplines working together in one and the same team. Operating in this manner alleviates the need for slow tooling & ticketing systems and inspires people to work together and get the job done.
Organizing people as a team working on a product instead of individuals performing a task, which in itself has no meaning, will help you to achieve the sixth objective of the Agile Manifesto. There is not a lot automation can do for you here.

Agile Principle 7: Working software is the primary measure of progress.
Agile aims towards delivering working software at the end of each sprint. For the customer that is basically what counts: working software, which can actually be used. Working software means software without defects. There is no point in delivering broken software at the end of every sprint.
When sending a continuous flow of new functions to the customer, each function should adhere to the required quality level straight away. In terms of quality, new functions might need to be ‘reliable’, ‘secure’, maintainable’, ‘fast’, etc, which all are fully testable properties. Testing these type of properties should be integral part of team activities. One of the principles related to Continuous Delivery addresses this topic through Test automation. Without it, it is not possible to deliver working production-ready software by the end of each sprint.
Proper implementation of test-disciplines, fostering a culture of delivering high quality software, testing every single feature, adhering to testing disciplines and applying matching & automated test tooling addresses topics related to the seventh object of the Agile Manifesto. Supply a test for every function you add to the product and automate this test.

Agile Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
As software complexity grows exponentially, it will become more difficult overtime to maintain a constant pace of delivering new features, when assembling, deploying, testing or provision manually. Humans are simply not made to perform multiple tasks fast, repetitively and consistently over a longer period of time, that is what machines are for!
The eighth Agile principle typically comes down to a concept called ‘flow’. You might have an Agile team in place for creating new software, but what about the flow in the rest of your organization? Should the team wait for requirements to drip through, should it wait for the testers to manually test software, or is it the Operations team that needs to free resources in order to deploy software? To address this, from idea to product, handover moments should be minimized as much as possible and where possible principles of automation should be applied. This brings us back to build automation, test automation, deployment automation and the automation of infrastructure.

Stay tuned for the next post, where I’ll address the final four Agile principles of the bunch.

Michiel Sens.