Release early, release often’ (RERO) is a development methodology that creates an agile feedback loop, which promotes collaboration between developers, testers, and users. When collaboration between all relevant parties is fast, teams can avoid bottlenecks. However, it is crucial to set clear expectations, and provide tooling for easy communication.
In this article you will learn:
What Is Release Early, Release Often?
Release early, release often (RERO) is a development strategy focused on frequent, early releases. It is designed to create a feedback loop between testers, users, and developers. The goal is to promote faster, higher software quality that better meets user needs and expectations. RERO is a development strategy that embraces the risk reduction approach used in agile methodologies.
4 Benefits of Release Early, Release Often
Adopting a ‘release early, release often’ strategy can provide several benefits for teams and users. You’ll find a review of key benefits below.
1. Quick Feedback Loops Improve Developer Productivity
A quick feedback loop improves developer productivity. When developers get feedback on each change or smaller set of changes, they are better able to cater future work to user needs. Getting fast feedback also helps developers address issues faster, before changes are complicated by additional work.
Frequently releasing small changes enables continuous feedback to be passed back to developers. Since changes are smaller, users and testers are better able to evaluate change impacts. In contrast, with larger releases, users may be distracted by numerous differences and less able to provide feedback on individual changes. You can learn more about testing feedback loops in our guide about the software testing life cycle.
2. Faster Feature and Patch Release Cycles
When features and patches are developed and released quickly, releases are more directly tied to requests or needs. For example, a user requests a feature but nothing is released for months in response. When the release is made, that user may not even remember the request anymore, negating the benefit of the work.
For bug fixes, early remediation is critical, because fixing bugs becomes much more expensive the later they are discovered in the software lifecycle. Frequent releases can help ensure that the lifetime of bugs is short. For security-related flaws, this also limits the time that vulnerabilities can be exploited.
3. Avoid the Pressure of Larger Releases
When software releases contain lots of changes, developed over a longer period, there are more demands on a team. Longer periods between releases add pressure to make each release significant, with multiple large features.
Infrequent releases are also likely to have more bugs since each release contains more code. As release time approaches, developers have to determine priorities for a much larger group of issues and changes. For example, which bugs to fix or features to finish.
Small, fast releases inherently limit the number of features or bugs that might be included. These limitations, imposed by methodologies like ‘release early, release often’, make developer choices simpler. Developers can then focus on completing each sprint goal without being distracted by additional tasks or requests.
4. Improves User Experience
Users appreciate fast responses when they request feature changes or report bugs. Fast responses show that development teams care about user opinions and needs and are working to meet those needs.
Additionally, active products that are consistently and constantly improving are more appealing to users. This activity can show potential users that investing in a product is worthwhile rather than a gamble.
3 Steps to Begin Your RERO Journey
If you’re interested in adopting a ‘release early, release’ often strategy, there are several steps you need to take. The three steps introduced here can get you started.
1. Set Clear Expectations
As with any project, the clearer your expectations, the easier it is to start working effectively from the start. To begin, you should get your stakeholders together to discuss ideas, expectations, and limitations. You don’t have to have a perfect plan from the start but you do need to define your project boundaries. From there, you can narrow your focus and develop discrete, well-defined guidelines for features and timelines.
Ideally, you should spend a bit more time upfront, with everyone’s feedback to create a clear plan. Doing so can help you avoid bottlenecks and last-minute changes that interfere with speed and progress.
2. Request Feedback
Within reason, the more feedback you have, the better you are. Developers and designers should submit drafts of features and interfaces early in the process. These drafts can help ensure that work is not done in vain. Drafts can also help teams better collaborate and refine ideas. Since there is a base idea to work from, teams are less likely to get stuck in the creation phase or derailed with defining specifics.
When gathering feedback, make sure your reviewers understand what you need to implement their insights. It does you no good to get feedback that simply says “I don’t like this”. Train your team on how to provide constructive feedback and how to request feedback effectively.
3. Embrace Technology
In any project, you need tools to help teams communicate and collaborate smoothly. Although these tools do not have to be electronic, software tooling can often provide greater benefits than analog options. This is particularly true for distributed teams.
There are many messaging and communication tools that teams can use, such as Slack. Often you can integrate these tools into larger planning platforms, such as Jira or Basecamp. These combinations enable you to create a central hub of project information to ensure project visibility. Centralization helps organize communications and reduces time spent switching platforms or digging for notes.
When adopting communication tools for ‘release early, release often’ cycles, make sure to set up clear guidelines for use. If you don’t, each team member is likely to adopt the tool in a different way, which can cause conflicts. For example, you can set up channels for specific features, general issues, or even lunch requests. By restraining communications by channel, you can help limit distractions and ensure that important communications aren’t obscured by chatter.
Similar to communication tools, there are content creation tools that you can adopt and integrate into a single source of truth. Using shared creation tools, such as G Suite or wikis can help you avoid the issues that come with individually stored documents. Shared repositories ensure that everyone has access to content at all times and that everyone is working from the same version.
This single source of truth also makes it easier to track your progress and ensure that documentation is not lost. One caveat, you do need to carefully decide privileges for editing or changing your various content. For example, if someone submits an item for review, they often don’t want to allow others to make undocumented changes.
Release Early, Release Often With Sealights Software Quality Intelligence
Testing is a crucial element of any ‘release early, release often’ implementation. However, that does not mean you need to run all types of testing for any type of release. To ensure maximum productivity, you should prioritize testing. You can do that with insights provided by Sealights Software Quality Intelligence.
Sealights analyzes your software, and then provides you with the feedback necessary to improve sprints velocity and productivity. With Sealights, you can:
- Identify quality risks—discover which tests will improve the quality of your software.
- Identify waster tests—discover which tests are redundant and waste your time and effort.
- Make data-driven decisions—release builds to production only after ensuring quality standards were achieved.
For more advice on how to increase agile velocity and productivity with quality intelligence, learn more about Quality Intelligence.