Blog

If you are a software engineer, or if you have been a part of a software development company in the last 10 years there is a good chance that you have heard of the Agile Manifesto and the Twelve Principles behind Agile Manifesto. 

Agile Manifesto is a document, or a proclamation of sorts, which is designed to improve software development methodologies, and directly responds to the inefficiency of traditional development processes. Namely, their reliance on weighty documentation and opportunity for oversight. 

One of the principles behind the Manifesto says that we should: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.”

How often does it happen in real life? Unfortunately, not too often.

More often than not, an engineering organization will declare itself as agile, adopt an agile framework (usually scrum), and then go through the motions of having sprints, daily standups, sprint plannings and retrospectives. These are important steps and they almost always help in making an organization more agile, but the work doesn’t end thare. Continuous integration/delivery is one of the most important characteristics of an agile software organization, or as it’s outlined in the third principle of the Manifesto, you should deliver working software frequently, with a preference for a shorter timescale.

Usually, organisations fall short on the delivering working software frequently step of the agile principles. This inevitably leads to more stress when the release comes, with engineers on-call, working weekends and delays in increment delivery. 

From our experience, an engineering organization greatly benefits from making a transformation from an organization that releases over a longer period of time to an organization that releases early and often. These benefits are visible both in terms of team satisfaction and the quality of software we are building. Here are the key benefits we experienced when adopting this strategy: 

• Less stress around releases among the development teams – when you bake in releasing in your daily routine as opposed to releasing once every couple of months, releases are not treated as a special event, what didn’t go in today, will go out tomorrow (or next week, depending on your cadence), no need to stress about it
• Shorter client feedback loops – when you release every day, you quickly get feedback from your customers and are able to make changes to your product accordingly 
• Better code quality – smaller releases mean less code being shipped and we decrease the possibility of shipping bugs
• Quicker recovery time – when a bug slips by your QA process, it’s easier to identify the root cause and get a fix out if you have a smaller release to analyze 

However, releasing early and often requires you to make some adjustments and investments to your SDLC. Some practices that helped us get to 1-per-day release cadence are listed below: 

• QA process should run in parallel with the development – engineers doing QA and developement should start working on the feature together, figure out what’s the best way to verify that the feature is working, write test cases that will be used for verification, and test the feature as it is being built
• Automate as many test cases as possible – reduce the amount of engineering effort needed to run regression tests
• Put safeguards in place – we like to run automated tests on every PR before merging it to main branch, making sure nothing is broken 
• Automate the release process as much as possible – ideally, you should be able to release your latest increment to production with just a couple of clicks 
• Use feature flags and staggered rollout (if possible) for more complex features
• For more complex features, do a staggered rollout if possible 
• Implement observability tools such as New Relic. As an engineering organisation, you must know if there’s a problem with your app before your customers tell you there is. New Relic (or some other,, similar tool) will provide you with real-time performance metrics of your app, both through logs and graphs/dashboards so you’ll be able to spot inconsistencies/irregularities and react to them
• Invest in your Site Reliability Team – having great engineers in your SRE team will vastly improve your ability to build a resilient and scalable deployment pipeline and also respond to any production issues

These are our lessons learned from releasing early and often. We would strongly recommend adoption of these principles in 9/10 cases, but it’s also important to remember there is not a one-size-fits-all solution in software development. The most important thing for every engineering organization is to be honest and open in assessing its needs and then deciding which route it will take.