Why do Short Release Cycles Matter

Moving fast is obviously a good thing on mobile. Just take a look at the world’s top mobile apps and you’ll see that their teams are releasing every 1–2 weeks. But switching to a fast release cycle isn’t as simple as it sounds. And you should think if you really need to do it or not.

The story that I’m going to tell you may sound very familiar to you. Every time we sat down and tried to decide what product problems to solve next, we had a lot of ideas and were trying to build all at once. And as a lot of people do, we were over-complicating the problem and even trying to fit the problem into the solution instead of finding a solution to the problem. And, of course, we all wanted the product to be perfect without knowing whether the things we are going to try out were going to work or not.

So how do you build features that are NOT based on blind assumptions?

The answer for us was iterate until you make it perfect.

We started thinking about making simple changes and testing them instead of building big perfect features. So the plan was to create simple MVPs and deliver them to the users as fast as possible and get the feedback to iterate from there. In other words, we wanted to react to the market changes and learn quickly through gathering feedback from our users.

So, we set a goal to shorten our release cycles.

When I started out at PicsArt, we had a 2-month release cycle. And today, we release every week. That transition didn’t happen in just a couple of days. We did it gradually decreasing our cycles down to a month, 3 weeks, 2 weeks, and finally one week.

While this process took time and resources, finally it paid off by increasing our speed and time to market (TTM).

The Release Train

There is a release train concept which is not new and is part of the scaled agile framework. We were doing Feature based shipments (releasing when a set of features are completed) which would often lead to uncertain release dates, as well as a decrease in quality. The issue with that was the uncertainty as to when the next release is going to go out. Any delay or any other major issues pushed our entire release back for an uncertain period of time.

That’s why we decided to move from feature based release model to the schedule based (train) model.

Why Train?

Think about a real train. Maybe you will say that it is not the most efficient way of transportation. But there are certain reasons to choose a train:

• It is reliable and always departs on schedule
• Whether you’re onboard or not, trains and subways are going to leave the station at a set time
• The departure and arrival schedules are planned out months in advance
• If you’re not on time, you can always catch the next train

So imagine your releases are always on time and planned in advance and if some features are not ready yet there is always a next train (next release).

When shifting to this model we faced many constraints, but in this section I’ll talk about 3 key things to focus on.

Mentality

In order to achieve this shift, you need to make sure your entire team is ready for going all-in. This requires collaboration and a shift in mentality. The idea is that it’s ok to ship small changes instead of huge features. Explain to your team the benefits of moving quickly and being at the top and the model by which you are going to accomplish it.

Transparency

Make sure that the train schedule (Release dates) is public for everyone in the company, like in the train station. And everyone is aware about the processes, documents, features that should go into the train.

Confidence

Make sure that you have all the necessary tools to operate in this fast-paced environment. Imagine that the release is not a special occasion anymore and it is part of your everyday routine. In order to be confident you need to make sure to automate anything that stops you from achieving this goal. And one of the pillars for us was our internally developed feature flagging solution that allows us to rollout or disable any feature on Live without submitting a new version to the store.

A lot of people will say that you also need someone who will manage this entire process, someone called a Release Manager or Release Owner. At PicsArt, I took that role for some period but after automating almost all parts of the process, that role started to be something artificial. And now at PicsArt, all team members are Release Owners in some sense.

Wrap UP

There are a lot of advantages when you move faster, you are able to be on top of the game, deliver value faster. In other words, you get the chance to gain first-mover advantage by continuously improving the user experience. But to keep this going, you should always deliver innovation again and again in this process and keep in mind that weekly releases are not the ultimate success and you can level up the game and make your release cycles even shorter.