You\u2019re always looking for methods to release new features faster.<\/p>\n\n\n\n
After all\u2014 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.<\/p>\n\n\n\n
Of course, you have many methods you can deploy to accelerate your feature releases. You can perform canary releases<\/a>. You can test in production<\/a>. You can master rollbacks<\/a>. Each of these will accelerate your feature releases, and you should experiment with each of them.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n In this piece, we\u2019ll 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.<\/p>\n\n\n\n Parallel development is an easy concept to understand, but a challenging practice to master.<\/p>\n\n\n\n Essentially\u2014 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.<\/p>\n\n\n\n You don\u2019t 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\u2014 or four, or five, or ten, or more. The exact number doesn\u2019t matter. All that matters is this\u2014 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. <\/p>\n\n\n\n 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\u2019s code changes disrupting the working environment of the rest of your teams. And\u2014most important\u2014you can release each team\u2019s work independently, which means you don\u2019t have to wait for everyone to complete their tasks to push something new out to your users. <\/p>\n\n\n\n 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. <\/p>\n\n\n\n Essentially\u2014 with feature branching, you will organize your parallel development strategy around feature development. You will create a new \u201cbranch\u201d 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 <\/em><\/p>\n\n\n\n At times, these feature-focused branches are called \u201cuser stories\u201d, but for the sake of simplicity we are going to just refer to features and branches in this piece.<\/p>\n\n\n\n Once a feature branch<\/a> is completed, tested, and reviewed, it can then be merged back onto the main code base and released to users\u2014 no matter how far along, or how stalled, the product\u2019s other feature branches might be.<\/p>\n\n\n\n By focusing on the parallel development and release of individual features\u2014 and not on pushing large-scale releases, or monolithic trunk-based development<\/a>\u2014feature branching allows you to iterate your product as quickly as possible. <\/p>\n\n\n\n Click here<\/a> to learn more about monolithic architecture and how it compares to more distributed systems (microservices approach).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019t, 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s code base or feature set without anyone else knowing it.<\/p>\n\n\n\n These are big potential problems, but they are not inevitable.<\/p>\n\n\n\n Let\u2019s look at a few ways you can avoid them.<\/p>\n\n\n\n Let\u2019s start with the most complex problem to solve\u2014 misalignment.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019re working on, to collaborate on that feature\u2019s development, and to make sure their branch isn\u2019t straying too far from everyone else\u2019s. <\/p>\n\n\n\n But most of the solutions to misalignment are much subtler and \u201csofter\u201d. 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\u2019s work) before it has enough time to get too badly misaligned in the first place.<\/p>\n\n\n\n Misalignment is not inevitable, but it requires a lot of daily discipline to make sure all of your branches fit together.<\/p>\n\n\n\n Next, let\u2019s tackle the most common pitfall of feature branching\u2014 merge conflicts.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n When this happens, it\u2019s almost inevitable that a host of merge conflicts will pop up as soon as the team attempts to integrate their work with everyone else\u2019s.<\/p>\n\n\n\n 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\u2014as imperfect as it might be\u2014you merge and release it.<\/p>\n\n\n\n Finally, the simplest challenge to solve\u2014 developing the technical capability to release features independent of each other.<\/p>\n\n\n\n The solution here can be summed up in two words, \u201cfeature flags\u201d.<\/p>\n\n\n\nWhy Should Product Managers Bother with Parallel Development?<\/h2>\n\n\n\n
How Does Feature Branching Work?<\/h2>\n\n\n\n
What are the Potential Downsides to Feature Branching?<\/h2>\n\n\n\n
How to Avoid Misalignment When Feature Branching<\/h2>\n\n\n\n
How to Avoid Merge Conflicts When Feature Branching<\/h2>\n\n\n\n
How to Avoid Release Bottlenecks When Feature Branching<\/h2>\n\n\n\n