How to shorten the release cycle from weeks to days

Longer sprints could potentially produce excellent results. However, there are a lot of advantages when you can go from three months to two months, for example, or from one month to two weeks. Shortening the release cycle is also referred to with the methodology release often, release early (RORA), outlined by Eric S. Raymond in his book “The Cathedral and the Bazaar”. Moving to RORA does require effort. Therefore, it is essential to first properly focus on the benefits up front.

The advantages of a shorter release cycle

• Shorter time-to-market which ensures faster customer feedback;
• Higher quality because the scope is smaller and the focus greater;
• Lower complexity of releases resulting in less risk of bugs and more control;
• Faster feedback loop, faster fixes of bugs and being more flexible in making choices;
• Users see that bugs are fixed faster and notice that the customer experience is continuously improving. This creates appreciation;
• The development team is motivated by less stress and more impact. The team is more concerned with adding value than figuring out where they all touched the code.

Depending on the team and project, above advantages could have a different importance. For an online store, for example, the customer experience will be key. And for industries where retaining the right people is difficult, the motivation aspect will be more important. Focus on the specific benefits for your company and IT team, because:

Pitfalls certainly exist

The first dilemma that often comes up when looking at RORA is this: until people try your product, you don't know how good it really is. By releasing faster, you get the feedback you need to improve the product faster. However, you want people to see the best and final version of your product, and that in turn requires more development time. Therefore, the best approach is to incrementally shorten the release cycle. Keep the following pitfalls in mind when you start shortening the release cycle:

Not daring to take the leap

The necessary steps are taken - such as more automated testing, for example - but you still don’t have the feeling your way of working is perfect. Making the switch requires some guts. Embrace the adage "Nothing ventured, nothing gained”. Assume that new problems will arise that you will have to tackle.

Giving up too soon

The first few sprints will be difficult and you will have setbacks. This is a matter of perseverance, because at some point it really does get easier. You take a step back so you can then take two steps forward.

Wanting to accelerate without a plan

There are all kinds of conditions and scenarios that you have to agree on and complete beforehand: onboarding and motivating the team, automating the infrastructure, the impact on all stakeholders and how to involves them in the release, how to deal with major features, etc.

In short, to shorten the release cycle, you need a plan of action with the benefits, a realistic schedule, conditions and scenarios. The following best practices will help you create one.

Best practices for shortening your release cycle

The single most important prerequisite for any process change is simple, open communication. Don't impose the process from above, but ensure support and a multidisciplinary approach. Document everything well so there is no ambiguity. The following best practices and insights make a shorter release cycle feasible:

Discovery phase

Look at where you are now, what your infrastructure looks like and what technical and business processes are in place. Capture this well; this is your starting point.

Set a realistic goal

Are you already pretty focused on a two-week release? Then go for one day less. If that works, then a second and third day less will also work. Are you more likely to be at a three month sprint? Then set your goal to cut one week out of the sprint. A small goal works better than a big goal.

Ensure good coordination

Involve everyone on and off the team who will be affected by changes. So for example, the marketeer who will soon be able to design the customer experience faster, but also the HR manager who can tighten up the job ads. Capture the new way of working for everyone and keep massaging it in to ensure commitment.

Automate the pipeline (CI/CD)

Look at how you can replace as much manual work as possible in the development process: code quality measurement, performance testing, regression testing, test scenarios, deployment, etc. You will never achieve 100 percent automation, so determine how much coverage you need to feel comfortable.

Consider a "toggle”

This allows you to turn off a feature that contains errors or isn’t as well received as planned. A toggle is also useful for complex development that requires multiple sprints: turn the feature off until it is completely finished.

Shift-left testing

This is an approach where you move testing forward in the process (to the "left") as much as possible, which allows bugs to be found faster (and thus cheaper to fix) and shortens the feedback loop. It also helps making developers more accountable for quality.

Communicate clearly

Create an easy-to-read report to keep stakeholders well informed and aligned.

As a company, when are you ready to take the first step?

In the short term, manual testing always wins over automated testing. But once you get it set up right, testing does go a lot faster. You're making an investment in the future. That goes for all the steps you take to speed up the release cycle. Just be careful that increased speed doesn't come at the expense of quality. For that, it is essential to fully address the challenges people experience and keep people continuously motivated.

Why exactly are we doing this? Why do we make life more difficult for ourselves? The answer consists of the benefits predetermined by everyone. Therefore, you can start shortening your release cycle as early as today: look at the benefits for your IT team and company.

This article was originally published in Dutch - read it on Emerce.nl