Releasing Often: How Rapid Delivery Helps Us Develop Faster

This post is part of our series on the agile development process that we follow at NewVoiceMedia.

One of our main principles as an agile team is that we release new versions of the software to live regularly.

Gone are the days of releasing every year in a "big bang" style, only to find the market has shifted, our customers requirements have changed, or even worse, the software doesn't work.

Regularly releasing poses a whole new set of challenges, but with these challenges comes great benefit for our customers and of course, ourselves.

One of the main principles of agile is concerned with reducing feedback loops. A feedback loop is when you gain insights as to whether your message (or what you were doing) was good, bad or indifferent from the audience you were targeting.

This is a very simple explanation but at the heart of agile is the goal of getting feedback early and often from the people that matter.

We have a number of feedback systems in place during our internal programming and testing work, but regular releases to Live is one of our main feedback systems from a wider audience.

Our goal is to release our products every two weeks with no disruption to our customers. It's a fluid cycle but has found its momentum over the last year and we're continuing to grow and evolve.

Releasing to live involves almost every department in our business as we embark on a release process that sees the software leave the Development team and move through to Operations to deploy the software to our live system, followed by support, marketing, sales etc. It's a great team effort to get these releases out frequently.

We have an outstanding track record in achieving an almost fortnightly release cycle (with some exceptions for holidays etc) but it's not been an easy ride and it's involved a lot of hard work. It takes a huge amount of discipline, communication and commitment. Even though we are releasing fortnightly it's still going to take a huge amount of focus and energy to keep this going.

I think a common myth about agile development is that the hard work is in attaining the guiding principles (iterative work, regular releases, planning sessions, feedback cycles). In my experience the hard work comes in maintaining them also.

So why do it?

In releasing to live often:

• We reduce the cycle of feedback from our customers. Where once this could be measured in years, it's now measured in weeks.
• The changes in the code-base between releases is limited to only two weeks (easier to find and fix issues).
• We can respond to shifting markets, customer insights or product changes faster than if we were tied to long-term projects.
• We can see our work realised in a working product being used by our customers. This gives a great deal of satisfactions and motivation.
• We learn about what works and what doesn't quickly.
• We can change a process that might not be optimal, measure how the change affects us and react to these accordingly.
• We learn about our internal processes, team dynamics and release processes more frequently. This gives us the confidence to change the process for the better.
• The gap between an idea and a realisation is short meaning we can reduce the chance of a misunderstanding.
• It creates a really vibrant working environment where delivery to our customers is a core focus.

We are always learning more about our release process, and always looking for ways to make it smoother, less prone to errors and more seamless. Putting in place this regular release cycle has really changed our focus towards adding value to the product for our customers.

It's no longer about shoe-horning in requirements for a year long release, writing huge upfront specifications, spending months coding with little to no feedback and then releasing a massively disruptive change to our customers.

It's now about manageable levels of work, rapid short feedback cycles throughout the whole development process and regular releases of added-value for our customers.

Does your business operate with short development times? What are your thoguths about the agile process?

We'd love to know your comments in the section below, and please subscribe to the blog and share with your network.