One product but different components and different backlog.

Single Backlog first.

Single PO with possibly a committee of POs who help flesh out the features.

Feature teams if you can i.e. take a dev from each component and fit them into one team which work on on feature at a time across the stack. This is difficult.

You'll also require continuous integration and deployment and more automated testing than your used to to ensure the changes coming in are not breaking anything including integration.

Keep Bugs and Tech Dept at zero.

So I had a similar situation. We went with Nexus and really like the framework because if you know Scrum, it is SO EASY to incorporate versus learning an entirely new framework. 

I will say that I highly caution against scaling before you nail scrum. Just like Scrum itself won't solve your problems, Nexus or any scaling framework won't; instead they expose your problems and problem areas. 

I agree that your first priority should be a clear PRODUCT focused backlog, not a component specific backlog. This is where we struggled. Due to timing and various issues, we needed to move from component teams to feature teams, changed the framework to Nexus, and as a result we combined the component backlogs together. As you can imagine, this has created a huge problem because instead of being Product focused, teams are still component focused. 

Single PO with possibly a committee of POs who help flesh out the features.

First rule of being a Product Owner is there is NO Committee of PO's. There is a Single PO and anyone else can provide helpful insight from a stakeholder standpoint but there is only 1 PO.

You'll also require continuous integration and deployment 

CI/CD certainly makes the world go round smoother but to say it is "required" is absolutely false. You should strive and work towards CI/CD but saying that you have to have CI/CD in order to scale is just not right.

Hi All,

To give much more detail seems important to me. We have one base product in C# and the other components are running from this base product. One component is matlab, the other component is integrated C++ applications. But they are all related with C# base, i mean if we don't work with c# code base, the other components affected. 

I agree CI/CD can be a part of solution, neverthless we are making CI/CD and a little improvements came out. We couldn't totally solve the issues. Instead making a single backlog we have more than a backlog. But when we think about the languages (matlab,c++,python ) we need more than a backlog. For this differences our customers also wants these kind of varieties.

Thanks

Not sure if this is a good approach for you but I have seen it work in the past.  The approach involved looking at what we defined as a Product.  We were faced with similar situtaions where some disparate technologies were in use due to the development of the components by different organizations and one case by a separate company that was acquired. In this case it was a financial product, or at least that was the base assumption.  Upon inspection we realized that the financial product was actually a suite of products (i.e. Accounts Receivable, Accounts Payable, General Ledger, Payroll, etc). We found that each of these could have functionality released mostly independent of the others so we broke the single Product Backlog into multiple Product Backlogs. 

Without knowing more about your product I can't say that this a valid solution for you. But it can't hurt to take a close look at your definition of Product and see if there are ways to address this without going the scaling route.  As  @Curtis Slough says, scaling is not easy especially if you haven't mastered basic Scrum.  And in the true sense of agile, try experimenting with simplier solutions before going to the complex.  You may find a solution you weren't considering based on the learnings from your experiments. 

I try to solve our scaling issues . I say we have issues because we are working on a single product, but we make different product backlogs and components. Do you suggest scaling an agile environment with using Nexus,Safe,Less ?

My advice is to avoid scaling frameworks as much as you can. They should be a last resort. The preferred approach is to descale a challenge so the implementation of Scrum by separate teams continues to be viable.