Still Not Really Agile?
Still Not Really Agile?
How fast do features get to your customer? How fast does feedback drive change?
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Do 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.
The main objective that Agile teams aim for is 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 the most part, it is about culture: do [product-based] teams drive 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 a 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 the rigid processes some Enterprises still work with today. It requires a culture of trust, requires continuous improvement at the organizational, 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 by 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.
Delivering 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 with the objective 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 centrally 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 the 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.
Read the original blog entry here.
Published at DZone with permission of Michiel Sens . See the original article here.
Opinions expressed by DZone contributors are their own.