You’re always looking for methods to release new features faster.
After all— the faster you release new features, the faster you get to collect real-world feedback from your real-world users, and the faster you can use that feedback to release higher and higher quality versions of your product.
Of course, you have many methods you can deploy to accelerate your feature releases. You can perform canary releases. You can test in production. You can master rollbacks. Each of these will accelerate your feature releases, and you should experiment with each of them.
But if you are really serious about accelerating your feature releases, then you have to start thinking about how to speed things up from a development perspective as well. And one of the most powerful ways to accelerate feature development is through parallel development, deployed through a dedicated feature branching strategy.
In this piece, we’ll explore parallel development, why feature branching offers an ideal form of parallel development, and how you can avoid the pitfalls of feature branching and use it to accelerate your feature releases.
Why Should Product Managers Bother with Parallel Development?
Parallel development is an easy concept to understand, but a challenging practice to master.
Essentially— when you and your team perform parallel development, some of your developers will work on one set of tasks, while your other developers work on another set of tasks.
You don’t need to split your developers into two even groups. You can have three different groups within your pool of developers working on three different sets of tasks— or four, or five, or ten, or more. The exact number doesn’t matter. All that matters is this— instead of having everyone work on the same tasks from the same code base, different groups work on different tasks within the same time period.
Establishing parallel development accelerates your feature releases in a few ways. Your teams will get to focus on smaller, laser-targeted assignments that are typically easier to knock off. You can avoid instability from one team’s code changes disrupting the working environment of the rest of your teams. And—most important—you can release each team’s work independently, which means you don’t have to wait for everyone to complete their tasks to push something new out to your users.
This last point is key. While there are many different forms of parallel development available to you, if you want to accelerate your feature releases then you must follow a form called feature branching.
How Does Feature Branching Work?
Essentially— with feature branching, you will organize your parallel development strategy around feature development. You will create a new “branch” off of your main code base that relates to a specific feature or a cluster of features, and you will assign that branch to a specific, independent team
At times, these feature-focused branches are called “user stories”, but for the sake of simplicity we are going to just refer to features and branches in this piece.
Once a feature branch is completed, tested, and reviewed, it can then be merged back onto the main code base and released to users— no matter how far along, or how stalled, the product’s other feature branches might be.
By focusing on the parallel development and release of individual features— and not on pushing large-scale releases, or monolithic trunk-based development—feature branching allows you to iterate your product as quickly as possible.
Click here to learn more about monolithic architecture and how it compares to more distributed systems (microservices approach).
What are the Potential Downsides to Feature Branching?
Now, even though feature branching can rapidly accelerate your feature releases, it is not a magic bullet. Feature branching can go wrong in a few big ways.
First, feature branching can be challenging to pull off from a purely technical perspective. You must establish some sort of easy method to release features independent of each other. If you don’t, then completed features are just going to pile up while you wait for others to wrap up, eliminating the entire point of feature branching in the first place, and reverting you to a more traditional release branching strategy.
Second, feature branching can cause painful merge conflicts. Even though your teams work independent from each other, their individual branches might all require changes to the same shared elements of the code base. When one team completes their work and merges with the code base, they might alter those shared elements and make other branches incompatible by the time they are ready to release.
Finally, feature branching can create a softer type of misalignment. When teams work in focused isolation for too long, they can lose touch with each other, and lose sight of the product as a whole. Feedback will be challenging to collect and share. Collaboration can disappear entirely. And teams can make big changes to the product’s code base or feature set without anyone else knowing it.
These are big potential problems, but they are not inevitable.
Let’s look at a few ways you can avoid them.
How to Avoid Misalignment When Feature Branching
Let’s start with the most complex problem to solve— misalignment.
When you deploy a feature branching strategy, you get caught in a paradox. On the one hand, isolating your teams is what feature branching (and parallel development as a whole) is all about. On the other hand, too much isolation destroys the unity of your team as a whole and the fundamental product you are developing.
There are some technical solutions to the misalignment that can so easily creep into teams working in parallel. One team can always pull-down changes from your other teams to see what they’re working on, to collaborate on that feature’s development, and to make sure their branch isn’t straying too far from everyone else’s.
But most of the solutions to misalignment are much subtler and “softer”. You can host daily stand ups for your entire group of developers. You can facilitate constant communication so everyone knows what everyone else is doing at all times. And you can shrink the size of each feature being developed so it has to merge back to the product (and everyone else’s work) before it has enough time to get too badly misaligned in the first place.
Misalignment is not inevitable, but it requires a lot of daily discipline to make sure all of your branches fit together.
How to Avoid Merge Conflicts When Feature Branching
Next, let’s tackle the most common pitfall of feature branching— merge conflicts.
Feature branching usually starts with great intentions. The developer group is broken into multiple teams. Each team is assigned a feature branch. And they are sent off to deliver their work quickly, and to return to merge quickly.
But often, these intentions go awry. Teams keep working on their features long after they were supposed to merge, and they keep pushing back their integrations. Usually this happens because a team gets lost in their work. They want to deliver the highest quality feature possible, and they go down perfectionist rabbit holes. But as they keep developing, they shoot far past their initial scope. And what was supposed to be a single small new feature or a simple update to an existing feature turns into a large, complex set of new features that better resemble a brand new release.
When this happens, it’s almost inevitable that a host of merge conflicts will pop up as soon as the team attempts to integrate their work with everyone else’s.
Like the solution to misalignment, the solution here is simple in concept but challenging in execution. You must maintain the discipline of keeping small feature branches that can be merged early and often. Set a minimum viable product (MVP) prior to creating the branch, and as soon as it is hit—as imperfect as it might be—you merge and release it.
How to Avoid Release Bottlenecks When Feature Branching
Finally, the simplest challenge to solve— developing the technical capability to release features independent of each other.
The solution here can be summed up in two words, “feature flags”.
Feature flags are toggles that let you release or rollback an entire feature with the click of a button. Each new feature, or each feature update, is assigned its own toggle that operates 100% independent of every other feature or update ready to be released. You can push the completed work of any team at any time, no matter how bug-ridden or half-baked the rest of your teams’ features may be at that moment.
The beauty of feature flags lies in their flexibility. If you want to release a completed feature as soon as it’s ready to go, you just toggle it on with one click. If you want to wait to release a few new features at once, then you let them stack up as they complete until the last new feature in the suite is finished, then you can release them all at once. If you release a new feature and then find a hidden merge conflict, you can toggle it off right away with just one more click.
Release Features Faster with the Right Branching Strategy
At this point, you now have a pretty clear picture of what feature branching is all about, and how to deploy it in your product management practice without falling into the strategy’s most common pitfalls.
Structure the smallest feature branches possible to minimize misalignment and merge conflicts.
Maintain the discipline to stick to these small feature branches and not get caught in endless attempts to make them perfect before release.
And streamline your independent feature release process as much as possible with the right tech.
Don’t let the simplicity of this strategy fool you. Once mastered, feature branching gives you a powerful method to accelerate your feature releases.
