Blog Company How we maintain product velocity with a monthly release cycle
Published on: November 21, 2018
5 min read

How we maintain product velocity with a monthly release cycle

This workplace has gone 85 months without missing a release.

monthlyrelease.jpg

We eagerly await the 22nd of each month, because we get to share the hard work of our team and community with our users. Our release schedule illustrates our belief in the importance of velocity and our commitment to delivering value in the form of features. Monthly releases might seem aggressive to outsiders, but we believe our ability to deliver features quickly is a competitive advantage that has helped us find success.

Three cheers for a monthly release cycle!

A monthly release cycle is great for users, because it adds value at a predictable pace. Most of GitLab's installations are self managed, helping users identify when new functionality will arrive. As a user, you can look forward to the 22nd of every month, knowing that's when new features become available.

A screenshot of a user's comment, which says that he is looking forward to February 22 more than 21, which is his birthday

A predictable schedule helps with planning team capacity

The team has also found that it's easier to determine how much capacity we have when we're planning our workload, because there's no need to agree on deadlines. GitLab team-members know exactly how many days they have to work on something, and we can plan in advance. Working with such a short timeframe forces us to build features as small as possible. We can't say, "I need two releases for this," so we have to really think about how we can make a feature smaller, an idea that's reinforced by our iteration value.

"Sometimes, team members will propose having longer release cycles, because we'd be able to fit more into it, or we'd be able to do better quality control, but I think that's short sighted. It's true that in a longer release cycle, you can fit more in, but that will require bigger steps, and we know that iteration is what makes us achieve velocity. So, the smaller the steps we take, the faster we can go and the easier it is to do quality control. We think a monthly release cycle is the optimal frequency." -- Sid Sijbrandij, GitLab CEO

Challenges posed by monthly releases

It's not always easy to stick to the plan

It's not all sunshine and rainbows. While we're strong proponents of the monthly release, we realize that there are quite a few challenges. A few of the drawbacks relate to our actual deadline and staying on track with the direction of GitLab. For example, a release might be far away, but we want to ship something now. Or, we want to ship something, but the release just passed, and now we have to wait. Sometimes we try to cram in something just before the merge window closes even though it's not ready. When these situations arise, we remember to shift objectives and focus on providing value to our users.

There's a big impact on morale

One of the most bittersweet aspects of a monthly release cycle is that morale can soar or suffer, depending on the processes that are put in place. We're thrilled when we make something and quickly see the benefits. With our schedule, GitLab team-members see their hard work in action within a month, which is way better than in some enterprise organizations in which someone might make something that won't get released for six months. At GitLab, people can rapidly effect change with their contributions and feel like their work matters.

There were times in the past, however, when our release schedule dampened morale. In the early days, we had a few times when things came down to the wire, and we battled bugs right until the end, making the 22nd look like an impossibility. The rush towards the end caused quite a bit of stress on the team, so we decided to create a bigger buffer between the release and the closing of our merge window. We also developed a release process to help keep us on track. Our release template has helped us identify problems earlier so that we're not feeling pressured at the end, which could be detrimental to everyone's motivation.

How to determine the right cadence

While we've found success with monthly releases, we understand that it's not right for everyone. If you're a SaaS provider, you don't need releases and can just ship whenever something is finished. If you're shipping software that people manage themselves, you're going to have to do versioning, so that people know what version they're on and are aware of releases, patches, and upgrades. A monthly release cycle forces you into this, so in that case, this cadence would work well for your team. If there's hardware in the loop, extensive testing, or human testing that's needed, then a longer release cadence is required, because you have to factor in significant fixed costs.

Identifying the right cadence for your organization comes down to experimentation and what your users will accept. Some user bases may only want to update every quarter or twice a year, while others want more frequent versions to stay current with industry changes. Because we strongly believe that smaller steps let you deliver faster, we encourage you to start with monthly releases and work towards settling on the pacing that works best. Collaborate with your team to create processes that simplify actions and hold retrospectives to make adjustments. We've found that our retrospectives are extremely helpful in identifying consistent problem areas.

Cover image licensed under CC 0

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert