Scaling with multiple sub-branches — from front end point of view

Start point

When corporation reaches a certain size, it will create or acquire sub branches (franchises, sub brands or clients) for extend the client base. For example, Toyota created Lexus in 1998.

It means the whole engineering team has multiple sub-branches (we will call it branch for short from now on) to maintain with front end and back end. And this could be a scaling issue

Scaling and solutions

The common branch management solutions is, one branch per agile squad (in this case, Toyota squad and Lexus squad), and this has its limitations in scaling

Unsynchronised implementations

It means same update (fix or feature) for one section would not rollout across the branches as one solution, not updated in same way or not get released at all.

This is maintaining issues for quality: for example, one shared section has a security risk, it would need to be fixed repeatedly and separately (based on different cases) in multiple places to cover the risk. Same is true for adding new functions

The root of the problem is that the feature implementation across the branches is usually out of ownership scope of one individual branch(sub branch as Lexus) squad: when squad update a feature, the squad could easily forget to inform other squad, or been ignored by other squad based on their differetn sprint priority

We are using Toyota group as a sample:

one feature per squad over one branch per squad

At one page per release level, as image above shows (on the left side), the search result page release update in one branch(Lexus), would be fully or partially isolated from other branch (Toyota), since each squad has different sprints and priorities. Usually the update may be shipped to other squad(Toyota) release with major delay (or not get released at all).

Instead of one branch per squad, we could have one feature per squad (as the right side of image).

By change the ownership from vertical to horizontal, the update of search result pages for multiple branches and their releases are owned by search feature squad. The priority would be same for two branches (Lexus and Toyota), thus the same update we mentioned before will be, ideally, shipped to both branches in on sprint.

This also covers the problem of unsycnchronised implementation: because feature ownership could drive the squad to optimise the implementation. The search team could see and unify the front end (and back end) code base by similarity to reduce duplication and improve productivity.

At same time, it is more scalable squad structure: if Toyota sell or buy a new branch, the search feature squad may require only a minor updated on team size. On the other hand, when it is one per branch squad structure, would need a major update to relocate one branch based squad members to other branch based squads and has branch knowledge to transfer. Which could end up way more expensive compare to the first one.

Regression created by guest squad

Cutting it vertical by features does not mean it solves all ownership issues, without branch specialist support, the feature squad like users squad could create regressions on branches feature: the branch specific feature update provided by user squad also reviewed by user squad leads to critical bug on features outside of user squad

This is an ownership problem: when some sections requires multiple squad input, those usually ended up with one squad (user squad in this case) and can only see the impact from a limited angle. At same time, user squad alone could not ensure the success of all cases in multiple squad.

Luckily, we could solve this by introduce sub branches squad: the squad in charge and provide of all branches’ settings and features. See image blow

squad packages to support isolation of ownership

On the left side, the user squad has full ownership the branch based configuration on user order page. Without the ownership of branches, this wound easily end up

• Unsynchronised implementation (as first point, seach squad build a branch solution ),
• Or create regression without knowing breaking others, if it is shared with other squads that no squad has the overall view (ownership)

When we add sub branches squad, this ownership will lead the sub branches squad have the vision of overall view and this squad could add test coverage to ensure all cases are working correction when regressions are found.

This is also where squad packages shines. Within the user order page release repository (let’s say it is one repo for all branches), we could have (as the right side of the image shows)

• User squad packages provide render component with all possible variations are needed for different branches
• Sub branches squad packages provide the functions to inform render component how it should be render in each specific branch, things like ask global store which branch is it

With this setup, how it should be rendered in specific branches are controlled by sub branches squad. The sub branches squad release a new version the package, then update the version in order release repo, that would be it. This requires almost nothing from user squad, as user squad is not the owner.

To reduce Regression also requires better ownership in repos, the guest squad changes need to be reviewed by owner squad before release. In the sample above, we have 3 repos

• Branches packages repo: own by branches squad
• User packages repo: own by user squad
• User order repo: own by user squad

This is how ownership should work in guest squad and owner squad situation in our illustration, lets say branches squad need to update the the component render toggle

• Branches squad updates the branch packages and create a new version which updates the toggle
• Branches squad makes a pull request on User squad order page release repo with this new version
• User squad reviews and releases the change

In this process, guest squad (sub branches) modify owner squad (user) repo will need a review from owner squad to reduce the risk of generating regression without knowing it.

Corporation

Individual squad packages repo also reduce the regression in shared releases, it could add ownership layer to shared area. See blew:

With individual squad packages, one shared release repo (like home page repo) could be cut into multiple sections which owned by individual squads with packages, as the right side of the image shows:

• Search bar could be reused from Lexus to Toyota and supported by same design system and sub branches packages
• When the component is specific for one branch, it belongs to Branches squad like Lexus NX campaign and Toyota 86 campaign

That’s all

This design covers most of the cases in my team, Thank you for your time, and feel free to let me know what do you think about the solution